| *** NickSB2 has joined #lv2 | 00:04 | |
| *** falktx__ has quit IRC | 00:32 | |
| *** NickSB2 has quit IRC | 01:03 | |
| *** edogawa has joined #lv2 | 07:16 | |
| *** falktx has joined #lv2 | 07:34 | |
| *** Anchakor has quit IRC | 08:13 | |
| *** Anchakor has joined #lv2 | 08:15 | |
| *** ricardocrudo has joined #lv2 | 08:22 | |
| *** NickSB2 has joined #lv2 | 08:38 | |
| *** ddom has joined #lv2 | 08:55 | |
| *** bgola_ is now known as bgola | 09:45 | |
| *** bgola has quit IRC | 10:43 | |
| *** bgola has joined #lv2 | 10:43 | |
| *** ventosus has joined #lv2 | 11:05 | |
| *** ssj71 has quit IRC | 11:28 | |
| *** sigma6 has quit IRC | 12:34 | |
| *** NickSB2 has quit IRC | 13:49 | |
| *** falktx has quit IRC | 15:31 | |
| *** ricardocrudo has quit IRC | 15:34 | |
| *** rncbc has joined #lv2 | 16:10 | |
| *** ddom has quit IRC | 16:13 | |
| *** rncbc has quit IRC | 16:34 | |
| *** gabrbedd has joined #lv2 | 16:41 | |
| *** flexus has joined #lv2 | 16:43 | |
| *** ricardocrudo has joined #lv2 | 17:46 | |
| *** flexus has quit IRC | 17:48 | |
| *** flexus has joined #lv2 | 17:53 | |
| *** ricardocrudo has quit IRC | 18:54 | |
| *** NickSB2 has joined #lv2 | 19:12 | |
| *** flexus has quit IRC | 20:26 | |
| *** falktx__ has joined #lv2 | 20:53 | |
| *** ventosus has left #lv2 | 21:13 | |
| *** edogawa has quit IRC | 22:16 | |
| rgareus | falktx__: testing lv2-port count scalability http://pastebin.com/Uex9xXsx | 22:21 |
|---|---|---|
| rgareus | it's not a real valid test (easily fooled by compiler optimization). but a baseline | 22:22 |
| rgareus | I suppose a real test (plugin in host, compiled with optimization) would be more meaningful though I don't expect the value to change dramatically | 22:23 |
| falktx__ | param[] is not set | 22:24 |
| falktx__ | you should set those values to something | 22:24 |
| rgareus | they're set to some random value that's on the stack | 22:25 |
| rgareus | but sure, feel free to improve things | 22:25 |
| falktx__ | stack values are random, can be inf, nan, denormal or some other weird number | 22:26 |
| rgareus | I just wanted a quick test. on i386 (X60s) overhead for 2K parameters is 9% | 22:26 |
| falktx__ | rgareus: the overhead and big param list is not my main issue/concern here | 22:26 |
| falktx__ | rgareus: it's hiding things and implementing them plugin side | 22:26 |
| falktx__ | the host is the one that should decide what to do regarding midi-cc | 22:27 |
| rgareus | how can in case of synths? | 22:27 |
| falktx__ | that's what we need to figure out | 22:28 |
| falktx__ | if you're going to list them as lv2:parameters and changing values happens through an atom event, that's cool for me | 22:28 |
| rgareus | send a CC-7 volume request. Note-on, note-off, CC-7 volume other-note on. | 22:28 |
| falktx__ | that gets rid of the big float array overhead | 22:28 |
| rgareus | if the volume would be a control-port you can only set it once per cycle | 22:29 |
| falktx__ | rgareus: carla subdivides the buffer | 22:29 |
| rgareus | split cycle | 22:29 |
| falktx__ | yeah | 22:29 |
| falktx__ | but with lv2:parameters + atom events this is not an issue | 22:30 |
| falktx__ | atom events are timestamped | 22:30 |
| rgareus | yes +1 for using Atoms | 22:30 |
| rgareus | that's also the plan I have in mind for controls | 22:30 |
| rgareus | just send a LV2:Patch | 22:30 |
| falktx__ | patch:set param:that_thing 1.23f ? | 22:31 |
| falktx__ | something like that? | 22:31 |
| rgareus | yes | 22:31 |
| falktx__ | ok, then I guess we just need to agree on some format for this | 22:31 |
| falktx__ | instead of lv2:ports provide lv2:parameters | 22:31 |
| falktx__ | hopefully in some way that makes portProperties/range/designation also work | 22:33 |
| falktx__ | rgareus: perhaps port type lv2:Parameter? | 22:33 |
| falktx__ | http://lv2plug.in/ns/lv2core/#Parameter | 22:33 |
| rgareus | I thought it's atom:supports patch:Message | 22:33 |
| falktx__ | yeah, but you need to expose those parameters to the host | 22:34 |
| falktx__ | so it can show them to user, do midi bindings, etc etc | 22:34 |
| *** Anchakor has quit IRC | 22:35 | |
| rgareus | IIUC, you query them on demand | 22:35 |
| falktx__ | hmm | 22:35 |
| falktx__ | so dynamic ports? | 22:35 |
| rgareus | patch:wildcard will get you all of them | 22:36 |
| falktx__ | but that implies the host has enough space on the rt atom buffer for it | 22:36 |
| falktx__ | I doubt it will | 22:36 |
| rgareus | I'd like to hear drobilla's opinion about this. I don't know what exactly he had in mind there | 22:36 |
| falktx__ | I'd love to hear *anything* from drobilla | 22:37 |
| falktx__ | he's been offline for a few days now | 22:37 |
| rgareus | well, a plugin can specify a min required atom buffer size | 22:38 |
| rgareus | if a plugin has 2M parameters, it should say so and request a minSize of a few MB. | 22:38 |
| falktx__ | heh... hmmm | 22:38 |
| falktx__ | I'd prefer if that data was on the ttl in the first place | 22:39 |
| rgareus | 200MB of ttl | 22:39 |
| rgareus | how are you planning to trackle this with zynaddsubfx? | 22:40 |
| falktx__ | optmize lilv! :P | 22:40 |
| falktx__ | rgareus: I must say this is a nice case for LV2 | 22:41 |
| falktx__ | I really want to have the midi-cc handled host-side. but it's proving difficult | 22:41 |
| rgareus | heh, I don't think liblilv will be the bottleneck. | 22:42 |
| rgareus | well, you could intercept it. and generate a http://lv2plug.in/ns/ext/midi/#controllerNumber or something | 22:43 |
| falktx__ | the thing is here, as you read on the emails, someone is using osc to control plugins in carla | 22:44 |
| rgareus | ardour does the same. It parses Input -> midi-CC -> Controllable/Automatable Param/Disk -> generate CC -> plugin | 22:44 |
| falktx__ | that is not possible with setbfree right now | 22:44 |
| falktx__ | the host needs to know about the plugin params for this | 22:45 |
| rgareus | right. execpt with ssj's OSC to midi. | 22:45 |
| falktx__ | rgareus: so the host can know what midi-ccs the plugin is using internally, right? | 22:45 |
| rgareus | falktx__: setBfree -m /tmp/midnam.xml and you have a complete list of bindings | 22:45 |
| rgareus | ardour can read midnam | 22:45 |
| rgareus | and give nice names to them. | 22:46 |
| rgareus | it's a hack to abuse it in this case. | 22:46 |
| rgareus | but it was something to whip up easily for testing, since there was already midnam support in A3. | 22:46 |
| * rgareus is not an XML fan | 22:47 | |
| falktx__ | not sure if I like that "solution" | 22:48 |
| rgareus | well, we need a LV2 way to "list all current [midi bound]? properties". | 22:49 |
| falktx__ | ttl? :P | 22:49 |
| rgareus | dynamically | 22:49 |
| falktx__ | why does it have to be dynamic? | 22:50 |
| rgareus | bindings can change | 22:51 |
| rgareus | I didn't want to come up with a spec for this while hacking.. so I just re-used the existing midnam spec for the time being. | 22:51 |
| rgareus | IIUC rncbc has the same issue. depending on plugin-state bindings differ | 22:52 |
| falktx__ | you can still can change the bindings | 22:52 |
| falktx__ | if you export all the parameters used by the plugin, that will be changed via patch messages, the host becomes in control | 22:52 |
| rgareus | except the plugin can do more fancy things and report back value or simply not http://lv2plug.in/ns/ext/patch/#Ack them | 22:53 |
| rgareus | ie the host is in control, but the plugin can refuse to do dumb things | 22:54 |
| falktx__ | then I guess we're back to square one | 22:57 |
| rgareus | ? | 22:57 |
| falktx__ | rgareus: let's discuss this again once drobilla gets more online | 22:57 |
| rgareus | the alternative is to add something like AUDependentParameter | 22:58 |
| rgareus | a "parameter whose value can change in response to a change in its parent metaparameter" in Apple land | 22:58 |
| rgareus | but that would not solve the issue of countless ports. | 22:58 |
| falktx__ | tbh I think countless ports is the least of our issues | 22:59 |
| rgareus | well, setBree's config is around a Million [floats]. ~4 MB packed in a struct. | 23:00 |
| falktx__ | shall we give it a test? | 23:00 |
| rgareus | sure. that's why I started with http://pastebin.com/Uex9xXsx | 23:01 |
| rgareus | buta simple plugin (not fully fledged setBfree or zyn) will be a lot more convenient. | 23:02 |
| *** NickSB2 has quit IRC | 23:02 | |
| falktx__ | rgareus: I mean testing via patch messages, not control ports | 23:02 |
| *** ssj71 has joined #lv2 | 23:03 | |
| falktx__ | rgareus: 2M control ports are too much | 23:03 |
| rgareus | falktx__: yep. | 23:03 |
| falktx__ | I think 3000 is around the limit for this | 23:03 |
| rgareus | falktx__: it's on my ToDo list for this summer. sBf already has most of the infrastucture in place | 23:03 |
| rgareus | falktx__: I'd have also said around 1K. | 23:03 |
| falktx__ | drumsynth (from distrho ports) has 2000 control ports :) | 23:04 |
| rgareus | 500 - 5000 depending on CPU. | 23:04 |
| falktx__ | I have an i7 3.5GHz, and even better cpus are being released. | 23:04 |
| falktx__ | we should use them more | 23:04 |
| rgareus | fastest machine I have is an i5 2.6GHz | 23:05 |
| falktx__ | hm wait, it is 2600 ports | 23:05 |
| falktx__ | Port 2620: | 23:05 |
| falktx__ | Type: http://lv2plug.in/ns/lv2core#ControlPort | 23:05 |
| rgareus | for float-ctrl that's crazy. I thought Kontakt with its 512 directly exposed control ports is already over the top. | 23:06 |
| falktx__ | 512 is nothing on windows vst world | 23:07 |
| falktx__ | the crystall freeware plugin has 2000+ parameters | 23:07 |
| rgareus | isn't that even a hard limit in VST2+ | 23:07 |
| rgareus | ? | 23:07 |
| falktx__ | no | 23:07 |
| rgareus | but right. for VST you call setParameter on demand | 23:07 |
| rgareus | and getParameter() you don't iterate over all ports every cycle | 23:08 |
| falktx__ | yeah, the float arrays for params in lv2 was a bad design | 23:08 |
| rgareus | goes back to LADSPA, doesn't it? | 23:08 |
| falktx__ | yes | 23:08 |
| rgareus | and it's fine for a lot of simple things. | 23:08 |
| falktx__ | for direct parameters it's awesome | 23:09 |
| falktx__ | the plugin doesn't need to implement anything for parameters, the host does everything | 23:09 |
| falktx__ | but for complex things it's terrible | 23:09 |
| rgareus | I could not have said it better | 23:09 |
| falktx__ | shall we start the plans for lv3? ;) | 23:10 |
| rgareus | falktx__: will you still be in Berlin end of Oct? | 23:11 |
| * rgareus heard it thrugh the grapevine that loop.ableton.com will feature a panel on open-source | 23:12 | |
| falktx__ | rgareus: perhaps. we'll see how it goes soon | 23:12 |
| falktx__ | everything is still a bit uncertain | 23:12 |
| rgareus | on MOD sales, I suppose. | 23:13 |
| falktx__ | sorta | 23:14 |
| ssj71 | would a 16k object overrun the host's circular buffer between the work and audio threads? | 23:40 |
| falktx__ | maybe. better set the minimumSize | 23:45 |
| ssj71 | minimum size of the data the worker responds with? got an example? | 23:50 |
| ssj71 | It seems it was. I've got a hacky workaround that resolves it, but I'd like a cleaner solution | 23:51 |
| ssj71 | I guess I can mutex it in the worker thread | 23:53 |
| *** falktx__ has quit IRC | 23:54 | |
| rgareus | ssj71: for worker, I think so. | 23:55 |
| rgareus | worker responses are supposed to be short. a byte or four. | 23:56 |
| ssj71 | ok. I'll just store it in the plugin and have a flag that prevents concurrent loading | 23:57 |
| rgareus | jalv allocates 4096 bytes for the worker ringbuffer | 23:58 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!