| *** NickSB has quit IRC | 00:21 | |
| *** NickSB has joined #lv2 | 00:23 | |
| *** edogawa has quit IRC | 00:26 | |
| *** ColaEuphoria has quit IRC | 01:25 | |
| *** falktx has joined #lv2 | 04:10 | |
| *** falktx` has quit IRC | 04:14 | |
| *** ssj71 has quit IRC | 08:11 | |
| *** ventosus has joined #lv2 | 08:38 | |
| *** edogawa has joined #lv2 | 08:42 | |
| *** ocbtec has joined #lv2 | 09:25 | |
| *** ricardocrudo has joined #lv2 | 09:42 | |
| *** edogawa has quit IRC | 09:44 | |
| *** edogawa has joined #lv2 | 09:55 | |
| *** dsheeler has joined #lv2 | 10:21 | |
| *** falktx|work has joined #lv2 | 10:33 | |
| *** jbitdrop has joined #lv2 | 10:42 | |
| *** kwmiebach has quit IRC | 11:40 | |
| *** kwmiebach has joined #lv2 | 11:42 | |
| *** dsheeler has quit IRC | 12:04 | |
| *** jbitdrop is now known as jbitdropAFK | 13:03 | |
| *** NickSB2 has quit IRC | 14:06 | |
| *** jbitdropAFK is now known as jbitdrop | 14:33 | |
| *** dsheeler has joined #lv2 | 14:41 | |
| *** ocbtec is now known as ocbtec_AFK | 14:51 | |
| *** ocbtec_AFK is now known as ocbtec | 15:06 | |
| *** ssj71 has joined #lv2 | 16:08 | |
| *** son0p has quit IRC | 17:07 | |
| *** son0p has joined #lv2 | 17:15 | |
| *** sigma6 has quit IRC | 17:16 | |
| *** falktx|work has quit IRC | 18:11 | |
| *** rncbc has joined #lv2 | 18:43 | |
| *** ricardocrudo has quit IRC | 19:02 | |
| *** ventosus has left #lv2 | 19:31 | |
| *** rgareus has quit IRC | 20:20 | |
| *** grejppi has quit IRC | 20:20 | |
| *** EntropySink has quit IRC | 20:20 | |
| *** HarryHaaren has quit IRC | 20:20 | |
| *** rgareus has joined #lv2 | 20:20 | |
| *** EntropySink has joined #lv2 | 20:20 | |
| *** grejppi has joined #lv2 | 20:20 | |
| *** HarryHaaren has joined #lv2 | 20:21 | |
| *** ricardocrudo has joined #lv2 | 20:21 | |
| ssj71 | rgareus: I don't really follow entirely the "touch" idea of your automation. isn't the host the one going to "touch" the value of the plugin with the user-overriden value? | 20:38 |
|---|---|---|
| ssj71 | to me the plugin is always performing the analysis portion AND the processing portion | 20:39 |
| ssj71 | so IMO you could just have a pair of CVports at that point (e.g. after the envelope detection, before gain reduction) | 20:40 |
| ssj71 | if the plugin spat out its internal state through the CV (g.r. or pitch correction etc) the host could record that | 20:40 |
| ssj71 | then the host could optionally send data through the input CV to "override" the plugins internal calculated value | 20:41 |
| rgareus | ssj71: "touch" here means: add a guard point. | 20:41 |
| ssj71 | can you explain the guard point to me? | 20:41 |
| rgareus | ssj71: ie a point of previous existing automation dat. | 20:42 |
| rgareus | a | 20:42 |
| rgareus | ssj71: say you have a value "1" at time zero. | 20:42 |
| ssj71 | ok, in my proposal a host would have to split cycles if they didn't want to send data over some set of samples | 20:42 |
| ssj71 | I think I get the principle, just didn't know the terminology | 20:43 |
| rgareus | ssj71: and now you add a new point "0" at time 10 | 20:43 |
| ssj71 | you want it to remain at 1 until it reaches 10 | 20:43 |
| rgareus | ssj71: the host would "interpolate" ie draw a line from 1 ...0 so that at time 5 the value would be 0.5 | 20:44 |
| rgareus | but in this case you don't want that. | 20:45 |
| ssj71 | gotcha. | 20:47 |
| rgareus | ssj71: a good visualization is also 0:20 at https://www.youtube.com/watch?v=B0DKjABQ6MA | 20:47 |
| rgareus | the two points added at the beginning and end when deleting an automation-range are "guards" | 20:48 |
| rgareus | 0:28 in the video | 20:48 |
| ssj71 | right. makes sense. You only want to touch specific samples | 20:48 |
| rgareus | yep | 20:48 |
| ssj71 | but especially I think many of compressors and autotuners aren't needing atom ports at all | 20:49 |
| rgareus | it's a small detail and in many case may be irrelevant | 20:50 |
| rgareus | but not including it in the spec would IMHO be wrong. | 20:50 |
| ssj71 | I like the idea of the CV ports because it requires very little change to the plugin. Naturally since I don't write hosts :) | 20:53 |
| ssj71 | the host could just have the input CV port a null pointer to indicate that the internal calculated value should be used | 20:55 |
| ssj71 | the ports of course would need to be specially designated | 20:55 |
| ssj71 | its not as sophisticated or powerful, but I see it much more likely to be implemented | 21:00 |
| ssj71 | as it puts most of the work on the host | 21:06 |
| ssj71 | it also changes it from a "self-automating" plugin to more of a "deeply automatable" plugin | 21:08 |
| rgareus | ssj71: I don't see how this is related. seems a rather orthogonal issue | 21:26 |
| rgareus | unless you propose to split the plugin in two | 21:27 |
| rgareus | but that still does not allow a user to easily correct a plugin | 21:27 |
| rgareus | main cases in real world situation are really gates, limites and pitch-detection | 21:29 |
| rgareus | you set plugin parameters for a whole song, and the plugin gets it right in 99% of the cases, but to fix that 1% a lot of indirect work is needed (eg automate thresholds or tuning) | 21:30 |
| rgareus | the goal is to allow an easy way to fix one note (blue note too deep) or a few drum hits (gate does not open...) manually | 21:31 |
| rgareus | in a studio when mixing/mastering under time pressure you're not going to build a CV network. | 21:32 |
| rgareus | well, you might, but not the average sound engineer :) | 21:33 |
| ssj71 | the workflow I propose is using specially designated CV ports. The host need not even expose them for the user to network. Instead the host records the output from the first into an automation lane | 21:35 |
| ssj71 | then plays it back with the user's edits as necessary | 21:35 |
| ssj71 | through the input CV port | 21:36 |
| ssj71 | its a special case for a port that is only set/calculated in RT and doesn't make sense to "set" in the traditional port way | 21:36 |
| ssj71 | I just think the plugin needing to select that it is in analyze mode, and send guard points etc. is quite the barrier of entry | 21:37 |
| ssj71 | perhaps this is a naieve proposal as I haven't used automation much, nor midi controllers | 21:39 |
| ssj71 | It just seems strange to me to make the plugin behaving as a control surface | 21:39 |
| ssj71 | instead you want the host to be able to display the timeline of this inner state to the user and override the state as necessary | 21:49 |
| *** rncbc has quit IRC | 22:17 | |
| *** ricardocrudo has quit IRC | 22:29 | |
| *** jbitdrop has quit IRC | 22:30 | |
| *** ocbtec has quit IRC | 22:30 | |
| *** ssj71 has quit IRC | 23:29 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!