| *** artfwo has quit IRC | 00:05 | |
| *** edogawa has quit IRC | 00:19 | |
| *** artfwo has joined #lv2 | 01:42 | |
| *** artfwo has quit IRC | 02:38 | |
| *** edogawa has joined #lv2 | 07:27 | |
| *** falktx has joined #lv2 | 07:30 | |
| *** ricardocrudo has joined #lv2 | 07:39 | |
| *** falktx has quit IRC | 07:43 | |
| *** rncbc has quit IRC | 07:44 | |
| *** ricardocrudo has quit IRC | 07:56 | |
| *** sigma6 has joined #lv2 | 08:01 | |
| *** falktx has joined #lv2 | 08:33 | |
| *** edogawa has quit IRC | 09:04 | |
| falktx | drobilla: does lilv_world_load_resource load data even if the file has been loaded before? | 09:56 |
|---|---|---|
| falktx | my code is running very slow even on my i7 machine | 09:56 |
| falktx | I mean, when scanning plugins that have 300+ presets | 09:57 |
| falktx | amsynth with ~2300 presets takes more than 20 secs | 09:57 |
| falktx | perhaps I can do an initial lilv_world_find_nodes without loading the resource, and only load the resource if that fails | 10:06 |
| falktx | aha, much better now | 10:07 |
| falktx | now I don't call lilv_world_load_resource for amsynth and getting the preset info is instantaneous | 10:14 |
| falktx | and with noisemaker I only call lilv_world_load_resource twice for its 2 preset ttl files | 10:15 |
| * falktx loves when things work fast | 10:20 | |
| *** ricardocrudo has joined #lv2 | 10:53 | |
| *** ricardocrudo has quit IRC | 11:07 | |
| *** son0p has quit IRC | 11:26 | |
| *** son0p has joined #lv2 | 12:08 | |
| *** artfwo has joined #lv2 | 12:32 | |
| drobilla | falktx: It shouldn't, no | 12:33 |
| falktx | drobilla: well, it seems to load them anyway | 12:34 |
| falktx | drobilla: I think it happens when the presets are not in separate ttls | 12:34 |
| falktx | although for amsynth they do are in fact in separate ttl files... | 12:35 |
| falktx | ah! amsynth includes the label inside the main manifest instead of the preset file | 12:35 |
| drobilla | falktx: It should happen at the file level. It's in lilv_world_load_file() (world.c:830) | 12:35 |
| falktx | so my current code works without having to load the actual preset file | 12:35 |
| falktx | all I want is the label | 12:36 |
| falktx | this seems to make things much faster | 12:36 |
| drobilla | 20 seconds is beyond crazy though | 12:36 |
| drobilla | something is weird | 12:36 |
| falktx | lot of allocations, it's 2300 presets after all | 12:36 |
| falktx | divided into 18 separate files | 12:36 |
| drobilla | $ time lv2info http://code.google.com/p/amsynth/amsynth > /dev/null | 12:37 |
| drobilla | 12:37 | |
| drobilla | real0m1.871s | 12:37 |
| falktx | drobilla: I forgot to tell you that was running on valgrind :P | 12:37 |
| drobilla | lol | 12:37 |
| drobilla | Yes, that makes a wee difference :P | 12:37 |
| falktx | running software in my pc in valgrind sorta matches the speed of the MOD :P | 12:38 |
| drobilla | heh | 12:38 |
| falktx | valgrind is still slightly slower | 12:38 |
| drobilla | There are a lot of .000000 in the preset files | 12:40 |
| drobilla | 187K of useless 0's | 12:40 |
| drobilla | (Probably not significant, just the only thing obvious to shrink) | 12:41 |
| drobilla | falktx: Speaking of presets, what do you consider to be a preset for a graph/pedalboard? | 12:43 |
| drobilla | falktx: All the control values for everything inside? | 12:43 |
| falktx | something like that yes | 12:43 |
| falktx | the connections and plugins loaded are the same, but the values for plugin controls will change | 12:44 |
| drobilla | One option for this is that lilv could provide a streaming interface if you want to scan files for particular information but not keep them loaded | 13:07 |
| *** NickSB2 has quit IRC | 13:18 | |
| *** ssj71 has joined #lv2 | 15:33 | |
| falktx | drobilla: I can't call lilv_world_load_all twice without getting duplicates. is this a bug or a feature? | 15:50 |
| drobilla | falktx: define "duplicates" | 16:05 |
| falktx | well this: | 16:05 |
| falktx | lilv_world_add_plugin(): error: Duplicate plugin <http://moddevices.com/plugins/tap/autopan> | 16:05 |
| falktx | lilv_world_add_plugin(): error: ... found in file:///home/falktx/.lv2//tap-autopan.lv2/ | 16:05 |
| falktx | lilv_world_add_plugin(): error: ... and file:///home/falktx/.lv2//tap-autopan.lv2/ | 16:05 |
| falktx | drobilla: it doesn't always happen. | 16:06 |
| drobilla | It is a feature to avoid actual duplicates | 16:06 |
| drobilla | In this case, I don't know | 16:06 |
| falktx | I'll see if I can get a reproduceable case | 16:06 |
| falktx | seems just random | 16:07 |
| drobilla | That's odd | 16:07 |
| drobilla | (The trouble with reloading that way is that no statements will be removed) | 16:07 |
| falktx | oh wait | 16:07 |
| falktx | perhaps it's not random... | 16:08 |
| drobilla | I assure you there is no if (rand() % 2) load_file() in there :) | 16:08 |
| falktx | ah, it happens when I add a new bundle (in the filesystem, not via lilv api) | 16:09 |
| drobilla | Bundle must contain a duplicate... | 16:10 |
| falktx | nope, I just copied the folder to .lv2 | 16:10 |
| falktx | and LV2_PATH is set to only .lv2 | 16:10 |
| drobilla | It must know about the plugin somehow | 16:11 |
| drobilla | I'd guess you're explicitly loading the bundle as well? | 16:11 |
| falktx | actually no need to copy anything | 16:11 |
| falktx | calling lilv_world_load_all twice is enough (I thought this wasn't the case) | 16:12 |
| falktx | if I call lilv_world_load_all() 2 times, I get the duplicates | 16:12 |
| drobilla | Presumably you will get a "duplicate" for every plugin found, yes | 16:12 |
| falktx | drobilla: so, ahem, is this a bug or a feature? | 16:12 |
| drobilla | mu | 16:12 |
| drobilla | It's just not written for this | 16:13 |
| drobilla | and I don't think it can be, because to work correctly it would have to destroy plugins (and basically everything else) | 16:13 |
| drobilla | Some mechanism to explicitly do this and/or notify the host that things have gone away is required, as discussed earlier | 16:14 |
| falktx | perhaps a lilv_world_load_new_bundles ? | 16:14 |
| drobilla | If you don't have a bunch of LilvFoo* pointers hanging around, it's certainly way easier to just nuke the world | 16:14 |
| drobilla | If you do, then we'll need to do that | 16:14 |
| drobilla | falktx: Hm. That seems reasonable | 16:15 |
| drobilla | and/or load_bundle itself could just skip the bundle if it's already loaded, like files | 16:15 |
| falktx | loading new bundles that appeared in the world sounds very useful | 16:15 |
| falktx | I know removing is tricky, so I'm not bothered with that | 16:15 |
| drobilla | Also realtively easy and not burdened with the infinitely recursive hell of horrible problems that this shit usually brings up | 16:16 |
| drobilla | lilv_world_load_bundle returns void | 16:16 |
| drobilla | Sigh, I really need to get out of the habit of making anything in a API return void ever | 16:17 |
| falktx | drobilla: btw, a question. if I do lilv_world_unload_bundle, replace the bundle with new contents, and then lilv_world_load_bundle. can that work? | 16:19 |
| drobilla | The resulting model will be correct | 16:20 |
| drobilla | But lilv has zero mechanism currently for removing objects like LilvPlugin* | 16:20 |
| drobilla | At all. | 16:20 |
| drobilla | Ever. | 16:20 |
| drobilla | At all. In any way. | 16:20 |
| * drobilla never wants to have to say this again :) | 16:20 | |
| falktx | keeping the old pointers is a good thing | 16:21 |
| falktx | they might be in use, so no complaints | 16:21 |
| drobilla | Not if they no longer exist it isn't | 16:21 |
| drobilla | Well, I guess some things might kind of work mostly sort of sometimes | 16:22 |
| drobilla | But the plugin list itself might be wrong | 16:22 |
| falktx | my question is rather if the plugin I ask for after load-bundle, if it's going to be the new contents, or the old contents | 16:22 |
| drobilla | I guess it could set the plugin as invalid and you're required to check that for everything if you ever do this | 16:22 |
| drobilla | mmm | 16:23 |
| drobilla | it will drop everything in that bundle | 16:23 |
| drobilla | but the loaded files list might not be updated for all the seeAlsos. I'm not sure | 16:24 |
| drobilla | I think, no. Back to needing plugin removal | 16:25 |
| drobilla | It would need to find all the files loaded from that bundle and unload them, or at least remove them from the loaded files list, since effectively the actual data is unloaded anyway | 16:27 |
| drobilla | i.e. the thing at the end of lilv_world_add_plugin() but backwards | 16:27 |
| drobilla | except it needs to check that the file is actually within the bundle | 16:31 |
| drobilla | ... and blissfully assume there are no cross-bundle seeAlso links | 16:31 |
| drobilla | Which is probably totally unsafe | 16:31 |
| drobilla | Meaning a file refrence count is needed. Whee! | 16:31 |
| drobilla | falktx: I think it might actually be *no* contents | 16:37 |
| drobilla | falktx: That should be fixed | 16:37 |
| falktx | this seems overly complex :( | 16:38 |
| drobilla | Well, yep. | 16:38 |
| drobilla | But inherently so. | 16:38 |
| falktx | I'll just do a "killall mod-host" and let it auto-restart | 16:38 |
| drobilla | It wouldn't be complex at all if it were just a model and none of this pretend to be a bunch of C objects shit was in there, but c'est la vie | 16:39 |
| drobilla | Actually the above is not quite right, load_bundle does not load all the (e.g.) plugin data files | 16:40 |
| drobilla | But getting anything from the plugin does | 16:40 |
| drobilla | That seems excessive, but that'll surely work anyway | 16:42 |
| drobilla | Thing is, if you have so much state around that reloading the worl entirely isn't feasible, there's a very good chance you don't want junk Plugin etc handles around either | 16:42 |
| drobilla | You think you do right now, but it'll probably bite you in the ass a whole lot harder later | 16:43 |
| falktx | that's why for my c lilv discovery code I only store 2 lilv pointers | 16:43 |
| falktx | the world itself and the get_all_plugins return value | 16:43 |
| drobilla | So why can't you just nuke it? | 16:44 |
| falktx | I can | 16:44 |
| falktx | the issue is mod-host | 16:44 |
| drobilla | "my" is not mod-host above? | 16:44 |
| falktx | mod-host is a separate tool | 16:44 |
| falktx | I needed a fast way to get all data, a simple python ctypes thing with custom C lilv code is the best for this | 16:45 |
| falktx | previously I was using py-lilv, but even that was getting a bit slow | 16:46 |
| drobilla | OK | 16:46 |
| drobilla | Well, the only way I see of doing this is to add a callback to notify the app that some resource is now gone | 16:46 |
| drobilla | If that thing is a plugin or pluginclass, the lists in the world are now junk | 16:47 |
| drobilla | I think those are the only things where that's an issue | 16:47 |
| drobilla | I will fix the unload reload thing, anyway | 16:51 |
| drobilla | The rest, I don't know. More API needed. It was probably a mistake to keep the plugin list around in the world | 16:52 |
| *** edogawa has joined #lv2 | 16:52 | |
| drobilla | What do you plan to do if the plugin *is* loaded in a current pedalboard and it's removed, anyway? | 16:55 |
| falktx | we are making a distinction between live usage and setup | 17:18 |
| falktx | during setup (installing, removing) supposedly the audio won't run | 17:18 |
| falktx | although I'd prefer if everything was dynamic | 17:20 |
| *** sigma6 has quit IRC | 17:20 | |
| falktx | I need to get this new code working first, almost there... | 17:20 |
| *** rncbc has joined #lv2 | 17:30 | |
| *** uncle-j_j has joined #lv2 | 17:53 | |
| drobilla | Well, I need to focus on Real Work⢠right now, but I'll make unload_bundle unload any contained resources, and fire a callback to notify the host | 17:54 |
| drobilla | What to do in that case is the host's problem, but if you unload then re-load and the plugin is properly the same or a newer version, you'll get the new data and it'll be fine | 17:54 |
| drobilla | Don't know how painful wrapping a callback in Python via swig will be, there currently are none | 17:54 |
| falktx | that will be awesome | 17:56 |
| drobilla | Probably needs a lilv_plugin_is_zombie() and lilv_world_drop_plugin() or some such on top of that | 17:59 |
| drobilla | But this can be considered separately | 17:59 |
| falktx | drobilla: btw this you're working on this. some of the lilv api comments say to use lilv_uri_to_path, but that's deprecated | 18:01 |
| falktx | those should change to lilv_file_uri_parse | 18:01 |
| falktx | *btw since | 18:01 |
| drobilla | Hm, k. Thought I fixed that | 18:03 |
| falktx | oh you did, my files are still a bit behind | 18:10 |
| falktx | (asking, not stating) | 18:10 |
| falktx | drobilla: I still see it in http://dev.drobilla.net/browser/trunk/lilv/lilv/lilv.h#L753 for example | 18:11 |
| drobilla | Yes, some are still there, I just looked in mine | 18:11 |
| *** son0p has quit IRC | 18:12 | |
| drobilla | Bloody escaping, PITA... | 18:12 |
| *** son0p has joined #lv2 | 18:13 | |
| drobilla | Bleh, changes here, changes there... I seriously need to migrate to git already | 18:24 |
| *** starsun has joined #lv2 | 20:01 | |
| *** starsun has left #lv2 | 20:06 | |
| *** ricardocrudo has joined #lv2 | 20:17 | |
| *** ricardocrudo has quit IRC | 20:28 | |
| *** edogawa has quit IRC | 20:53 | |
| *** edogawa has joined #lv2 | 20:58 | |
| *** edogawa has quit IRC | 21:05 | |
| *** edogawa has joined #lv2 | 21:08 | |
| *** falktx has quit IRC | 21:35 | |
| *** uncle-j_j1 has joined #lv2 | 21:50 | |
| *** uncle-j_j has quit IRC | 21:50 | |
| *** uncle-j_j1 has quit IRC | 21:59 | |
| *** falktx has joined #lv2 | 22:03 | |
| *** edogawa has quit IRC | 22:44 | |
| *** rncbc has quit IRC | 23:09 | |
| *** artfwo has quit IRC | 23:27 | |
| drobilla | finally | 23:43 |
| drobilla | One of the benefits of being a parallel computing researcher is that experiment times tend to be measured in the days so you can do other things in the mean time while still technically getting work done :) | 23:44 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!