6 Feb
2012
6 Feb
'12
10:33 a.m.
hi *!
total lv2 newbie trying to get my feet wet, so bear with me :)
i'm trying to dezip my control ports by using simple linear
interpolation. to that end, i'm storing the current values of all
control ports in extra fields in the LV2_Handle.
they get ramped to the desired value during run(), so that the current
values will equal the ones set by the control ports at the end of each
run().
now i'm stuck trying to understand where to initialize my current value
fields.
what i want to avoid is a ramp from default or previous values whenever
the plugin is run for the first time. in that case, i want to have no
ramp and start cold with the control port value.
can i rely on control port data being available during activate() so
that i can initialize my current values to the control port values?
now i could set the current values to NULL during instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
what is the recommended procedure to deal with this?
jörn
6 Feb
6 Feb
12:04 p.m.
On Mon, Feb 06, 2012 at 10:33:31AM +0100, Jörn Nettingsmeier wrote:
what i want to avoid is a ramp from default or
previous values whenever
the plugin is run for the first time. in that case, i want to have no
ramp and start cold with the control port value.
For general purpose processing (as opposed to synthesis) that doesn't
matter in practice. Certainly not if the ramp is just one period.
can i rely on control port data being available during
activate() so
that i can initialize my current values to the control port values?
now i could set the current values to NULL during instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
This would be outside the main loop, so harmless. You may want something
similar to switch between interpolated or constant runs as well, so it
would just add one boolean.
Note that making parameter smoothing dependent on the period size
is not really recommended, except again for synthesis. For the zita
series it is Verboten.
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
12:55 p.m.
On 02/06/2012 12:04 PM, Fons Adriaensen wrote:
true.
On Mon, Feb 06, 2012 at 10:33:31AM +0100, Jörn
Nettingsmeier wrote:
it might if a DAW deactivates plugins on transport stop, then locates,
then re-activates on play - can i be sure this won't happen with any host?
i certainly don't want my first note to go through a sweep of all plugin
controls each time i press "play".
what i want to avoid is a ramp from default or
previous values whenever
the plugin is run for the first time. in that case, i want to have no
ramp and start cold with the control port value.
For general purpose processing (as opposed to synthesis) that doesn't
matter in practice. Certainly not if the ramp is just one period. can i rely on
control port data being available during activate() so
that i can initialize my current values to the control port values?
now i could set the current values to NULL during instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
This would be outside the main loop, so harmless. You may want something
similar to switch between interpolated or constant runs as well, so it
would just add one boolean. Note that making parameter smoothing dependent on the
period size
is not really recommended, except again for synthesis. For the zita
series it is Verboten.
well, i've considered carrying loads of state with me and maybe even do
cubic interpolation, but that's for later. the problem is i don't know
in advance how many control points i need to cache for constant
smoothing over time, because LV2 doesn't guarantee a constant number of
samples per run().
best,
jörn
7:46 p.m.
On Mon, 2012-02-06 at 12:55 +0100, Jörn Nettingsmeier wrote:
On 02/06/2012 12:04 PM, Fons Adriaensen wrote:
You must not make any assumptions about data across a deactive() and
activate(). There is an infinite chasm of unknown time between those
calls.
On Mon, Feb 06, 2012 at 10:33:31AM +0100, Jörn
Nettingsmeier wrote:
it might if a DAW deactivates plugins on transport stop, then locates,
then re-activates on play - can i be sure this won't happen with any host?
i certainly don't want my first note to go through a sweep of all plugin
controls each time i press "play". what i want to avoid is a ramp from default or
previous values whenever
the plugin is run for the first time. in that case, i want to have no
ramp and start cold with the control port value.
For general purpose processing (as opposed to synthesis) that doesn't
matter in practice. Certainly not if the ramp is just one period. >> can i rely on control port data being
available during activate() so
>> that i can initialize my current values to the control port values?
There is the possibility of a run() pre-roll (when nframes=0) but hosts
are not *required* to do this. Sounds like you don't need it anyway
(but in general this might need sorting out at some point...)
-dr
2:24 p.m.
On 02/06/2012 03:33 AM, Jörn Nettingsmeier wrote:
can i rely on control port data being available during
activate() so
that i can initialize my current values to the control port values?
No. Ports are only valid during the run() method.
now i could set the current values to NULL during
instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
If your engine has different "states," just make this first-run
condition one of your states and use a switch() statement.
You should be able to do all this initialisation with a single compare
or switch... which is cheap. I don't see a way to avoid having it, though.
-gabriel
5:49 p.m.
On 02/06/2012 02:23 PM, Gabriel M. Beddingfield wrote:
ok, did that now.
cheers,
jörn
On 02/06/2012 03:33 AM, Jörn Nettingsmeier wrote:
thanks for explaining.
can i rely on control port data being available
during activate() so
that i can initialize my current values to the control port values?
No. Ports are only valid during the run() method. now i could
set the current values to NULL during instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
If your engine has different "states," just make this first-run
condition one of your states and use a switch() statement.
You should be able to do all this initialisation with a single compare
or switch... which is cheap. I don't see a way to avoid having it, though.
4471
days inactive
4471
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
David Robillard -
Fons Adriaensen -
Gabriel M. Beddingfield -
Jörn Nettingsmeier