23 Jun
2015
23 Jun
'15
3:37 p.m.
On 06/23/2015 01:24 PM, Rui Nuno Capela wrote:
[..]
yes, there's also the lv2atom::eventTransfer
mechanism, but this time
it's a host <-> UI interface;
It's for all cases (incl host <-> DSP), except "eventTransfer"
delegates
it to the host to split an lv2atom:Sequence into individual Events
(useful for callback functions and hence indeed common for host -> GUI
http://lv2plug.in/ns/ext/atom/#eventTransfer )
If you'd want to use eventTransfer to the DSP, the host needs to split
the process cycle at every event-timestamp; hence Sequence of events is
a lot more useful.
look, for instance, there are a world of plugin
instruments out there
that supplies its own presets, addressable through MIDI
bank_select+program_change, which are channel messages, so it should
only affect one of the plugin parts (if multi-timbral) and NOT the
entire and complete plugin instance state. in response to this kind of
MIDI input the plugin should or even must change one or more of its own
parameters besides other internal state specific to the part being
selected.
Yes! I'm with you there 100%.
This is a good example where the host simply cannot be in control.
The solution I propose for this case is to simply not export the
control-parameters as "old-fashioned LADSPA float-pointer inputs" to the
host.
note that all of this often occurs *without* UI
intervention (or
proxying) as the UI might well be not visible at all. now, if the host
doesn't get it properly notified it will assume the previous or even
(re)set to its own version of the parameter values, with unpredictable
consequences and most probably NOT what the incoming MIDI PC message
meant in the first place (changing an instrument part preset or program).
of course this also applies to a plugin's own MIDI CC configuration,
binding or assignment. again, there's a vast multitude of plugins which
have it as on their own business, that is, it's not necessarily a host's
provided feature; a plugin's MIDI CC real-time response most probably
goes to one or more of its own parameters, so they will change them as
sees fit and to its own purpose--the host *must* know or listen that
this event is occurring and react accordingly.
yep.
alas, in LV2 there's no standard defined way to do
just that.
The vocab is there and there are some de-facto examples for patch:set.
patch:set param:some_control 1.234f
That message can be generated by a plugin (sent to host) and by a host
(sent to DSP).
but the official doc still says "Other methods, such as setting dynamic
parameters via messages, are possible but not defined here."
http://lv2plug.in/ns/lv2core/#Parameter
So yes, this needs to be worked out.
IIUC it's all there already in the LV2:Atom, LV2:Patch and LV2:MIDI doc.
But there's no reference implementation for float parameters per se.
Current existing examples are filenames and MIDI only.
iow. LV2
dictates that all plugins must not ever alter their own parameters
(input control ports) and thus delegate all MIDI CC, PC and any other
controllability features and support into host's shoulders.
and that's a shame if it stays this way.
I think it's fine if float-pointer input control ports remain completely
under the host's control (backwards compat, simple plugins) as long as
there are other means that allow a plugin to set its own properties.
There's no need to complicate the simple & fast way that's good for 90%
of all plugins. Like with AU: If you have a fancy plugin (dependent
Params, internal Properties), use the fancy API.
2c,
robin