25 May
2012
25 May
'12
9:22 a.m.
Hi all,
The LV2 spec says that on a call to activate(), "the plugin instance MUST
reset all state information dependent on the history of the plugin instance
except for any data locations provided by connect_port()"
I am not certain whether MIDI CC parameters are included in this category
of "data locations provided by connect_port()". The CC parameters are sent
through port buffers provided by connect_port(), but because they are *event
* buffers, all information passed through them is necessarily part of the *
history* of the plugin instance.
I could imagine cases where you would want to reset all internal state of
the plugin, but since CC values are very much like port values, they would
be kept. On the other hand, I could also imagine cases where you would
want to reset all internal data including the CC parameters.
I'm assuming MIDI note on/off status certainly should be reset.
Thanks,
Jeremy Salwen
28 May
28 May
5:41 p.m.
2012/5/25 Jeremy Salwen <jeremysalwen(a)gmail.com>om>:
Hi all,
The LV2 spec says that on a call to activate(), "the plugin instance MUST
reset all state information dependent on the history of the plugin instance
except for any data locations provided by connect_port()"
I am not certain whether MIDI CC parameters are included in this category of
"data locations provided by connect_port()". The CC parameters are sent
through port buffers provided by connect_port(), but because they are event
buffers, all information passed through them is necessarily part of the
history of the plugin instance.
I could imagine cases where you would want to reset all internal state of
the plugin, but since CC values are very much like port values, they would
be kept. On the other hand, I could also imagine cases where you would want
to reset all internal data including the CC parameters.
I'm assuming MIDI note on/off status certainly should be reset.
<personal opinion>
I have always interpreted activate()/deactivate() as a real-time safe
alternative to instantiate()/cleanup(), so I'd say restart fresh, wipe
out everything.
I do not necessarily agree that MIDI CC is like a port value, since
when the first run() after the first activate() is called and there's
no incoming CC event, however you probably need to be in a certain
"initial state".
</personal opinion>
Concrete use case would help.
Stefano
7:27 p.m.
On Mon, 2012-05-28 at 18:41 +0300, Stefano D'Angelo wrote:
2012/5/25 Jeremy Salwen
<jeremysalwen(a)gmail.com>om>:
The spec explicitly states: "the plugin instance MUST reset all state
information dependent on the history of the plugin instance except for
any data locations provided by connect_port()"
This text does date from a time when that was the only way to actually
get any data in/out of a plugin, so it might need clarification now with
MIDI/other events/state/etc.
For live plugins if you're going to stop continually running the plugin,
you must deactivate it, so I can see how a complete and total state
reset here might be undesirable. I'm not sure. A complete
cleanup/re-initialization is always an option for a total reset, though
of course not real-time whatsoever.
Hi all,
The LV2 spec says that on a call to activate(), "the plugin instance MUST
reset all state information dependent on the history of the plugin instance
except for any data locations provided by connect_port()"
I am not certain whether MIDI CC parameters are included in this category of
"data locations provided by connect_port()". The CC parameters are sent
through port buffers provided by connect_port(), but because they are event
buffers, all information passed through them is necessarily part of the
history of the plugin instance.
I could imagine cases where you would want to reset all internal state of
the plugin, but since CC values are very much like port values, they would
be kept. On the other hand, I could also imagine cases where you would want
to reset all internal data including the CC parameters.
I'm assuming MIDI note on/off status certainly should be reset.
<personal opinion>
I have always interpreted activate()/deactivate() as a real-time safe
alternative to instantiate()/cleanup(), so I'd say restart fresh, wipe
out everything.
I do not necessarily agree that MIDI CC is like a port value, since
when the first run() after the first activate() is called and there's
no incoming CC event, however you probably need to be in a certain
"initial state".
</personal opinion> Concrete use case would help.
Indeed.
-dr
29 May
29 May
1:43 a.m.
On 05/28/2012 07:27 PM, David Robillard wrote:
For live plugins if you're going to stop
continually running the plugin,
you must deactivate it, so I can see how a complete and total state
reset here might be undesirable. I'm not sure. A complete
cleanup/re-initialization is always an option for a total reset, though
of course not real-time whatsoever.
I'd say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the dry signal. That would essentially render such a plugin
totally useless. Or am I missing something here?
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
4:49 a.m.
On Tue, 2012-05-29 at 01:43 +0200, Albert Graef wrote:
On 05/28/2012 07:27 PM, David Robillard wrote:
It does seem like the most reasonable thing to do.
I don't know what the wording should be changed to, then. Perhaps all
that is reset between deactivate() and activate() is everything that is
time dependent?
Note that doing this means there is no way for the host to reset a
plugin instance to a known state other than completely reinstantiating
it. I don't know if this is a bad thing (since that's the only way you
can really be sure anyway)
-dr
For live plugins if you're going to stop
continually running the plugin,
you must deactivate it, so I can see how a complete and total state
reset here might be undesirable. I'm not sure. A complete
cleanup/re-initialization is always an option for a total reset, though
of course not real-time whatsoever.
I'd say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the dry signal. That would essentially render such a plugin
totally useless. Or am I missing something here? 
2:23 p.m.
On Mon, May 28, 2012 at 10:49 PM, David Robillard <d(a)drobilla.net> wrote:
On Tue, 2012-05-29 at 01:43 +0200, Albert Graef wrote:
there's a misconception right there, i think. you wouldn't deactivate it to
listen to the dry signal. you'd bypass it using some feature of the host.
On 05/28/2012 07:27 PM, David Robillard wrote:
> For live plugins if you're going to stop continually running the
plugin,
you must
deactivate it, so I can see how a complete and total state
reset here might be undesirable. I'm not sure. A complete
cleanup/re-initialization is always an option for a total reset, though
of course not real-time whatsoever.
I'd say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the dry signal.
3:37 p.m.
On 05/29/2012 02:23 PM, Paul Davis wrote:
there's a misconception right there, i think. you
wouldn't deactivate it
to listen to the dry signal. you'd bypass it using some feature of the
host.
Yes, of course this depends on the host. But presumably an LV2 host
would then also deactivate the plugin and later reactivate it to reset
it to a sane state? At least that's what I thought these callbacks were
for. IIRC that's how it works in Qtractor (Rui, please correct me if I'm
wrong), and that certainly makes sense to me. I didn't test this with
Ardour, though.
Otherwise, how is an LV2 plugin supposed to know that it has been
suspended and should prepare its internal state to be switched back on
again? All the host knows about the plugin are its ports, so it's
limited in what it can do. Only the plugin itself knows about the extra
cleanup it might want to do when being switched off and then back on
again, no?
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
3:48 p.m.
On Tue, May 29, 2012 at 9:37 AM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
the question really is under what circumstances should the host/user call
deactivate/activate?
if the host/user has done this, then they should be clear on the
consequences. you don't call these functions in order to bypass a plugin.
you call them specifically when there is a need to completely reset the
state of the plugin.
however, david's point stands which is that you really want both (a) a
method to stop and restart the plugin (b) a method to reset to it back to
the state it would have immediately after instantiation. its not 100%
whether deactivate/activate is either of these ...
there's a misconception right there, i think.
you wouldn't deactivate it
to listen to the dry signal. you'd bypass it using some feature of the
host.
Yes, of course this depends on the host. But presumably an LV2 host
would then also deactivate the plugin and later reactivate it to reset
it to a sane state? At least that's what I thought these callbacks were
for. IIRC that's how it works in Qtractor (Rui, please correct me if I'm
wrong), and that certainly makes sense to me. I didn't test this with
Ardour, though.
Otherwise, how is an LV2 plugin supposed to know that it has been
suspended and should prepare its internal state to be switched back on
again? All the host knows about the plugin are its ports, so it's
limited in what it can do. Only the plugin itself knows about the extra
cleanup it might want to do when being switched off and then back on
again, no?
6:18 p.m.
On Tue, May 29, 2012 at 09:48:10AM -0400, Paul Davis wrote:
the question really is under what circumstances should
the host/user call
deactivate/activate?
if the host/user has done this, then they should be clear on the
consequences. you don't call these functions in order to bypass a plugin.
you call them specifically when there is a need to completely reset the
state of the plugin.
I've always lookat at activate() as part of the sequence
required to load a plugin and make it work, not as something
ever explicitly done by the user. If a plugin needs a 'Reset'
(some do, it depends on the particular effect), it should have
a Reset button.
Since in LV2 activate() and deactivate() do not affect port
connections, I'd say they should not reset any controller
values that the plugin gets from MIDI input. The controller
remains connected, but it doesn't know it should resend its
current value if the plugin would reset it.
AFAICS, Ardour's 'activate' and 'deactivate' (at least for
LADSPA plugins) do not call those functions, they just change
the signal routing. Which looks to me as the right thing.
Another questions if a host bypasses a plugin, should it still
provide input signals to the plugin and run its process() ?
I tend to say yes - it's what you usually get on real mixers
when patching an outboard processor, and it can be useful
in some cases when working 'life', e.g. to set up a dynamics
processor (which requires input) before inserting it.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
30 May
30 May
1:25 a.m.
On Tue, 2012-05-29 at 16:18 +0000, Fons Adriaensen wrote:
On Tue, May 29, 2012 at 09:48:10AM -0400, Paul Davis
wrote:
This is a digression, but I think port_connect() is the dumbest thing in
LV2. I have all sorts of plugins that would be stateless but for the
idiotic need to keep that stuff around, when they are only used in run
anyway. All that function calling is also expensive, most hosts I have
seen just end up connecting every port every cycle anyway. It's absurd.
Should be arrays of buffer pointers to run().
the question really is under what circumstances
should the host/user call
deactivate/activate?
if the host/user has done this, then they should be clear on the
consequences. you don't call these functions in order to bypass a plugin.
you call them specifically when there is a need to completely reset the
state of the plugin.
I've always lookat at activate() as part of the sequence
required to load a plugin and make it work, not as something
ever explicitly done by the user. If a plugin needs a 'Reset'
(some do, it depends on the particular effect), it should have
a Reset button.
Since in LV2 activate() and deactivate() do not affect port
connections, I'd say they should not reset any controller
values that the plugin gets from MIDI input. The controller
remains connected, but it doesn't know it should resend its
current value if the plugin would reset it. AFAICS, Ardour's 'activate' and
'deactivate' (at least for
LADSPA plugins) do not call those functions, they just change
the signal routing. Which looks to me as the right thing.
It's the rightest thing, but it also wastes cycles.
Another questions if a host bypasses a plugin, should
it still
provide input signals to the plugin and run its process() ?
For live plugins it is strictly required to, for non-live plugins it is
not.
Since we don't actually have stateless plugins at all (thanks to the
above connect_port mistake) activate and deactivate are essentially
'start time' and 'stop time'. Whenever the time of data processed by
subsequent calls to run() is not contiguous (e.g. a transport locate)
the plugin MUST be deactivated and reactivated again.
In other words, if you havn't been deactivated, the audio you are
receiving in subsequent run calls is a continuous stream of audio.
Otherwise you'll end up applying 'trends' (like parameter interpolation)
from the 'previous' (but not) block to the current one, which is wrong.
This guarantee is necessary to be able to do basic stuff like filters
correctly. I think it is the actual motivation for the 'activate resets
state' language (e.g. you must reset your filter state because there's
been a gap in audio), but this should probably be clarified. Nothing in
the spec lays out this 'continuous stream' thing clearly.
tl;dr: The state that needs to be reset is state that depends on a
continuous stream of audio. Midi controllers and such do not cause
problems if they persist across audio gaps, and are not what was being
referred to here.
-dr
10:20 a.m.
On 05/29/2012 07:57 PM, David Robillard wrote:
tl;dr: The state that needs to be reset is state that
depends on a
continuous stream of audio. Midi controllers and such do not cause
problems if they persist across audio gaps, and are not what was being
referred to here.
Exactly. In the case of an instrument plugin, that might mean, e.g.,
that the allocated voices and the pitch bends are reset, but usually not
the controllers. Incidentally, that's exactly how I implemented those
callbacks in faust-lv2, and it works nicely with Qtractor at least.
Paul, you said that Ardour doesn't do activate()/deactivate() with
effect plugins. Is that the same with instrument plugins? Then the
scheme I used in faust-lv2 probably doesn't fare that well with Ardour3,
unless it takes care of resetting the plugin in some other way.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
7:24 p.m.
On Wed, 2012-05-30 at 10:20 +0200, Albert Graef wrote:
On 05/29/2012 07:57 PM, David Robillard wrote:
Right. I think time is the key to explaining this
clearly/precisely/generically.
What's happening is that time is no longer continuous. Reset
accordingly.
-dr
tl;dr: The state that needs to be reset is state
that depends on a
continuous stream of audio. Midi controllers and such do not cause
problems if they persist across audio gaps, and are not what was being
referred to here.
Exactly. In the case of an instrument plugin, that might mean, e.g.,
that the allocated voices and the pitch bends are reset, but usually not
the controllers. Incidentally, that's exactly how I implemented those
callbacks in faust-lv2, and it works nicely with Qtractor at least.
12:16 a.m.
On Tue, 2012-05-29 at 09:48 -0400, Paul Davis wrote:
[...]
you really want both (a) a method to stop and restart
the plugin (b) a
method to reset to it back to the state it would have immediately
after instantiation. its not 100% whether deactivate/activate is
either of these ...
There is also the distinction between "live" plugins and non-live
plugins (plugins can indicate being live and there are rules about it.
In particular, for live plugins, you *have* to regularly call run if it
is activated. So, to bypass, you're either running it on nothing
(wasting cycles) or you have to deactivate it.
-dr
9:51 a.m.
On 05/29/2012 07:39 PM, David Robillard wrote:
In particular, for live plugins, you *have* to
regularly call run if it
is activated. So, to bypass, you're either running it on nothing
(wasting cycles) or you have to deactivate it.
Exactly. So Qtractor does in fact do the right thing there. :) Whether
you call that option Bypass or Activate in the GUI, I don't really care.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
11:20 a.m.
On Wed, May 30, 2012 at 3:52 AM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
On 05/29/2012 07:39 PM, David Robillard wrote:
again, you do not deactivate or in anyway change the execution of a plugin
simply in order to hear a "dry" signal. if you doubt this, just turn the
switch between "wet" and "dry" into a knob ...
In particular, for live plugins, you *have* to
regularly call run if it
is activated. So, to bypass, you're either running it on nothing
(wasting cycles) or you have to deactivate it.
Exactly. So Qtractor does in fact do the right thing there. :) Whether
you call that option Bypass or Activate in the GUI, I don't really care.
11:46 a.m.
On 05/30/2012 11:20 AM, Paul Davis wrote:
again, you do not deactivate or in anyway change the
execution of a
plugin simply in order to hear a "dry" signal. if you doubt this, just
turn the switch between "wet" and "dry" into a knob ...
Ok, point taken, they're different things.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
29 May
29 May
4:41 p.m.
On 2012-05-29 14:37, Albert Graef wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
aha. qtractor doesn't have this "bypass" option as Paul refers to (i
guess from ardour's;) as being independent of lv2
deactivate()/activate() calls...
fact is, qtractor does call lv2plug.in->activate()/deactivate()
respectively, whenever its own plugin "activate"/"deactivate" commands
are issued, or the equivalent for other plugin types (vst, ladspa, dssi.
altough neither of which resets qtractor's external midi controllers
assignments per se...
however, depending on plugins implementation, it might (yeah might)
reset a plugins internal state re. their eventual midi control state,
leaving the host, qtractor in particular, to play catch-up after every
deactivate/activate() cycle...
yeah. you might have a point in there ;) maybe it's all qtractor fault,
of not having a separate "bypass" switch independent of plugins
(de)activate/activate() sort of power-cycle...
hmm... thinking of it, my recent "vee one" proto-toys (synthv1 &
samplv1) actually rest their midi control state upon lv2::(de)activate()
... that is, they behave as if a "panic" button has been issued
especially the all-controllers-off one (ie. GM CC#121) ...
so, should i read this whole question about a case of lv2 plugin
implementation or is that a lack of simple "bypass" on qtractor (or any
other lv2 host) to be at stake ?
cheers
--
rncbc aka. Rui Nuno Capela
there's a misconception right there, i think.
you wouldn't
deactivate it
to listen to the dry signal. you'd bypass it using some feature of
the
host.
Yes, of course this depends on the host. But presumably an LV2 host
would then also deactivate the plugin and later reactivate it to
reset
it to a sane state? At least that's what I thought these callbacks
were
for. IIRC that's how it works in Qtractor (Rui, please correct me if
I'm
wrong), and that certainly makes sense to me. I didn't test this with
Ardour, though.
11:51 p.m.
On Mon, May 28, 2012 at 10:49:06PM -0400, David Robillard wrote:
I agree.
This issue raises some other questions on how plugins could/should
handle MIDI input. I offer the following for your consideration and
comments.
The four cases outlined below are in fact points on a continuous
scale, with (1) and (4) being the extremes. The interesting range
is between (2) and (3).
1. The host accepts MIDI input, selects on port, channel, controller
number (e.g. by providing a 'learn' function), and converts selected
messages to control port values. The plugins are never aware that their
input is from MIDI.
2. As above, but the selected data is presented to the plugin either
in MIDI format, or via some more generic 'event delivery' mechanism.
The difference with (1) is that the plugin knows it is dealing with
events.
3. The host provides the MIDI ports, but offers all it gets to any
interested plugin. The plugin performs selection on port, channel
and controller number.
4. The plugin provides its own MIDI input, completely independent
from the host.
Some initial comments:
* One could argue that (3) and (4) lead to a lot of non-trivial
code and development effort being duplicated or repeated for
each plugin. But that need no be the case: the plugin SDK could
offer services that would make this (almost) as easy for the
plugin developer as (1) or (2).
* In (1,2) the selection of port/channel/controller are part of
the host configuration, this data would normally be stored in
the host's session file and the plugins are never aware of it.
In (3,4), the selection criteria become part of the plugin's
configuration, and could be included in e.g. plugin presets.
That makes a difference for the user - but I'm uncertain as
to which would be best.
* I'd expect (1,2) for e.g. individual modular synth modules,
it would feel strange if each individual one would implement
(3,4). OTOH, it wouldn't feel so odd if e.g. a Linuxsampler
or Yoshimi plugin would do that. [*]
* My tentative conclusion would be that a plugin standard
should provide both (2) and (3), and maybe something in
between those.
Comments invited !
[*] Some tricky questions to disturb your sleep:
We now have a few plugins that are in fact complete multitimbral
instruments. Suppose someone would first add LV2 support to AMS
(it can use plugins as if they were native modules), then turn
the complete AMS itself into an LV2 plugin.
- Should AMS then be able to load itself ???
- What impact would that have on the things discussed above ???
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
I'd say
that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the dry signal. That would essentially render such a plugin
totally useless. Or am I missing something here?
It does seem like the most reasonable thing to do.
30 May
30 May
3 a.m.
On Tue, 2012-05-29 at 21:51 +0000, Fons Adriaensen wrote:
On Mon, May 28, 2012 at 10:49:06PM -0400, David
Robillard wrote:
I agree.
This issue raises some other questions on how plugins could/should
handle MIDI input. I offer the following for your consideration and
comments.
The four cases outlined below are in fact points on a continuous
scale, with (1) and (4) being the extremes. The interesting range
is between (2) and (3).
1. The host accepts MIDI input, selects on port, channel, controller
number (e.g. by providing a 'learn' function), and converts selected
messages to control port values. The plugins are never aware that their
input is from MIDI.
2. As above, but the selected data is presented to the plugin either
in MIDI format, or via some more generic 'event delivery' mechanism.
The difference with (1) is that the plugin knows it is dealing with
events.
3. The host provides the MIDI ports, but offers all it gets to any
interested plugin. The plugin performs selection on port, channel
and controller number.
4. The plugin provides its own MIDI input, completely independent
from the host.
LV2 takes the simple non-choice strategy that Jack *really* should have
also went with: you can have inputs and outputs that are a buffer of
time-stamped events with *whatever* in them.
In practice, this has been only really been used for MIDI until
recently. Now more 'high level' things (like loading samples) are
starting to be done using non-MIDI events (e.g. LV2 'atoms' which is
sort of a binary JSON-like thing). Firing around POD-blobs of whatever
is fantastic.
While I would like to see something better than MIDI get established for
notes and such, no interest there so far. Unsurprisingly I don't think
the core API should be burdened with all that.
I'd
say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the dry signal. That would essentially render such a plugin
totally useless. Or am I missing something here?
It does seem like the most reasonable thing to do. Some initial comments:
* One could argue that (3) and (4) lead to a lot of non-trivial
code and development effort being duplicated or repeated for
each plugin. But that need no be the case: the plugin SDK could
offer services that would make this (almost) as easy for the
plugin developer as (1) or (2).
* In (1,2) the selection of port/channel/controller are part of
the host configuration, this data would normally be stored in
the host's session file and the plugins are never aware of it.
In (3,4), the selection criteria become part of the plugin's
configuration, and could be included in e.g. plugin presets.
That makes a difference for the user - but I'm uncertain as
to which would be best.
I doubt any strong conclusion could be reached either way. The thing
is, there are all kinds of good reasons for plugins to want to process
streams of MIDI (or OSC, or...) events. Even if there was an
alternative somewhat equivalent system for it, this would be true.
Something better than MIDI would be great, but not supporting MIDI would
surely doom any plugin API. Better to support <whatever> and let
somebody pioneer a better alternative when they're actually going to get
around to doing something with it (we can't really afford to be idealist
on this one anyway, the lack of LAD synth plugins is bad enough without
adding that gigantic barrier to porting on top of it)
For example, a great Ardour project would be to support explicit note
control (e.g. the ability to draw a single note and pitch bend it as an
arbitrary vector, and apply controls to *that note alone*) and actually
send all that data to a synth plugin (which MIDI can not do, OSC could,
other options as well) would be a great project. A chicken & egg
situation, though, that could only be resolved by someone actually
setting out to make that happen. Hopefully some day they do.
* I'd expect (1,2) for e.g. individual modular
synth modules,
it would feel strange if each individual one would implement
(3,4). OTOH, it wouldn't feel so odd if e.g. a Linuxsampler
or Yoshimi plugin would do that. [*]
Modulars can conveniently get around it by having separate plugins to do
whatever filtering the user wants. Probably the only "truly modular"
way to do it, really.
Stuff like LinuxSampler and Yoshimi are good examples of large fully
featured things that exist, and though existing code is
troublesome/irritating in an endless number of ways, I think practically
speaking it's clear this stuff has to work.
* My tentative conclusion would be that a plugin
standard
should provide both (2) and (3), and maybe something in
between those.
Thus far, 'the market' agrees, so that's probably the right conclusion.
[*] Some tricky questions to disturb your sleep:
We now have a few plugins that are in fact complete multitimbral
instruments. Suppose someone would first add LV2 support to AMS
(it can use plugins as if they were native modules), then turn
the complete AMS itself into an LV2 plugin.
- Should AMS then be able to load itself ???
- What impact would that have on the things discussed above ???
Ingen is actually just that: an LV2 plugin that can load LV2 plugins.
It actually saves to valid LV2 plugins, always (i.e. a saved ingen
bundle *is* an LV2 plugin, if always with the same binary). It is
theoretically possible for it to load itself, but this would be insane
for probably obvious reasons. I havn't really done the UI polish here
yet, but what it does is simply detect that an LV2 plugin is actually an
Ingen patch, and loads it as Ingen patches are normally loaded, and not
as a separate LV2 plugin via the generic interface.
I basically consider Ingen largely as a "plugin development without
writing code" project, these days (ideally I'd like there to be no user
visible distinction between Ingen patch and hand written LV2 plugin at
all). The biggest hole right now is that LV2 lacks dynamic
ports/parameters. This means if you drop a patch in an Ardour strip,
you're stuck with the inputs/outputs of the template you loaded -
including controls, which is quite limiting.
Coincidentally, this is one hidden motivation behind 'events for
parameters' I havn't yet mentioned: if you multiplex all the controls to
a single event buffer[1], you get dynamic parameters for free, in what
seems to be a dramatically simpler way than trying to erect a bunch of
API specifically for it.
It's probably worth mentioning that Ingen-as-an-LV2 can be *entirely*
controlled via the plugin's event input port using the above mentioned
atom messages. The patcher UI works through this mechanism, i.e. there
is no sneaky business happening outside the plugin API to make that
work. Precisely the same protocol, but in a text serialisation instead
of binary (as in the LV2 port) is used when you run Ingen and its UI as
separate processes over the network (it looks suspiciously like
fragments of the save files...)
Generic POD events are an extremely good thing, because it lets crazy
people like me do things like this :)
-dr
[1] e.g. struct ControlChange {
int param_num; /* Allows MUX */
int time;
float value;
int next_time;
float next_value;
}; /* or whatever... */
4992
days inactive
4997
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
7 participants
participants (7)
-
Albert Graef -
David Robillard -
Fons Adriaensen -
Jeremy Salwen -
Paul Davis -
rncbc -
Stefano D'Angelo