LV2 chat

what's the main difference between VST and LV2 control ports?
rgareus: LV2 and VST2 ar very similar. The only difference is that VST is always using the range [0..1]  and mapping to the actual value is done separately
rgareus: LV2 provides for control-port meta-data (VST3 now does as well, to some extent)


<drobilla> CV is control ports at audio rate
<rgareus> I'd use Atoms for control ports at audio rate, but that's a different story.

<wrl> i'm going to keep banging the "parameters should be setters/getters on the plugin itself, not ports" drum
<drobilla> The 90's called, it wants its design philosophy back :P
<drobilla> but setters and getters are just messages run through a few decades of Java brain-damage anyway, in which case, yes
<wrl> i'd argue the opposite, actually
<drobilla> Control ports are obviously garbage
<wrl> for the use-case of smoothed parameters, having the getter/setter there is massively easier
<drobilla> Unless a change is halfway through a buffer...
<wrl> parameter change events are basically just deferred set calls ;)
<wrl> even in the case of something like an audio-rate control port, parameters have different slew rates
<strogon14> the 0x4711 is just a magic number internal to the plugin, that tells the work() function, which runs in another thread, that the work request really came from its DSP thread. Its like door-badge :)
<wrl> discontinuity in the middle of a bunch of floats still needs to get filtered out. not for everything but for a lot of things


<milkii> what's the main difference between VST and LV2 control ports?
<rgareus> LV2 and VST2 ar very similar. The only difference is that VST is always using the range [0..1]  and mapping to the actual value is done separately
<rgareus> LV2 provides for control-port meta-data (VST3 now does as well, to some extent)
<wrl> also from an API perspective, the difference that i was complaining about above stands
<wrl> LV2 expects control port values to be passed into the plugin as... port values into process()
<wrl> VST2 represents control ports via a getter/setter pair of functions
<wrl> void setParameter(int32_t param_id, float val); float getParameter(int32_t param_id);
<drobilla> On that, the other problem there is now you have a bunch of threading rules
<drobilla> Which, knowing VST in practice, are probably violated 90% of the time
<drobilla> Synchronous is good
<wrl> yeah you uh
<wrl> you have to assume that setParameter will be called from any thread at any time
<wrl> possibly from two threads at the same time for the same parameter
<drobilla> The ideal for plugins, IMO, is pure functions.  run(inputs, outputs)
<wrl> ¯\_(ツ)_/¯
<drobilla> what in the blazing fuck
<drobilla> seriously?
<wrl> oh, dude.
<wrl> the vst2 spec is "whatever cubase does, probably."
<drobilla> See above with my opinionated 90s comments
<wrl> yo i'm not saying that vst2 is a paragon of engineering by a long shot
<drobilla> Which is also where the genius approach to parallelism of "yeah I dunno stick mutex in some places I guess?" lives in my mind :)
<wrl> it's a clowncar
<wrl> it just happens to make my parameter handling efficient :>
<wrl> but also auv2, vst3, etc... they all handle parameters in the same way
<drobilla> Yeah, but you're also a plugin dev
<wrl> the way i handle the threading cesspool is by only having my param handlers mutate atomics
<drobilla> Who left to their own devices just want their skeumorphic thing with knobs and fuck everything else :P
<wrl> hey
<wrl> HEY
<drobilla> heh
<wrl> but for real – param smoothing is a huge fit & finish thing and the LV2 model makes it a little clunky
<drobilla> routable control is a bit esoteric depending on how you look at it, to be fair
<drobilla> But also something basically any hardware equivalent just has for free, so.... I dunno.  "add more methods!!" smells like software people just fucking it up as software people do, to me
<wrl> well, yes and no
<drobilla> Yeah, having _some_ hook to explicitly know when a change happened is important
<wrl> i feel it's important to occasionally revisit API decisions and see how users are realistically using them is important
<drobilla> In general, sure
<wrl> for example, the whole notion of sample-accurate intra-process() automation is an interesting one
<wrl> while I was developing my AUv2 code, I did a lot of research into alternate implementations
<drobilla> With control ports I overtly and publicly fucking hate everything about them and rant about it constantly, so, y'know, yeah.
<wrl> AUv2, like VST3, has two different schedulable parameter events – one-shot (set param to X) and ramp (lerp param from A to B over N samples)
<wrl> i can only find one implementation of the ramp mode, and it's in apple's internal helper classes
<wrl> but like
<wrl> Iplug doesn't support it, JUCE doesn't support it, Dplug doesn't support it
<wrl> I got in touch with a friend on the Logic team, and after some trepidation on his part, was able to determine that Logic rarely (if ever) sends ramp events
<wrl> so it's like...
<drobilla> Ramps are how Live works internally
<wrl> does live send them to VST3s or AUs?
<wrl> if you can answer that
<drobilla> There's the whole host-controlled vs plugin-controlled interpolation debate there, and all the shades of grey therein
<drobilla> I dunno
<drobilla> (Probably not)
<wrl> yeah for sure
<wrl> the industry has largely moved to be plugin-controlled
<wrl> see: preset management in particular
<drobilla> I don't think they are necessarily at odds
<drobilla> The host can send a nice little line of all the control that's going on
<rgareus> VST3 makes this clear, see the vst3Automation.html I've linked earlier. If you only read the text and don't look at the API, it's very reasonable.
<drobilla> You are free to do whatever with that information
<drobilla> But I dunno.  It's just a bunch of work, really, like so many things
<rgareus> finally an explicit "No automated parameter must influence another automated parameter"
<wrl> rgareus: meanwhile, in AU land...
<wrl> "meta-parameters"
<rgareus> yeah, those are well-defined, too though
<drobilla> I kinda figured the ability for parameters to be influenced by others was a good thing you just want
<drobilla> ... there was some concrete case why but I forget now
<rgareus> "The prime example for this is the automation of preset changes."
<rgareus> or also MIDI control handled by a plugin