18 Jun
2009
18 Jun
'09
1:47 p.m.
hi everybody!
thanks for sharing your thoughts!
Jörn Nettingsmeier wrote:
consider the case of periodic control values of LADSPA
plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
to summarize: there seem to be no objections to adding such a hint
(stefano's initial critique was about just using it without adding it to
the standard LADSPA header, iiuc, which has never been intended).
some people opined that it could as well be done in LV2 using an
extension. there is no consensus yet about whether this belongs in the
existing units extension, but this is orthogonal to the LADSPA issue.
during the discussion, fons brought up the issue of adding an enum type
to integer ports, to enable hosts to display meaningful string values
for radio-button-type controls. the general usefulness of this was
undebated.
an RFC for a LADSPA 1.2 revision including both the "periodic" and the
"enum" hints will be posted in a new thread.
best,
jörn