*** JaVelDa has quit IRC | 02:32 | |
*** JaVelDa has joined #lv2 | 02:32 | |
*** oofus_lt has joined #lv2 | 06:19 | |
*** gianMOD has joined #lv2 | 06:21 | |
*** oofus_lt has quit IRC | 06:44 | |
*** oofus_lt has joined #lv2 | 06:45 | |
*** gianMOD has quit IRC | 06:53 | |
*** gianMOD has joined #lv2 | 06:58 | |
*** oofus_lt has quit IRC | 07:04 | |
*** JaVelDa has left #lv2 | 07:24 | |
*** JaVelDa has quit IRC | 07:24 | |
*** JaVelDa has joined #lv2 | 07:26 | |
*** sigma6 has joined #lv2 | 07:36 | |
*** gianMOD has quit IRC | 08:41 | |
*** gianMOD has joined #lv2 | 08:45 | |
*** trebmuh has joined #lv2 | 08:45 | |
*** ugjka has quit IRC | 09:06 | |
*** jbitdrop has joined #lv2 | 09:08 | |
*** ugjka has joined #lv2 | 09:11 | |
*** gianMOD has quit IRC | 09:14 | |
*** gianMOD has joined #lv2 | 09:20 | |
*** Yruama_Lairba has joined #lv2 | 10:17 | |
*** gianMOD has quit IRC | 10:21 | |
*** gianMOD has joined #lv2 | 10:22 | |
*** gianMOD has quit IRC | 11:07 | |
*** gianMOD has joined #lv2 | 11:07 | |
*** gianMOD has quit IRC | 11:11 | |
*** ocbtec has joined #lv2 | 11:19 | |
*** gianMOD has joined #lv2 | 12:05 | |
*** gianMOD has quit IRC | 13:10 | |
*** gianMOD has joined #lv2 | 13:15 | |
*** gianMOD has quit IRC | 13:49 | |
*** gianMOD has joined #lv2 | 13:57 | |
*** gianMOD has quit IRC | 14:13 | |
*** gianMOD has joined #lv2 | 14:14 | |
*** gianMOD has quit IRC | 14:16 | |
*** rncbc has joined #lv2 | 14:23 | |
rncbc | rgareus: hi again | 14:24 |
---|---|---|
rncbc | rgareus: jfyi. got rid of that lv2_atom_forge_is_object_type() crap today, and with that goes forge->Resource down the drain, in qtractor that is | 14:26 |
rgareus | cool. I take it, the code is also "cleaner" now. | 14:28 |
rncbc | rgareus: t6he Go3 aka. V1 suite has it ready re. StateChanged aka. Dirty whatnot:) | 14:29 |
rncbc | s/t6he/the/ | 14:32 |
rncbc | rgareus: however im not rly sure whether it should be implemented, on the V1s i mean--most of that stuff has been workaround'ed with some bad old hacks and threading :) | 14:35 |
rncbc | rgareus: i meaning on the plugin context | 14:35 |
rgareus | rncbc: in my case it's only synths. you can set some parameters using MIDI-CC or bind controls to MIDI. and those cannot be exposed as "normal" parameters | 14:36 |
rncbc | rgareus: thing is, V1s state are complete described by lv2 input control ports _and_ lv2 properties, attotw | 14:37 |
rgareus | rncbc: then you don't need it. | 14:37 |
rgareus | except if you still allow to "override" input control ports | 14:37 |
rgareus | using MIDI or GUI. ie the host does not change the input control port itself. | 14:38 |
rncbc | rgareus: since 0.7.5 (as of late june) all input control ports and midi controllable parameters are different internal computational entities | 14:39 |
rncbc | rgareus: that is to say that lv2 input control ports _and_ MIDI contrller assignments (which include CC, RPN, NRPN and even CC14bit) do concurr to the same subject parameter | 14:42 |
rgareus | rncbc: how do you resolve ambiguity? | 14:43 |
rgareus | ie a host sets a input-control to "27" and at the same time sends a MIDI-CC that'd set the mapped parameter to "48" | 14:43 |
rncbc | rgareus: inputs are polled to change in valçue (with 0.1% tolerance) | 14:43 |
*** gianMOD has joined #lv2 | 14:44 | |
rncbc | rgareus: and last value is cached | 14:44 |
rncbc | rgareus: some input is even smoothed (maximum slew rate is applied) | 14:45 |
rgareus | so 1) set input to 27. -> plugin uses 27. 2) send MIDI-CC to set it to 48 .. -> input is still 27, plugin uses 48 | 14:46 |
rgareus | 3) save + quit 4) re-open session -> host sets input to "27" -> plugin wrongly uses 27 (and not 48) | 14:47 |
rncbc | rgareus: no quite. on case 2): plugin detects input changed from "27" to "48" and rectas accordingly | 14:47 |
rncbc | s/rectas/reacts | 14:48 |
rncbc | rgareus: that runs on the lv2:run context of cource | 14:48 |
rgareus | is the "48" saved somewhere (in custom state)? | 14:49 |
rncbc | rgareus: if the particular parameter/input port is not subject to smoothing, that occurs immediatly | 14:50 |
rgareus | that part is fine (mostly) | 14:50 |
rgareus | it's 3, 4 where it really falls apart. | 14:50 |
rncbc | rgareus: otherwise it gets ramped so that the new value will only be effective a few samples later | 14:51 |
rncbc | rgareus: thing is, from plugin pov, the parameter value is say double-buffered | 14:53 |
rncbc | rgareus: so that lv2 input control ports are never overwritten anymore (as once before) | 14:56 |
rgareus | rncbc: so you save the "current" and "buffered" values with the custom plugin state? | 14:58 |
rncbc | rgareus: nope. think of it as "they live" (Carpenter's movie pun:)) | 14:59 |
*** gianMOD has quit IRC | 14:59 | |
rncbc | rgareus: hint, hint "i have come here to chew bubblegum, and..." you know the thrill don't ya? :) | 15:03 |
rgareus | rncbc: you sound like drobilla :) | 15:03 |
rncbc | rgareus: dang. don't you get that line? i bet drobilla don't either | 15:05 |
rgareus | rncbc: no, I don't | 15:05 |
rgareus | rncbc: but for reference, like cinnamon gum. | 15:05 |
rncbc | rgareus: oh no. the lien follows as "... i'm out of bubblegum!" -- this is one of most crazy lines ina conspiracy theory comedy movie ever | 15:07 |
*** ugjka has quit IRC | 15:07 | |
rgareus | rncbc: in any case calling "StateChanged" in case the double-buffered value changes is good, then. | 15:09 |
rncbc | rgareus: maybe... the case at hand is, any change made from the lv2 input ports are, say, real changes to a lv2 plugin state. that gets noted in hosts like atractor alright, np. midi controller induced changes are, what? should they be considered changes in lv2 state? uh? | 15:13 |
*** ugjka has joined #lv2 | 15:13 | |
rncbc | s/atractor/qtractor ;) | 15:13 |
rgareus | heh | 15:14 |
rgareus | rncbc: do those plugins have a lv2:state interface? | 15:14 |
rncbc | yep | 15:14 |
rgareus | ...and that state changes when you send it a MIDI message. | 15:14 |
rgareus | and the host does not know about that lv2:state changing. Some MIDI message may change the state, some other MIDI message may not. | 15:15 |
rncbc | i get that there's a static state and there's a dynamic state | 15:16 |
rncbc | static state is what lv2 state is about; a dynamic state reflects currect run-time and performence, it might not be what you want to store in session | 15:17 |
rncbc | s/currect/current/ | 15:18 |
rncbc | s/performence/performance | 15:18 |
rncbc | i take it, for instance, that MIDI controller changes are not to be read as static state changes, but they maybe get saved, later n, as dynamic/current state changes. | 15:21 |
rncbc | s/later n/later on/ | 15:21 |
rncbc | iow. they don't go as dirty'ing the current state of the plugin, but it can and will be saved as snapshot if the user is pleased | 15:23 |
*** gianMOD has joined #lv2 | 15:24 | |
*** gianMOD has quit IRC | 15:29 | |
rncbc | rgareus: the former (my) dilemma, in the V1s context, all state changes are already handled and flagged as dirty, either indirectly as an input control port change, or directly as a property/patch change. | 15:30 |
rncbc | rgareus: so that hosts "know" when these plugin's lv2 state is invalid at any one time. | 15:32 |
rncbc | s/invalid/outdated/ | 15:33 |
*** edogawa has joined #lv2 | 15:36 | |
*** sigma6 has quit IRC | 16:09 | |
*** gianMOD has joined #lv2 | 16:38 | |
*** gianMOD has quit IRC | 16:39 | |
*** oofus_lt has joined #lv2 | 16:45 | |
*** oofus_lt has quit IRC | 16:47 | |
*** oofus_lt has joined #lv2 | 16:50 | |
*** oofus_lt has quit IRC | 17:00 | |
*** oofus_lt has joined #lv2 | 17:01 | |
*** dsheeler has quit IRC | 19:12 | |
*** ocbtec has quit IRC | 19:12 | |
*** gianMOD has joined #lv2 | 19:30 | |
*** oofus_lt has quit IRC | 19:35 | |
*** gianMOD has quit IRC | 20:46 | |
*** gianMOD has joined #lv2 | 21:03 | |
*** rncbc has quit IRC | 21:41 | |
*** gianMOD has quit IRC | 22:26 | |
*** edogawa has quit IRC | 22:36 | |
*** gianMOD has joined #lv2 | 22:41 | |
*** gianMOD has quit IRC | 23:33 | |
*** jbitdrop has quit IRC | 23:50 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!