| *** artfwo has joined #lv2 | 00:28 | |
| *** falktx has quit IRC | 00:40 | |
| *** NickSB2 has joined #lv2 | 02:05 | |
| *** artfwo has quit IRC | 02:38 | |
| *** son0p has quit IRC | 05:39 | |
| *** son0p has joined #lv2 | 05:41 | |
| *** son0p has quit IRC | 05:51 | |
| *** son0p has joined #lv2 | 05:58 | |
| *** ricardocrudo has joined #lv2 | 07:15 | |
| *** edogawa has joined #lv2 | 07:19 | |
| *** edogawa has quit IRC | 07:25 | |
| *** edogawa has joined #lv2 | 07:27 | |
| *** ricardocrudo has quit IRC | 07:41 | |
| *** falktx has joined #lv2 | 08:10 | |
| *** drobilla` has joined #lv2 | 08:17 | |
| *** drobilla has quit IRC | 08:20 | |
| *** drobilla` has quit IRC | 08:27 | |
| *** sigma6 has joined #lv2 | 08:48 | |
| *** edogawa has quit IRC | 09:37 | |
| *** edogawa has joined #lv2 | 09:39 | |
| *** edogawa has quit IRC | 09:46 | |
| *** edogawa has joined #lv2 | 09:49 | |
| falktx | lilv_state_new_from_world is crashing for me | 10:11 |
|---|---|---|
| falktx | ah it's lilv_state_restore | 10:18 |
| falktx | cmon | 10:25 |
| falktx | the code doesn't check if the state interface is null or not, just assumes it's not... | 10:25 |
| falktx | so lilv build is broken and when fixed has a serious regression (crash) in it | 10:35 |
| falktx | I know drobilla is busy and rushes things a bit, but hmm, at least he could test the build before pushing | 10:35 |
| *** son0p has quit IRC | 11:08 | |
| *** son0p has joined #lv2 | 11:15 | |
| falktx | bypass and cv ports is confusing | 11:34 |
| falktx | also, perhaps midi plugins should bypass the midi too? | 12:09 |
| falktx | the plugin really needs to be the one that does bypass | 12:11 |
| falktx | rgareus: do you know what the conversation about this ended up? any consensus? | 12:12 |
| rgareus | plugin provided bypass? | 12:16 |
| *** badosu_ has quit IRC | 12:18 | |
| rgareus | it ended up a bit on the complex side: input for host to request, output for plugin to acknowledge. 3 state enum {bypassed, latency-corrected bypass, active} | 12:20 |
| rgareus | there was consensus that this is the way to go, but nobody really was enthousiastic about it. | 12:21 |
| rgareus | an alternative would be to use Atom messages instead.. but not everyone likes LV2 Atoms. | 12:22 |
| falktx | what's the difference between no 1 and 2 bypass modes? | 12:22 |
| rgareus | bypass: the signal is passed though as-is. latency-corrected bypass: the signal is delayed by the same time as processing would do. | 12:23 |
| rgareus | but no processed | 12:23 |
| falktx | do we need that distinction? | 12:24 |
| falktx | I think the plugin would always do #2 | 12:24 |
| rgareus | switching from bypassed to active are 2 indepdent changes. signal delay and processing. doing both can't always be done glitch free | 12:25 |
| falktx | of course | 12:25 |
| rgareus | falktx: most plugins can just ignore #1 | 12:25 |
| falktx | I'd make a rule that said that plugins that have latency, when bypassed they delay by that same latency value too | 12:26 |
| falktx | things get very confusing otherwise | 12:26 |
| falktx | rgareus: is there a reason for needing #1 ? | 12:26 |
| rgareus | yes, it's required to glitch free insert a plugin | 12:27 |
| rgareus | add a new plugin into the process graph. start completely bypassed.. no glitch | 12:28 |
| rgareus | move to state #1 -> no glitch | 12:28 |
| rgareus | normal operation #1 <-> #2 | 12:29 |
| rgareus | remove plugin #2 -> #1 -> #0 - remove from graph | 12:29 |
| * falktx is confused | 12:29 | |
| rgareus | if you remove the plugin while it has latency ie #2 -> #0 the audio will "jump" | 12:29 |
| rgareus | depending on what DSP the plugin has the transition between each states may take time. hence the plugin needs to announce its state | 12:30 |
| rgareus | some simple plugins may immediately (1 process cycle) transition states. some others may require e.g 1 second... | 12:31 |
| rgareus | the means to remove latency also depends on what the plugin does. could be a simple x-fader (though tha usually introduces comb-filtering) | 12:32 |
| rgareus | or an interpolated delayline (re-sample) | 12:32 |
| rgareus | there is no one-size-fits-all solution, if there were. the host could do it | 12:33 |
| *** artfwo has joined #lv2 | 12:37 | |
| falktx | ok I understood it all except the first sentence | 12:44 |
| falktx | if you remove a plugin that has latency the host is the one that has to compensate | 12:44 |
| *** badosu has joined #lv2 | 13:24 | |
| *** drobilla` has joined #lv2 | 14:10 | |
| *** drobilla` has quit IRC | 14:18 | |
| *** NickSB2 has quit IRC | 14:26 | |
| *** son0p has quit IRC | 14:31 | |
| *** drobilla` has joined #lv2 | 14:38 | |
| *** son0p has joined #lv2 | 14:38 | |
| *** son0p has quit IRC | 14:44 | |
| *** son0p has joined #lv2 | 14:46 | |
| *** drobilla` has quit IRC | 14:51 | |
| *** son0p has quit IRC | 14:52 | |
| *** son0p has joined #lv2 | 14:53 | |
| *** son0p has quit IRC | 15:20 | |
| *** son0p has joined #lv2 | 15:22 | |
| *** deva has joined #lv2 | 16:13 | |
| *** son0p has quit IRC | 16:29 | |
| *** son0p has joined #lv2 | 16:31 | |
| *** sigma6 has quit IRC | 17:10 | |
| *** drobilla` has joined #lv2 | 17:35 | |
| *** falktx has quit IRC | 17:37 | |
| *** falktx has joined #lv2 | 18:09 | |
| *** rncbc has joined #lv2 | 18:15 | |
| *** rncbc has quit IRC | 18:21 | |
| *** drobilla` is now known as drobilla | 18:25 | |
| *** deva has quit IRC | 18:45 | |
| *** rncbc has joined #lv2 | 19:24 | |
| *** drobilla has quit IRC | 19:29 | |
| *** uncle-j_j has joined #lv2 | 20:53 | |
| *** drobilla has joined #lv2 | 21:14 | |
| *** falktx has quit IRC | 22:47 | |
| *** rncbc has quit IRC | 22:54 | |
| drobilla | 10 points for the shortest / most reasonable name for the root graph in Ingen | 23:02 |
| rgareus | she's called Joe. | 23:09 |
| rgareus | "main" or "top" | 23:11 |
| rgareus | "top" is cool, since Joe sometimes attends topless bars :) | 23:11 |
| drobilla | heh | 23:11 |
| drobilla | Hm, actually top isn't half bad, I hadn't thought of that one | 23:11 |
| rgareus | she then crashes... | 23:12 |
| drobilla | It's the first component of the path of any visual object on the canvas, which is developer visible and only kinda sorta a little bit user visible | 23:12 |
| drobilla | But it will also be the name of the file in the bundle, which is ultra user visible | 23:12 |
| drobilla | (Until we get some kind of fancy directories as files thing like OSX, but I'm not holding my breath on that one) | 23:13 |
| rgareus | "home" maybe from a user's POV a "home" button conveys "top/root/main" | 23:13 |
| drobilla | Currently "graph" | 23:13 |
| drobilla | Considered root, which is alright, but a bit of a misnomer as it's not the root of the path hierarchy... though it is the root of the audio stuff | 23:14 |
| rgareus | root-node. | 23:14 |
| drobilla | /BaseAudioProcessingGraphFactory | 23:14 |
| rgareus | still for a modular "root-node" sounds odd. | 23:14 |
| rgareus | how about "well" as in "spring, source" | 23:16 |
| drobilla | Getting a little to creative now :) | 23:16 |
| rgareus | indeed | 23:17 |
| rgareus | "origin" | 23:17 |
| rgareus | "genesis" | 23:17 |
| drobilla | adam | 23:18 |
| drobilla | We can be both religiously and genderically offensive | 23:18 |
| * drobilla just invented that word | 23:18 | |
| rgareus | the OSX version will have Eve | 23:19 |
| rgareus | re " name of the file in the bundle" -> "state" | 23:25 |
| drobilla | They should be the same | 23:25 |
| drobilla | General idea is that the bundle is a representation of the server and all the paths line up | 23:26 |
| rgareus | simply "ingen" | 23:26 |
| drobilla | ... there is that, I suppose | 23:26 |
| drobilla | Though kind of suggests the engine itself, which is a different thing | 23:27 |
| *** edogawa has quit IRC | 23:39 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!