| *** ricardocrudo has quit IRC | 00:06 | |
| *** falktx has joined #lv2 | 00:32 | |
| *** drobilla has quit IRC | 00:46 | |
| *** drobilla has joined #lv2 | 00:47 | |
| *** drobilla has quit IRC | 00:49 | |
| *** drobilla` has joined #lv2 | 00:50 | |
| *** gianMOD has joined #lv2 | 01:04 | |
| *** gianMOD has quit IRC | 01:09 | |
| *** falktx has quit IRC | 01:29 | |
| *** falktx has joined #lv2 | 01:37 | |
| *** NickSB2 has quit IRC | 05:29 | |
| *** gianMOD has joined #lv2 | 08:11 | |
| *** gianMOD has quit IRC | 09:05 | |
| *** falktx has quit IRC | 09:40 | |
| *** gianMOD has joined #lv2 | 10:06 | |
| *** gianMOD has quit IRC | 10:11 | |
| *** ddom has joined #lv2 | 10:16 | |
| *** gianMOD has joined #lv2 | 11:07 | |
| *** gianMOD has quit IRC | 11:11 | |
| *** NickSB2 has joined #lv2 | 11:16 | |
| *** gianMOD has joined #lv2 | 11:27 | |
| *** gianMOD has quit IRC | 11:52 | |
| *** falktx has joined #lv2 | 12:11 | |
| *** daste has joined #lv2 | 12:55 | |
| *** ricardocrudo has joined #lv2 | 13:02 | |
| *** gianMOD has joined #lv2 | 13:02 | |
| *** gianMOD has quit IRC | 13:07 | |
| *** gianMOD has joined #lv2 | 13:22 | |
| *** gianMOD has quit IRC | 13:22 | |
| *** gianMOD has joined #lv2 | 13:34 | |
| *** daste has quit IRC | 13:42 | |
| *** daste has joined #lv2 | 13:43 | |
| *** daste has quit IRC | 13:43 | |
| *** daste has joined #lv2 | 13:45 | |
| *** daste has quit IRC | 13:46 | |
| *** daste has joined #lv2 | 13:47 | |
| *** daste has quit IRC | 13:47 | |
| *** daste has joined #lv2 | 13:48 | |
| *** falktx has quit IRC | 14:10 | |
| *** falktx has joined #lv2 | 14:12 | |
| *** ricardocrudo has quit IRC | 14:33 | |
| *** falktx has quit IRC | 15:00 | |
| *** ricardocrudo has joined #lv2 | 15:01 | |
| *** NickSB2 has quit IRC | 16:43 | |
| *** ddom has quit IRC | 16:57 | |
| *** gianMOD has quit IRC | 17:02 | |
| *** zth has joined #lv2 | 17:19 | |
| *** gianMOD has joined #lv2 | 17:32 | |
| *** gianMOD has quit IRC | 17:32 | |
| *** daste has quit IRC | 17:46 | |
| *** gianMOD has joined #lv2 | 17:58 | |
| *** gianMOD has quit IRC | 18:02 | |
| *** ricardocrudo has quit IRC | 18:14 | |
| *** drobilla` is now known as drobilla | 18:15 | |
| *** gianMOD has joined #lv2 | 18:21 | |
| *** gianMOD has quit IRC | 18:22 | |
| *** gianMOD has joined #lv2 | 18:23 | |
| *** gianMOD has quit IRC | 18:23 | |
| *** ricardocrudo has joined #lv2 | 18:44 | |
| *** bgola_ is now known as bgola | 18:51 | |
| *** NickSB2 has joined #lv2 | 18:52 | |
| *** gianMOD has joined #lv2 | 19:07 | |
| *** gianMOD has quit IRC | 19:07 | |
| *** gianMOD has joined #lv2 | 19:07 | |
| *** gianMOD has quit IRC | 19:15 | |
| *** gianMOD has joined #lv2 | 19:16 | |
| *** falktx has joined #lv2 | 20:04 | |
| *** zth has quit IRC | 20:54 | |
| *** gianMOD has quit IRC | 20:55 | |
| *** ricardocrudo has quit IRC | 21:33 | |
| *** gianMOD has joined #lv2 | 22:06 | |
| *** gianMOD has quit IRC | 22:10 | |
| *** Anchakor__ has quit IRC | 22:17 | |
| *** Anchakor_ has joined #lv2 | 22:21 | |
| ColaEuphoria | I think I remember a few months back here there was a discussion about deactivating inactive plugins | 23:09 |
|---|---|---|
| ColaEuphoria | Should that onus be on the plugin manufacturer? | 23:09 |
| ColaEuphoria | like a simple if() check to see if the plugin's current state is working or not in run() | 23:11 |
| ColaEuphoria | `active` could be a boolean variable in a plugin and the plugin will set it whenever something happens, and a bonus is that the plugin knows if a zero value on the output buffer is actually silence or not | 23:13 |
| drobilla | Not sure what you're getting at. run() is not called for a deactivated plugin at all. | 23:16 |
| ColaEuphoria | Sorry, I meant the plugin developers should have a if() inside their run() and jump to simply filling the out buffer with zeros | 23:19 |
| ColaEuphoria | As opposed to doing a ton of DSP calculations that eventually end up to zeros anyway | 23:20 |
| ColaEuphoria | It's not actually "deactivating" the plugin. It's to ease CPU cycles when the plugin isn't doing anything I meant | 23:20 |
| drobilla | We have no facility for that. | 23:33 |
| drobilla | Knee-jerk is that the host can simply do this. | 23:33 |
| drobilla | I don't remember what the rationale for bothering plugins with it was. It's on the ML somewhere | 23:33 |
| drobilla | For when bypass isn't true bypass for whatever reasons, I suppose. | 23:33 |
| ColaEuphoria | I'm just saying I don't think we even need to concern ourselves with it because I believe the onus should be on the plugin developer to manage their CPU footprint. | 23:35 |
| drobilla | Who is "ourselves"? | 23:36 |
| ColaEuphoria | LV2 people | 23:36 |
| drobilla | That means the plugin needs to actually know about whether it is bypassed. Which means a spec modification that must be supported by both hosts and plugins | 23:36 |
| ColaEuphoria | I should stop being ambiguous | 23:36 |
| drobilla | That's quite a bit of being concerned about it ;) | 23:36 |
| ColaEuphoria | Oh, that's totally different than what I was thinking. Oops. Yeah that's perfectly reasonable | 23:37 |
| drobilla | Not really troublesome ABI-wise, just designate a control as whatever:bypass, but hosts still need to actually use it | 23:37 |
| ColaEuphoria | Has polyphony been discussed? I have my own thoughts on it, but I'm curious of anyone else's thoughts. | 23:42 |
| Anchakor | if you are concerned with saving CPU like that in your plugin code you would also want to do that when silence is being passed into an active plugin, so I'd say the bypass flag API isn't necessary | 23:44 |
| drobilla | That is another issue, but one doesn't make the other go away. | 23:45 |
| drobilla | ColaEuphoria: Not really, since most hosts wouldn't do anything worthwhile with individual voice access anyway | 23:45 |
| drobilla | Ingen just replicates, which is a bit crap, but since it'd typically be relatively low-level plugins in that scenario anyway, not really a huge deal | 23:46 |
| ColaEuphoria | What about plugin users or per-note automation? | 23:46 |
| drobilla | "plugin users"? | 23:46 |
| ColaEuphoria | anyone using LV2 plugins | 23:46 |
| ColaEuphoria | end users | 23:46 |
| drobilla | Per-note anything needs something that isn't MIDI. | 23:47 |
| drobilla | ......... end users use plugins via hosts. That's what a plugin is. | 23:47 |
| drobilla | The people-who-care:effort ratio is hyper low. Interesting, perhaps, but I'm personally more concerned with higher priority things, and cleaning up what's already there, etc. | 23:49 |
| ColaEuphoria | Probably not the right place for this, but is it really evil to have a plugin API process sample-in-sample-out as opposed to buffer-in-buffer-out? | 23:49 |
| drobilla | nframes=1. voila. | 23:50 |
| drobilla | (Which nobody does because the overhead is insanely high) | 23:50 |
| ColaEuphoria | Ah | 23:50 |
| ColaEuphoria | As for the paradigm, should LV2 plugins be low-level designs of component parts (ADSR, oscillators, filters, e.g.) or should they be monolithic, containing all of them in a single LV2? | 23:55 |
| drobilla | yes? | 23:56 |
| Anchakor | depends on what is your intended use case for them | 23:59 |
| Anchakor | for Ingen low-level components are useful, higher level plugins are useful in DAWs | 23:59 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!