Stefano D'Angelo schrieb:
2009/6/18 Stefano D'Angelo zanga.m...@gmail.com:
2009/6/18 Luis Garrido luisgarr...@users.sourceforge.net
This has been debated already. Several times. For instance, please
follow this (long) thread:
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½ or
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 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 provide
2009/6/19 Krzysztof Foltman w...@foltman.com:
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
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 a combo
2009/6/19 Krzysztof Foltman w...@foltman.com:
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
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 about
2009/6/19 Krzysztof Foltman w...@foltman.com:
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,
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 LADSPA
2009/6/19 Krzysztof Foltman w...@foltman.com
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
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
void
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 anymore).
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 or
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...
Be
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
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 than
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
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
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
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 +
2009/6/18 Luis Garrido luisgarr...@users.sourceforge.net
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,
2009/6/18 Stefano D'Angelo zanga.m...@gmail.com:
2009/6/18 Luis Garrido luisgarr...@users.sourceforge.net
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
[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 f...@kokkinizita.net:
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
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 the
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
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
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 host
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 members are
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum *
2009/6/18 Damon Chaplin da...@karuna.eclipse.co.uk:
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
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
2009/6/18 Tim Goetze t...@quitte.de:
[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
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
non-C
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 that
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 host
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
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
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
2009/6/19 Fons Adriaensen f...@kokkinizita.net
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
Plus, you can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
39 matches
Mail list logo
