[LAD] LADSPA extension for periodic control values?
hi everyone! sorry if this has been discussed before, but i didn't find anything in the archives... 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). best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Sat, Jun 13, 2009 at 01:46:47PM +0200, Jörn Nettingsmeier wrote: > hi everyone! > > > sorry if this has been discussed before, but i didn't find anything in > the archives... > 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). Would make perfect sense, and there are lots of spare bits in the hints word. And I'll repeat my proposal of almost 5 years ago: - Add a 'enumerated' bit to the hints, used together with 'integer'. - Add the required strings at the end of the port names array, where it is trivially easy for a host to find them (or ignore them if the host doesn't know about the new bit). Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/13 Jörn Nettingsmeier : > hi everyone! > > > sorry if this has been discussed before, but i didn't find anything in > the archives... > 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). Hi, I think it makes no sense nowadays to do something like that, for two reasons: * LADSPA is old, hence old LADSPA hosts will not support that and new/maintained ones are not likely to support that, since many are focusing on newer APIs; * An LV2 extension would allow you to do that quite easily in LV2, which is probably preferable these days. That said, I can already hear people who disagree with me shouting and screaming. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Sun, Jun 14, 2009 at 11:44:11PM +0200, Stefano D'Angelo wrote: > * LADSPA is old, hence old LADSPA hosts will not support that and > new/maintained ones are not likely to support that, since many are > focusing on newer APIs; They would just ingnore LADSPA them ? > * An LV2 extension would allow you to do that quite easily in LV2, > which is probably preferable these days. > > That said, I can already hear people who disagree with me shouting and > screaming. Since it's useful, doesn't break anything, and trivially easy, there is no reason for not adding such a bit. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/14 Fons Adriaensen : > On Sun, Jun 14, 2009 at 11:44:11PM +0200, Stefano D'Angelo wrote: > >> * LADSPA is old, hence old LADSPA hosts will not support that and >> new/maintained ones are not likely to support that, since many are >> focusing on newer APIs; > > They would just ingnore LADSPA them ? > >> * An LV2 extension would allow you to do that quite easily in LV2, >> which is probably preferable these days. >> >> That said, I can already hear people who disagree with me shouting and >> screaming. > > Since it's useful, doesn't break anything, and trivially > easy, there is no reason for not adding such a bit. If it is added to the next version LADSPA itself, then it's fine, otherwise anyone could think like that and you can imagine the *POTENTIAL* mess. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
Stefano D'Angelo wrote: >> Since it's useful, doesn't break anything, and trivially >> easy, there is no reason for not adding such a bit. >> > > If it is added to the next version LADSPA itself, then it's fine, > otherwise anyone could think like that and you can imagine the > *POTENTIAL* mess. > I think way too many things in Linux audio are concerned about potential this and potential that, all while ignoring real problems/deficiencies. Idealism taken to extremes and all that. I already support enums in LADSPA via LRDF, but someone introduced those two bits and they were done "properly" (without breaking anything that used to work before), I'd support them in Calf, too. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/15 Krzysztof Foltman : > Stefano D'Angelo wrote: >>> >>> Since it's useful, doesn't break anything, and trivially >>> easy, there is no reason for not adding such a bit. >>> >> >> If it is added to the next version LADSPA itself, then it's fine, >> otherwise anyone could think like that and you can imagine the >> *POTENTIAL* mess. >> > > I think way too many things in Linux audio are concerned about potential > this and potential that, all while ignoring real problems/deficiencies. > Idealism taken to extremes and all that. Well, I just misread the original post (somehow I thought Jorn wanted to add the hint outside of the LADSPA spec, that would cause lots of problems). > I already support enums in LADSPA via LRDF, but someone introduced those two > bits and they were done "properly" (without breaking anything that used to > work before), I'd support them in Calf, too. Two bits? Stefano P.S.: Regarding LV2 Calf plugins, could you use urn:ladspa:12345-style URIs as specified here (http://lv2plug.in/docs/index.php?title=Replace_plugin) for dc:replace? ;-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
Stefano D'Angelo wrote: > Well, I just misread the original post (somehow I thought Jorn wanted > to add the hint outside of the LADSPA spec, that would cause lots of > problems). Lots of problems? What sort of? If you mean hordes of people suddenly starting to define their own proprietary undocumented conflicting port hints and hidden strings... wake up :) We don't see people flooding the LV2 Wiki with new port hint proposals. And it's much easier to define new port hints in LV2 than it is in LADSPA. > Two bits? Flags, port hints, bits, YKWIM. > P.S.: Regarding LV2 Calf plugins, could you use urn:ladspa:12345-style > URIs as specified here > (http://lv2plug.in/docs/index.php?title=Replace_plugin) for > dc:replace? ;-) Yes. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/15 Krzysztof Foltman : > Stefano D'Angelo wrote: > >> Well, I just misread the original post (somehow I thought Jorn wanted >> to add the hint outside of the LADSPA spec, that would cause lots of >> problems). > > Lots of problems? What sort of? > > If you mean hordes of people suddenly starting to define their own > proprietary undocumented conflicting port hints and hidden strings... > wake up :) > > We don't see people flooding the LV2 Wiki with new port hint proposals. > And it's much easier to define new port hints in LV2 than it is in LADSPA. You do not need "hordes of people", you just need two trying to define the same bit differently :-) Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
Stefano D'Angelo wrote: > You do not need "hordes of people", you just need two trying to define > the same bit differently :-) In Linux audio, that counts as hordes :) K. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Sun, 2009-06-14 at 23:44 +0200, Stefano D'Angelo wrote: > 2009/6/13 Jörn Nettingsmeier : [...] > > sorry if this has been discussed before, but i didn't find anything in > > the archives... > > 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. [...] > * An LV2 extension would allow you to do that quite easily in LV2, > which is probably preferable these days. Maybe belongs in the units extension? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/15 David Robillard : > On Sun, 2009-06-14 at 23:44 +0200, Stefano D'Angelo wrote: >> 2009/6/13 Jörn Nettingsmeier : > [...] >> > sorry if this has been discussed before, but i didn't find anything in >> > the archives... >> > 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. > [...] >> * An LV2 extension would allow you to do that quite easily in LV2, >> which is probably preferable these days. > > Maybe belongs in the units extension? I don't think so: periodicity and units are quite different things. For example: an angle could be used also to indicate direction (-180° != 180°) or distance in space (0° != 360°), while integers for example could be cyclic (rhythms, tones/semitones/harmony, musical cycles, etc.)... Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Mon, 2009-06-15 at 18:28 +0200, Stefano D'Angelo wrote: > 2009/6/15 David Robillard : > > On Sun, 2009-06-14 at 23:44 +0200, Stefano D'Angelo wrote: > >> 2009/6/13 Jörn Nettingsmeier : > > [...] > >> > sorry if this has been discussed before, but i didn't find anything in > >> > the archives... > >> > 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. > > [...] > >> * An LV2 extension would allow you to do that quite easily in LV2, > >> which is probably preferable these days. > > > > Maybe belongs in the units extension? > > I don't think so: periodicity and units are quite different things. > For example: an angle could be used also to indicate direction (-180° > != 180°) or distance in space (0° != 360°), while integers for example > could be cyclic (rhythms, tones/semitones/harmony, musical cycles, > etc.)... Sounds an awful lot like units to me... "degrees out of 360" is a cyclic unit -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Robillard wrote: > On Mon, 2009-06-15 at 18:28 +0200, Stefano D'Angelo wrote: >> 2009/6/15 David Robillard : >>> On Sun, 2009-06-14 at 23:44 +0200, Stefano D'Angelo wrote: 2009/6/13 Jörn Nettingsmeier : >>> [...] > sorry if this has been discussed before, but i didn't find anything in > the archives... > 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. >>> [...] * An LV2 extension would allow you to do that quite easily in LV2, which is probably preferable these days. >>> Maybe belongs in the units extension? >> I don't think so: periodicity and units are quite different things. >> For example: an angle could be used also to indicate direction (-180° >> != 180°) or distance in space (0° != 360°), while integers for example >> could be cyclic (rhythms, tones/semitones/harmony, musical cycles, >> etc.)... > > Sounds an awful lot like units to me... "degrees out of 360" is a cyclic > unit Yes, but there is a bit more to it too. As input controls have a min/max they are rendered UI as either a slider or knob with a fixed upper and lower bound that cannot be transgressed. This isn't true for a cyclic parameter. Although the values produced will be in some range (0 - -> 360, -pi -> pi, -1 -> 1) a UI knob would have no limits placed on it's movement (slider won't cut it here) - it can go round past the max or below the min (max and min are actually the same point). Obviously there is more that just rendering the UI, the host would need to know there are two paths to between points on a cyclic control and hence must have a method for choosing the direction with automation etc (remember direction along with values?). It would be nice if it also took care of shifting values to within the the desired range but a plugin with a cyclic parameter should be able to do the shifting itself. Declaring the control as being in some angle UOM isn't enough to know if the control is cyclic, as the values may just represent an arc (and why stop at just angle UOMs), there would need to be a flag to indicate to the host that a control is cyclic so that it could handle it properly. IMO if this is required it's a PortProperty. regards, Fraser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKN9FFNZroiEh4erwRAg7wAKCvELQJ9ntNvJQVqIlcHPC+1KVEdwCfemPK FFHIsKjQ6iGvYSkQD3rB/Nw= =ybbB -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Sat, 2009-06-13 at 13:46 +0200, 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. I don't know if this would be of any use to you, but I have a physical controller that sends messages about its full circular direction. I've made to work with midi like this; 1) The circle is a square mapped to two controlvalues Left/Right Front/Back. You start at the center of Front, walk all the way to the Right then all the way to the Back then to the Left and back to Front again. Pretty much what a joystick would do in its extreme positions and works well with existing gear. Recommended! 2) Still two controllers, one sends the initial angle where you touchdown, the other sends delta values as you move around. A bit harder to fit in with existing gear, unless you want to play your faders like a violin :) /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
On Wed, 2009-06-17 at 03:07 +1000, Fraser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > David Robillard wrote: > > Sounds an awful lot like units to me... "degrees out of 360" is a cyclic > > unit > > Declaring the control as being in some angle UOM isn't enough to know if the > control is cyclic, as the values may just represent an arc (and > why stop at just angle UOMs), there would need to be a flag to indicate to > the host that a control is cyclic so that it could handle it > properly. Good point > IMO if this is required it's a PortProperty. Yeah, probably -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
Stefano D'Angelo schrieb: > 2009/6/13 Jörn Nettingsmeier : >> hi everyone! >> >> >> sorry if this has been discussed before, but i didn't find anything in >> the archives... >> 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). > > Hi, > > I think it makes no sense nowadays to do something like that, for two reasons: > > * LADSPA is old, hence old LADSPA hosts will not support that and > new/maintained ones are not likely to support that, since many are > focusing on newer APIs; > * An LV2 extension would allow you to do that quite easily in LV2, > which is probably preferable these days. > > That said, I can already hear people who disagree with me shouting and > screaming. I disagree. I would not mind adding support for more hints to the gstreamer ladspa wrapper. Its not a lot of work and its good to have that now even if lv2 takes over in the long run. The other think I'd like to have is hints for audio-port channel grouping/mapping. That is describe that a port is the left-channel of stereo pair named , Even if this goes to the rdf. Stefan > > Stefano > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADSPA extension for periodic control values?
2009/6/19 Stefan Kost : > Stefano D'Angelo schrieb: >> 2009/6/13 Jörn Nettingsmeier : >>> hi everyone! >>> >>> >>> sorry if this has been discussed before, but i didn't find anything in >>> the archives... >>> 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). >> >> Hi, >> >> I think it makes no sense nowadays to do something like that, for two >> reasons: >> >> * LADSPA is old, hence old LADSPA hosts will not support that and >> new/maintained ones are not likely to support that, since many are >> focusing on newer APIs; >> * An LV2 extension would allow you to do that quite easily in LV2, >> which is probably preferable these days. >> >> That said, I can already hear people who disagree with me shouting and >> screaming. > > I disagree. I would not mind adding support for more hints to the gstreamer > ladspa wrapper. Its not a lot of work and its good to have that now even if > lv2 > takes over in the long run. > > The other think I'd like to have is hints for audio-port channel > grouping/mapping. That is describe that a port is the left-channel of stereo > pair named , Even if this goes to the rdf. > > Stefan Stefan, once again, I originally misunderstood the post by Jorn thinking he wanted to add that stuff outside of the LADSPA header, the discussion went and is still going on. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
