hi everybody!
as discussed in another thread, i would like to propose a new LADSPA
release 1.2, which should include the following changes:
1. addition of a port range hint flag LADSPA_HINT_PERIODIC to denote
periodic behaviour of a control port to be added to the
LADSPA_PortRangeHintDesc
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
> 2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
>hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
>should be annotated with a set of labels rather than numbers.
>
>LADSPA_HI
Fons Adriaensen wrote:
> On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
>
>> 2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
>>hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
>>should be annotated with a set of labels rather t
2009/6/18 Fons Adriaensen :
> On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
>
>> 2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
>> hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
>> should be annotated with a set of labels rath
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: "is lrdf simple and lightw
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano D'Angelo wrote:
> > Host will need to use the value (UpperBound + 1) no matter
> > where these strings get stored. A host looping over the port
> > data should just initialise a pointer:
> >
> > const char **enum_labels = descriptor->PortNames + de
2009/6/18 Luis Garrido
> This has been debated already. Several times. For instance, please
> follow this (long) thread:
>
>
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
>
> While I think that each side of the argument has its merits, in the
> end to me it all bo
2009/6/18 Stefano D'Angelo :
> 2009/6/18 Luis Garrido
>>
>> This has been debated already. Several times. For instance, please
>> follow this (long) thread:
>>
>>
>> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
>>
>> While I think that each side of the argument has
[Fons Adriaensen]
>
>This makes is backwards compatible, as no new field is required
>in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are appended to the
struct.
(That is not to say it's hugely preferable
2009/6/18 Fons Adriaensen :
> On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano D'Angelo wrote:
>
>> > Host will need to use the value (UpperBound + 1) no matter
>> > where these strings get stored. A host looping over the port
>> > data should just initialise a pointer:
>> >
>> > const char **enum
On Thu, Jun 18, 2009 at 08:46:28PM +0200, Stefano D'Angelo wrote:
> 3. Do as Fons suggested (which to me sounds like make that tiny part of the
> API a bit counter-intuitive);
It's just a conceptual change. The port_names array
becomes a general-purpose string table, the first
NPORT values are th
2009/6/18 Fons Adriaensen :
>> 5. Add something like this to the API:
>>
>> struct {
>> float value;
>> const char *name;
>> } ladspa_port_value_enum;
>>
>> struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
>> descriptor_index, unsigned long port_index);
>
> Would not be
On Thu, Jun 18, 2009 at 08:54:39PM +0200, Stefano D'Angelo wrote:
> You would have to add the names in order of (port index, value),
> starting from PortNames + PortCount... is this really so intuitive to
> someone who occasionaly does C?
Should someone who 'occasionaly does C' write a
plugin ho
On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze wrote:
> [Fons Adriaensen]
> >
> >This makes is backwards compatible, as no new field is required
> >in the descriptor struct.
>
> AFAICS, binary compatibility is not compromised by an expanded
> descriptor struct, as long as additional member
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
> 2009/6/18 Fons Adriaensen :
> >> 5. Add something like this to the API:
> >>
> >> struct {
> >> float value;
> >> const char *name;
> >> } ladspa_port_value_enum;
> >>
> >> struct ladspa_port_value_enum * ladspa_get_port_value_enums(
2009/6/18 Fons Adriaensen :
> On Thu, Jun 18, 2009 at 08:54:39PM +0200, Stefano D'Angelo wrote:
>
>> You would have to add the names in order of (port index, value),
>> starting from PortNames + PortCount... is this really so intuitive to
>> someone who occasionaly does C?
>
> Should someone who 'o
2009/6/18 Damon Chaplin :
>
> On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
>> 2009/6/18 Fons Adriaensen :
>> >> 5. Add something like this to the API:
>> >>
>> >> struct {
>> >> float value;
>> >> const char *name;
>> >> } ladspa_port_value_enum;
>> >>
>> >> struct ladspa_port_val
2009/6/18 Fons Adriaensen :
> On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze wrote:
>
>> [Fons Adriaensen]
>> >
>> >This makes is backwards compatible, as no new field is required
>> >in the descriptor struct.
>>
>> AFAICS, binary compatibility is not compromised by an expanded
>> descriptor
[Stefano D'Angelo]
>
>Note: a weird host could copy make a copy of the descriptors (I see
>nothing claiming this should not happen in the header file), thus ABI
>would be broken... this could maybe happen in LADSPA hosts written in
>non-C languages (why does Java come to my mind?).
No, it's not a
2009/6/18 Tim Goetze :
> [Stefano D'Angelo]
>>
>>Note: a weird host could copy make a copy of the descriptors (I see
>>nothing claiming this should not happen in the header file), thus ABI
>>would be broken... this could maybe happen in LADSPA hosts written in
>>non-C languages (why does Java come
Hi,
On Thursday 18 June 2009 23:16:53 Tim Goetze wrote:
> [Stefano D'Angelo]
> >Note: a weird host could copy make a copy of the descriptors (I see
> >nothing claiming this should not happen in the header file), thus ABI
> >would be broken... this could maybe happen in LADSPA hosts written in
> >n
On Thu, Jun 18, 2009 at 10:50:45PM +0200, Stefano D'Angelo wrote:
> Now, suppose you wanted to add other kind of stuff in some future to
> ports: if they are strings, you could do this thing once again (maybe,
> maybe not), if they are not strings (e.g. units of measure as an
> enum), how to do th
On Thu, Jun 18, 2009 at 11:23:52PM +0200, Arnold Krille wrote:
> But if the plugin is v1.2 and the host is v1.1 doesn't this mean the host
> only
> used v1.1 at compile time? Then on copying the struct or on doing pointer-
> arithmetic it will only know the old size of the struct and definitely
On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote:
> Sorry, didn't see that. Well, I guess there's no problem on the plugin
> side then... any other possible problems on the host side?
>
> In case there are none, we could add an array or another callback.
You'd need a way to let the hos
2009/6/18 Damon Chaplin
>
> On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote:
>
> > Sorry, didn't see that. Well, I guess there's no problem on the plugin
> > side then... any other possible problems on the host side?
> >
> > In case there are none, we could add an array or another callb
2009/6/18 Fons Adriaensen :
>> Plus, you can't change the name of the parameter (PortNames) in the
>> descriptor, without breaking API, which is weird.
>
> You can. Fields are not referred to by name in compiled
> code. Host and plugins can use different names, except
> for symbols that are looked
Stefano D'Angelo wrote:
> You're right. Well, I vote for the extra function and leaving
> descriptor untouched too.
The extra function seems best to me as well. Sort of DSSI-like approach
(and DSSI obviously works!).
Krzysztof
___
Linux-audio-dev mail
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
> 2009/6/18 Fons Adriaensen :
> >> Plus, you can't change the name of the parameter (PortNames) in the
> >> descriptor, without breaking API, which is weird.
> >
> > You can. Fields are not referred to by name in compiled
> > code.
2009/6/19 Fons Adriaensen
> On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
>
> > 2009/6/18 Fons Adriaensen :
> > >> Plus, you can't change the name of the parameter (PortNames) in the
> > >> descriptor, without breaking API, which is weird.
> > >
> > > You can. Fields are not r
Stefano D'Angelo wrote:
> You're right. Well, I vote for the extra function and leaving descriptor
> untouched too.
What if that extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
Added bonus: we could use it to provi
2009/6/19 Krzysztof Foltman :
> Stefano D'Angelo wrote:
>
>> You're right. Well, I vote for the extra function and leaving descriptor
>> untouched too.
>
> What if that extra function was more of "get textual representation of a
> particular float value" (see: Buzz MDK) instead of "get all strings"
Stefano D'Angelo wrote:
>> What if that extra function was more of "get textual representation of a
>> particular float value" (see: Buzz MDK) instead of "get all strings"?
> But you would have to know the float values in advance...
I'm talking about a label box displayed next to a knob here, not
2009/6/19 Krzysztof Foltman :
> Stefano D'Angelo wrote:
>
>>> What if that extra function was more of "get textual representation of a
>>> particular float value" (see: Buzz MDK) instead of "get all strings"?
>> But you would have to know the float values in advance...
>
> I'm talking about a label
Stefano D'Angelo wrote:
> I do totally agree, and in fact what I was suggesting looks like:
>
> struct {
> float value;
> const char *name;
> } ladspa_port_label;
> struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
> descriptor_index, unsigned long port_index);
We are talking
2009/6/19 Krzysztof Foltman :
> Stefano D'Angelo wrote:
>
>> I do totally agree, and in fact what I was suggesting looks like:
>>
>> struct {
>> float value;
>> const char *name;
>> } ladspa_port_label;
>> struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
>> descriptor_index, uns
Stefano D'Angelo wrote:
> A little note, though: wouldn't it be better to pass this functions
> the descriptor index rather than the descriptor pointer? (This really
> is subjective taste, I guess).
I'm already thinking of reusing the same thing for DSSI, and DSSI
indexes may be overlap with LADS
2009/6/19 Krzysztof Foltman
> Stefano D'Angelo wrote:
>
> > A little note, though: wouldn't it be better to pass this functions
> > the descriptor index rather than the descriptor pointer? (This really
> > is subjective taste, I guess).
>
> I'm already thinking of reusing the same thing for DSSI,
Krzysztof Foltman wrote:
> // this gives us text-to-string for arbitrary floats (side effect of
> which is being able to implement enums)
> const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
> float value);
> // this tells us which float values have "interesting" meaning
> v
Fraser wrote:
> I'd be very happy to see this functionality too.
> This (for me) would allow the removal of just about all parameter conversions
> from the run function and just do them for display. (ie keep parameters native
> as I don't have to worry about exposing internal values to users anymor
On Fri, 2009-06-19 at 19:00 +0100, Krzysztof Foltman wrote:
> Factory presets are important, too, but it proved to be a contentious
> issue more than one time already, and you probably don't want to wait
> until everyone agrees or stops giving a damn ;). If I had my way, I'd
> probably avoid RDF
Krzysztof Foltman wrote:
> Such a change could also give you problems if you expose
> implementation-defined values (as opposed to real-life-compatible units)
> to users. Think of backward compatibility, for example.
good point.
>> While ideas are being tossed about, here are some more...
>>
>
Hi Jörn,
I've just discovered this thread (and haven't found time to go through
the tail of it). I just wanted to add that we (clam developers at
BarcelonaMedia) are facing the same problem for the 3D audio systems,
and so we'd clearly advocate for having this functionality -- either
being Ladspa
Stefano D'Angelo schrieb:
> 2009/6/18 Stefano D'Angelo :
>
>> 2009/6/18 Luis Garrido
>>
>>> This has been debated already. Several times. For instance, please
>>> follow this (long) thread:
>>>
>>>
>>> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
>>>
>>> Whi
Stefan Kost wrote:
> I like the idea of the function. A nice feature of buzzmachine plugins
> is that plugins can have a describe_value() function. It returns a port
> value as a string. This is very flexible as plugins can include the unit
> values or other characters in the string (e.g. "90°", "4
44 matches
Mail list logo