14 May
2004
14 May
'04
11:15 a.m.
well, it appears that there is little to no response to the proposal
from the LADSPA meeting at ZKM. just to be sure that the silence is an
accurate reflection of what people think, i want to take a harsh
stance on the proposal and see if it generates any response...
if we follow through with the proposal, LADSPA will no longer be a
header file. it will require the use of a library. the actual struct
in the header file will contain the absolute bare minimum information
required to actually run a plugin, nothing more. No port names, no
hints, no default values. we will try to make the library
self-contained, dependency-free, but it will still be more complex
than the current model.
moreover, there will be 2 versions of LADSPA floating around, thus
leading to problems with host/plugin compatibility issues.
personally, i think its worth going through this pain. we will end up
with a system in which new LADSPA extensions do not require changes to
the API, which is a great thing. but it will be painful to get there,
and i want to check that people don't mind doing it.
--p
14 May
14 May
12:24 p.m.
Paul Davis <paul(a)linuxaudiosystems.com> writes:
personally, i think its worth going through this pain.
we will end up
with a system in which new LADSPA extensions do not require changes to
the API, which is a great thing. but it will be painful to get there,
and i want to check that people don't mind doing it.
Seems like the right approach, but the devil is in the details. The
current scheme, though wildly successful, has been hard to extend. A
library API should be more manageable, if done carefully.
--
joq
12:58 p.m.
On Fri, May 14, 2004 at 08:36:24AM -0400, Paul Davis wrote:
well, it appears that there is little to no response
to the proposal
from the LADSPA meeting at ZKM. just to be sure that the silence is an
accurate reflection of what people think, i want to take a harsh
stance on the proposal and see if it generates any response...
if we follow through with the proposal, LADSPA will no longer be a
header file. it will require the use of a library. the actual struct
in the header file will contain the absolute bare minimum information
required to actually run a plugin, nothing more. No port names, no
hints, no default values. we will try to make the library
self-contained, dependency-free, but it will still be more complex
than the current model.
moreover, there will be 2 versions of LADSPA floating around, thus
leading to problems with host/plugin compatibility issues.
personally, i think its worth going through this pain. we will end up
with a system in which new LADSPA extensions do not require changes to
the API, which is a great thing. but it will be painful to get there,
and i want to check that people don't mind doing it.
I don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
Another solution is to use the xrm format, and then you get the library
for free - it's part of X11 client library but independent of the graphical
part of X.
I routinely use this instead of getopt() to combine configuration data
from various files and command line options into one consistent system.
As a configuration language it's quite powerful.
Another point. I've defended the adoption of simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information. At the Karlsruhe BOF
it was said that this is not true, as the LOGARITHMIC hint does not
specify the log base. Indeed it doesn't, nor is there any reason why
it should. The LOG hint means that the user would expect a widget, e.g.
a slider, that maps a certain displacement to a certain ratio (as opposed
to difference) of the controlled parameter. So the host has to do a linear
to exponential conversion, but it is completely irrelevant to what base
this calculation is done.
--
FA
2:01 p.m.
On Fri, May 14, 2004 at 04:50:31 +0200, Alfons Adriaensen wrote:
I don't mind *IFF* the metadata file has a simple,
human readable
syntax (no XML please) that can be parsed line by line.
Human readable and line by line parsable are pretty much mutually
exclusive - try expressing any complex structure in Xresources. However
its easy to have a format which can be parsed line by line, and produced
from a human writable format.
One such example is RDF/NTriples, which is a simple ASCII format that can
be parsed with a trivial regex, scanf or similar. It can be generated using
commonly available tools from RDF/N3 or RDF/XML which are human
readable/writable. It looks like:
<foo:a> <foo:b> <foo:c> .
<foo:a> <foo:d> "e" .
...
Another solution is to use the xrm format, and then
you get the library
for free - it's part of X11 client library but independent of the graphical
part of X.
Yes, but xrm misses most of the desirable feaures of metadata languages
(agreed semantics, extensibility and so on). We could just use the syntax,
but its pretty complex for non-X11 apps that want to parse it.
- Steve
2:38 p.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
On Fri, May 14, 2004 at 04:50:31 +0200, Alfons
Adriaensen wrote:
Exactly.
I'm having trouble figuring out Fons' original point here, though I'm
sure he has one. Simple and human readable are worthwhile goals, but
hard to reconcile.
Why rule out XML? It's one of the few widely-used language groups
that actually sorta meets both those requirements (*fairly* simple and
*somewhat* human-readable). ;-)
The other examples that readily come to mind are even worse. LISP
appeals to me as an alternative, but that's probably not what he
wants, either.
--
joq
I don't mind *IFF* the metadata file has a
simple, human readable
syntax (no XML please) that can be parsed line by line.
Human readable and line by line parsable are pretty much mutually
exclusive - try expressing any complex structure in Xresources.
2:53 p.m.
Why rule out XML? It's one of the few widely-used
language groups
that actually sorta meets both those requirements (*fairly* simple and
*somewhat* human-readable). ;-)
Reactions to XML can be as strong as your feelings about C++ :)
Personally, I am fan of both of them, but I don't think that forcing
the use of one of the many XML parsing libraries into a LADSPA
application is a good thing. I think that Steve's simple tuple scheme
can be parsed very easily in C code without any fun and games, and the
file is human readable if not instantly understandable.
--p
5:21 p.m.
On Fri, May 14, 2004 at 12:45:34 -0400, Paul Davis wrote:
*cough* its not my scheme, its a W3C standard.
- Steve
Why rule out
XML? It's one of the few widely-used language groups
that actually sorta meets both those requirements (*fairly* simple and
*somewhat* human-readable). ;-)
Reactions to XML can be as strong as your feelings about C++ :)
Personally, I am fan of both of them, but I don't think that forcing
the use of one of the many XML parsing libraries into a LADSPA
application is a good thing. I think that Steve's simple tuple scheme
can be parsed very easily in C code without any fun and games, and the
file is human readable if not instantly understandable.
8:08 p.m.
On Fri, May 14, 2004 at 02:48:18 -0500, Jack O'Quin wrote:
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
NTriples is defined in
http://www.w3.org/TR/rdf-testcases/#ntriples
General RDF stuff is at
http://www.w3.org/RDF/
- Steve
*cough* its not my scheme, its a W3C standard.
That's nice. How about a pointer to where it's defined? 
3:36 p.m.
On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
I'm having trouble figuring out Fons' original
point here, though I'm
sure he has one. Simple and human readable are worthwhile goals, but
hard to reconcile.
Strange.. I'd think these two would go hand in hand...
Whit 'simple' and 'line by line' I mean
- you read in a line with fgets()
- look at the first word, a keyword that tells you all about the format
of the line
- use sscanf() to read the rest.
Why rule out XML? It's one of the few widely-used
language groups
that actually sorta meets both those requirements (*fairly* simple and
*somewhat* human-readable). ;-)
*somewhat* if properly formatted and indented. And evven then it's
bloated. XML was one of the reasons I gave up on Gnome. After having read
the forests (a forest is a lot of trees) for weeks I still was unable
to kill the file browser permanently.
The other examples that readily come to mind are even
worse. LISP
appeals to me as an alternative, but that's probably not what he
wants, either.
LISP is quite nice actually, but you'd need a complete LISP engine to
read it...
It shouldn't be that hard. All we want is a list of ports and their
properties.
--
FA
5:53 p.m.
Fons Adriaensen <fons.adriaensen(a)skynet.be> writes:
I'm no great lover of XML, but at least its syntax is sufficiently
well-defined that it's easy to write a pretty-print script.
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is over half a meg. Would all the LADSPA hosts be
willing to add that and whatever else it entails to their memory
footprint?
Libxml2 is even bigger, almost a meg. I wonder how many LADSPA hosts
already use it for some other reason? I see that ardour, jamin and
hydrogen do...
$ ldd `which ardour` | grep xml
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x40297000)
--
joq
On Fri, May 14, 2004 at 11:31:01AM -0500, Jack
O'Quin wrote:
Ah. I thought you meant syntactic simplicity, not the ease of writing
an ad-hoc parser. I fully agree that the size of the library should
be moderate. But, I'm not much in favor of basing a language on
fgets() and sscanf(). Made-up languages like that are often
syntactically more complex than you might think. Try writing the BNF
if this is not clear.
I'm having trouble figuring out Fons'
original point here, though I'm
sure he has one. Simple and human readable are worthwhile goals, but
hard to reconcile.
Strange.. I'd think these two would go hand in hand...
Whit 'simple' and 'line by line' I mean
- you read in a line with fgets()
- look at the first word, a keyword that tells you all about the format
of the line
- use sscanf() to read the rest. Why rule out
XML? It's one of the few widely-used language groups
that actually sorta meets both those requirements (*fairly* simple and
*somewhat* human-readable). ;-)
*somewhat* if properly formatted and indented. And evven then it's
bloated. XML was one of the reasons I gave up on Gnome. After having read
the forests (a forest is a lot of trees) for weeks I still was unable
to kill the file browser permanently. The other
examples that readily come to mind are even worse. LISP
appeals to me as an alternative, but that's probably not what he
wants, either.
LISP is quite nice actually, but you'd need a complete LISP engine to
read it...
8:03 p.m.
On Fri, May 14, 2004 at 02:46:19 -0500, Jack O'Quin wrote:
Libxml2 is even bigger, almost a meg. I wonder how
many LADSPA hosts
already use it for some other reason? I see that ardour, jamin and
hydrogen do...
I do really like XML - it's probably saved me more programming time than
another other spec, parser writing is a pain, but XML is not without its
downsides.
I've had problems in hte past when a library and progeam want difference
versions of libxml2, its usually OK, but you have to be careful.
- Steve
16 May
16 May
9:49 p.m.
Jack O'Quin wrote:
sure, libxml2 is huge, but almost everybody will have it in memory
anyway, since it's used by other programs.
imho, xml *is* very human-readable if the DTD is sane and the output
is pretty-printed. and it's already defined, all the tools are in
place, and changing the DTD is a matter of writing a simple XSLT for
the users to convert their old versions.
so ++xml.
best,
jörn
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
Fons Adriaensen <fons.adriaensen(a)skynet.be>
writes:
>On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
<snip>
LISP is quite nice actually, but you'd need a complete LISP engine to
read it...
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is over half a meg. Would all the LADSPA hosts be
willing to add that and whatever else it entails to their memory
footprint?
Libxml2 is even bigger, almost a meg. I wonder how many LADSPA hosts
already use it for some other reason? I see that ardour, jamin and
hydrogen do...
$ ldd `which ardour` | grep xml
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x40297000) 
10:07 p.m.
On Sat, 2004-05-15 at 03:23, Joern Nettingsmeier wrote:
sure, libxml2 is huge, but almost everybody will have
it in memory
anyway, since it's used by other programs.
imho, xml *is* very human-readable if the DTD is sane and the output
is pretty-printed. and it's already defined, all the tools are in
place, and changing the DTD is a matter of writing a simple XSLT for
the users to convert their old versions.
so ++xml.
I agree. For metadata, XML or RDF is where it's at. ++++. :)
Taybin
17 May
17 May
5:01 p.m.
On Sun, 2004-05-16 at 19:59, Taybin Rutkin wrote:
On Sat, 2004-05-15 at 03:23, Joern Nettingsmeier
wrote:
Ditto. Standard, ubiquitous, obscenely large number of tools to work
with it, double plus good.
Minor gripes about it being (objectively) not nice to read (or "bloated"
or blah blah) are trivial compared to the advantages.
Then again, the libxml2 dependancy is an issue.. not sure what I think
about that one.
-Dave
sure, libxml2 is huge, but almost everybody will
have it in memory
anyway, since it's used by other programs.
imho, xml *is* very human-readable if the DTD is sane and the output
is pretty-printed. and it's already defined, all the tools are in
place, and changing the DTD is a matter of writing a simple XSLT for
the users to convert their old versions.
so ++xml.
I agree. For metadata, XML or RDF is where it's at. ++++. :)
Taybin
4:26 p.m.
Jack O'Quin wrote:
Fons Adriaensen <fons.adriaensen(a)skynet.be>
writes:
If this is the only contro for lisp/scheme there are some nice and
small implementations that are made especially for embedding and
reading of configurations. Stupid me I can't remember the nicest
and tiniest one of them :-((( Will look into it.
But I found:
- http://www.cis.rit.edu/~jerry/Software/lithp/
This is a basic, tiny LISP implementation. It was created to be a
configuration/logic file format for a game I am working on.
- http://tinyscheme.sourceforge.net/home.html
TinyScheme is a lightweight Scheme interpreter that implements as
large a subset of R5RS as was possible without getting very large
and complicated.
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
LISP is quite nice actually, but you'd need a
complete LISP engine to
read it...
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is over half a meg. Would all the LADSPA hosts be
willing to add that and whatever else it entails to their memory
footprint?
7:37 p.m.
On Mon, May 17, 2004 at 08:18:46PM +0200, Uwe Koloska wrote:
Jack O'Quin wrote:
If that's half a meg of shared code, that's not too bad. There are some
plugins of that size... OTOH, if it takes half a meg of user data per
client, that's another story,
--
FA
Fons Adriaensen <fons.adriaensen(a)skynet.be>
writes:
If this is the only contro for lisp/scheme there are some nice and
small implementations that are made especially for embedding and
reading of configurations. Stupid me I can't remember the nicest
and tiniest one of them :-((( Will look into it. LISP is quite nice actually, but you'd need a
complete LISP engine to
read it...
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is over half a meg. Would all the LADSPA hosts be
willing to add that and whatever else it entails to their memory
footprint?
4:32 p.m.
Jack O'Quin wrote:
That [Lisp] wasn't really a serious suggestion.
Just found this nice and small lisp. It is used in festival speech
synthesis system and named SIOD (Scheme in one defun)
http://www.cs.indiana.edu/scheme-repository/imp/siod.html
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
14 May
14 May
3:05 p.m.
On Fri, May 14, 2004 at 04:53:53PM +0100, Steve Harris wrote:
Yes, but xrm misses most of the desirable feaures of
metadata languages
(agreed semantics, extensibility and so on). We could just use the syntax,
but its pretty complex for non-X11 apps that want to parse it.
Actually, it's very simple. See the Aeolus main.cc for a simple example.
(there is a library used here, but it's almost trivial).
--
FA
2:05 p.m.
Alfons Adriaensen wrote:
Another point. I've defended the adoption of
simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information. At the Karlsruhe BOF
it was said that this is not true, as the LOGARITHMIC hint does not
specify the log base. Indeed it doesn't, nor is there any reason why
it should. The LOG hint means that the user would expect a widget, e.g.
a slider, that maps a certain displacement to a certain ratio (as opposed
to difference) of the controlled parameter. So the host has to do a linear
to exponential conversion, but it is completely irrelevant to what base
this calculation is done.
I thought the idea with the LOGARITHMIC hint was to maximize the
controllability of the parameter and make use of the entire slider range
better. If the base is left out, the host will have to guess, and most
often miss the optimal slider mapping.
Marcus
2:38 p.m.
On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus Andersson wrote:
Alfons Adriaensen wrote:
Sorry but this is wrong. For example, if the range is 1 to 1000, then it's
clear that 10 will be at 1/3 and 100 at 2/3 of the slider range. This does
not depend on the log base at all.
--
Fons
Another point. I've defended the adoption of
simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information. At the Karlsruhe BOF
it was said that this is not true, as the LOGARITHMIC hint does not
specify the log base. Indeed it doesn't, nor is there any reason why
it should. The LOG hint means that the user would expect a widget, e.g.
a slider, that maps a certain displacement to a certain ratio (as opposed
to difference) of the controlled parameter. So the host has to do a linear
to exponential conversion, but it is completely irrelevant to what base
this calculation is done.
I thought the idea with the LOGARITHMIC hint was to maximize the
controllability of the parameter and make use of the entire slider range
better. If the base is left out, the host will have to guess, and most
often miss the optimal slider mapping.
15 May
15 May
3:20 a.m.
Fons Adriaensen wrote:
On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus
Andersson wrote:
Interesting interpretation. This means that the mapping between the
slider and the parameter will be
f(x) = k*a^x
with k=f(0) and a = f(1) if the slider goes form 0 to 1.
In the example above, k=1 and a=1000.
This also means that it is illegal to include 0 in the parameter range.
If this is what we want LOGARITHMIC to mean, it should be documented to
this detail in the LADSPA specification. Otherwise, host and plugin
writers might get it wrong.
Marcus
Alfons Adriaensen wrote:
Sorry but this is wrong. For example, if the range is 1 to 1000, then it's
clear that 10 will be at 1/3 and 100 at 2/3 of the slider range. This does
not depend on the log base at all.
Another point. I've defended the adoption of
simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information. At the Karlsruhe BOF
it was said that this is not true, as the LOGARITHMIC hint does not
specify the log base. Indeed it doesn't, nor is there any reason why
it should. The LOG hint means that the user would expect a widget, e.g.
a slider, that maps a certain displacement to a certain ratio (as opposed
to difference) of the controlled parameter. So the host has to do a linear
to exponential conversion, but it is completely irrelevant to what base
this calculation is done.
I thought the idea with the LOGARITHMIC hint was to maximize the
controllability of the parameter and make use of the entire slider range
better. If the base is left out, the host will have to guess, and most
often miss the optimal slider mapping.
6:48 a.m.
On Sat, 15 May 2004 07:10:30 +0200
Marcus Andersson <marcus.t.andersson(a)spray.se> wrote:
Fons Adriaensen wrote:
You're right - there's an asymptote at x=0 - there's no correct way of
dealing with it. What I've done in the past is do linear conversion near
0:
to linear:
value > e : log(value)
< -e : -log(-value)
: value / e
to logarithmic
value > 1 : exp(value)
< -1 : -exp(-value)
: value * e
However, it is also perfectly valid to simply clip the lower bound. What
isn't right is for a host to *assume* that the lower bound of a
LOGARITHMIC
port is always > 0. I myself want to be able to specify a logarithmic
frequency port with range + / - 24000 for my oscillator plugins, without
having a host break by doing log(-440) or something.
Fons is right about the base. It will have no bearing on the behaviour
of slider.
-
Myk
On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus
Andersson wrote:
I thought the idea with the LOGARITHMIC hint was to maximize the
controllability of the parameter and make use of the entire slider range >better.
If the base is left out, the host will have to guess,
and most >often miss the optimal slider mapping.
Sorry but this is wrong. For example, if the range is 1 to 1000, then
it's clear that 10 will be at 1/3 and 100 at 2/3 of the slider range.
This does not depend on the log base at all.
Interesting interpretation. This means that the mapping between the
slider and the parameter will be
f(x) = k*a^x
with k=f(0) and a = f(1) if the slider goes form 0 to 1.
In the example above, k=1 and a=1000.
This also means that it is illegal to include 0 in the parameter
range.
If this is what we want LOGARITHMIC to mean, it should be documented
to this detail in the LADSPA specification. Otherwise, host and plugin
writers might get it wrong. Alfons Adriaensen wrote:
>Another point. I've defended the adoption of simple integer
enumerations>>
>(corresponding to a C switch) using the
argument that it is the
single>>missing essential feature in the port
information. At the
Karlsruhe BOF>>it was said that this is not true, as the LOGARITHMIC
hint does not>>specify the log base. Indeed it doesn't, nor is there
any reason why>>it should. The LOG hint means that the user would
expect a widget, e.g.>>a slider, that maps a certain displacement to
a certain ratio (as opposed>>to difference) of the controlled
parameter. So the host has to do a linear>>to exponential conversion,
but it is completely irrelevant to what base>>this calculation is
done.>>
7:57 a.m.
Mike Rawes wrote:
You're right - there's an asymptote at x=0 -
there's no correct way of
dealing with it. What I've done in the past is do linear conversion near
0:
to linear:
value > e : log(value)
< -e : -log(-value)
: value / e
to logarithmic
value > 1 : exp(value)
< -1 : -exp(-value)
: value * e
However, it is also perfectly valid to simply clip the lower bound. What
isn't right is for a host to *assume* that the lower bound of a
LOGARITHMIC
port is always > 0. I myself want to be able to specify a logarithmic
frequency port with range + / - 24000 for my oscillator plugins, without
having a host break by doing log(-440) or something.
But how can the host know how close to zero the exp should become
linear? What do you do with a LOGARITHMIC parameter with the range -1.0
to 1.0? Something is missing here to make the LOGARITHMIC hint
unambiguous. But maybe that's not the goal of LADSPA. :(
Marcus
9:06 a.m.
On Sat, 15 May 2004 11:46:47 +0200
Marcus Andersson <marcus.t.andersson(a)spray.se> wrote:
Mike Rawes wrote:
That's a good point.
The host could just do a simple linear mapping for small ranges, or it
may want to scale up the range internally so that only a fixed
proportion of the range (say 10%) is linear. Or it may clip the range to
+ve values. Or it could offer them all to the user as configuration
options!
We could add an extra hint for log ranges in 2.x for plugins that want
to assert a particular behaviour... it all gets a bit messy though.
There'd need to be two ranges - the linear range, and then the log
range.
-
Myk
You're right - there's an asymptote at
x=0 - there's no correct way
of
dealing with it. What I've done in the past is do linear conversion
near 0:
to linear:
value > e : log(value)
< -e : -log(-value)
: value / e
to logarithmic
value > 1 : exp(value)
< -1 : -exp(-value)
: value * e
However, it is also perfectly valid to simply clip the lower bound.
What isn't right is for a host to *assume* that the lower bound of a
LOGARITHMIC
port is always > 0. I myself want to be able to specify a logarithmic
frequency port with range + / - 24000 for my oscillator plugins,
without having a host break by doing log(-440) or something.
But how can the host know how close to zero the exp should become
linear? What do you do with a LOGARITHMIC parameter with the range
-1.0 to 1.0? Something is missing here to make the LOGARITHMIC hint
unambiguous. But maybe that's not the goal of LADSPA. :(
10:38 p.m.
On Sat, May 15, 2004 at 07:10:30AM +0200, Marcus Andersson wrote:
Interesting interpretation. This means that the
mapping between the
slider and the parameter will be
f(x) = k*a^x
with k=f(0) and a = f(1) if the slider goes form 0 to 1.
You probably meant a = f(1)/f(0).
This also means that it is illegal to include 0 in the
parameter range.
In that case you can use f(x) = x*a^x, with a = f(1).
--
FA
16 May
16 May
5:25 a.m.
Fons Adriaensen wrote:
How do I invert this function? I am stuck.
What do you propose in the case of [-20.0, 40.0]?
Marcus
On Sat, May 15, 2004 at 07:10:30AM +0200, Marcus
Andersson wrote:
Yes, thanks.
Interesting interpretation. This means that the
mapping between the
slider and the parameter will be
f(x) = k*a^x
with k=f(0) and a = f(1) if the slider goes form 0 to 1.
You probably meant a = f(1)/f(0).
This also means
that it is illegal to include 0 in the parameter range.
In that case you can use f(x) = x*a^x, with a = f(1).
9:43 a.m.
On Sun, May 16, 2004 at 09:14:46AM +0200, Marcus Andersson wrote:
How do I invert this function? I am stuck.
You need the inverse only to set the slider to a given value.
A Newton-Raphson iteration will do that very rapidly, and
the required precision is not very much (a small fraction of
a pixel).
This also means that it is illegal to include 0 in the
parameter range.
In that case you can use f(x) = x*a^x, with a = f(1).
What do you propose in the case of [-20.0, 40.0]?
For a HINT_LOGARITHMIC control, which implies that there is an
exponential conversion from the slider position to the param
value, this is just illegal (as is in fact the f(0) = 0 case).
What do you mean with a log scale from -20 to +40 ???
In fact the linear / logarithmic choice is a bit too simplistic,
It could be improved with a few more hint bits to cover some
classic cases, but for a plugin I can live with this limitation.
Another thing that is not covered is the case of simple gain
fader. If you look at the control law of a good fader on a mixing
desk, it clear that there is more precision (in dB) in the upper
range than at the bottom, and it goes down to minus infinity.
Depending on what the fader is used for, the lowest tick above
'off' could be something from -100 to -40 dB. No standard
slider widget allows you to do such a thing, and you'll need
something more general anyway.
For typical audio work, I'd think a set of about 8 to 10
control laws would cover 99.99% of all cases. It would take
just 4 hint bits to encode these cases plus some 'escape'
value for an arbitrary mapping, but I wouldn't dare propose
such a thing.
--
FA
14 May
14 May
2:08 p.m.
I don't mind *IFF* the metadata file has a simple,
human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.
Another solution is to use the xrm format, and then you
get the library
for free - it's part of X11 client library but independent of the graphical
part of X.
yes, its a nice model for sure, but LADSPA needs to work without
linkage to X. there are people who use LADSPA plugins on systems where
X is not installed.
Another point. I've defended the adoption of simple
integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information.
I just found another: side-chain and/or modulation inputs. Its not
possible to distinguish the current purpose of audio input ports, and
this is important for several interesting classes of plugins (anything
that modulates operations on one signal with another signal). This
would require Yet Another Hint.
--p
3:06 p.m.
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
The plugins I made for AMS have modulation inputs, and I don't see what's
special about them. An we still have 20 + something hint bits...
--
FA
I don't
mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess. Another
solution is to use the xrm format, and then you get the library
for free - it's part of X11 client library but independent of the graphical
part of X.
yes, its a nice model for sure, but LADSPA needs to work without
linkage to X. there are people who use LADSPA plugins on systems where
X is not installed.
Another point. I've defended the adoption of
simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information.
I just found another: side-chain and/or modulation inputs. Its not
possible to distinguish the current purpose of audio input ports, and
this is important for several interesting classes of plugins (anything
that modulates operations on one signal with another signal). This
would require Yet Another Hint.
3:22 p.m.
On Fri, 2004-05-14 at 13:07, Fons Adriaensen wrote:
! Why? This is just plain good software engineering practise. If the
configuration is read/written through library methods, the format of the
file can be improved or changed, and everything remains extensible (who
knows what people could end up doing...)
Leaving everyone to just muck around files manually is not only an
annoying uneccessary hassle, but horrible design and a huge disaster
waiting to happen.
Something changes about the file format and everything needs to be
rewritten manually to still work? Ew.
I suppose the question is _why_ would you "fiercely resist" this good
design practise?
- Dave Robillard
no XML, and
yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
4:01 p.m.
On Fri, May 14, 2004 at 01:15:37PM -0400, Dave Robillard wrote:
On Fri, 2004-05-14 at 13:07, Fons Adriaensen wrote:
! Why? This is just plain good software engineering practise. If the
configuration is read/written through library methods, the format of the
file can be improved or changed, and everything remains extensible (who
knows what people could end up doing...)
Leaving everyone to just muck around files manually is not only an
annoying uneccessary hassle, but horrible design and a huge disaster
waiting to happen.
Something changes about the file format and everything needs to be
rewritten manually to still work? Ew.
I suppose the question is _why_ would you "fiercely resist" this good
design practise?
System interfaces are often defined by an API (and even that is
questionable since it imposes a language), but file formats and
network protocols most certainly are *not* defined this way.
AFAIK, wav, ogg, mp3, mid, and hundreds of others are defined at
the file data level, not by an API.
As to changing the file format, it should be defined from the start
to be extensible, which does not mean it should be as general as XML,
It can still be a format that is specific for the application.
And even if it has to change at some point, it can still include
a version number.
--
FA
no XML,
and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
6:14 p.m.
On Fri, 2004-05-14 at 14:09, Fons Adriaensen wrote:
And by your logic every program that needs to write ogg files should do
all the encoding manually by itself. This is most certainly not the
case for brutally obvious reasons.. these reasons apply to our situation
just as well (if on a lesser scale). If you want to write an ogg file,
you use the ogg library.
It's not like the file format isn't going to be defined at all.. of
course it's going to be "defined at the file data level". That doesn't
mean every single application should be mucking with that file
manually. That would be stupid and counterproductive.
I suppose the
question is _why_ would you "fiercely resist" this good
design practise?
System interfaces are often defined by an API (and even that is
questionable since it imposes a language), but file formats and
network protocols most certainly are *not* defined this way.
AFAIK, wav, ogg, mp3, mid, and hundreds of others are defined at
the file data level, not by an API. As to changing the file format, it should be defined
from the start
to be extensible, which does not mean it should be as general as XML,
It can still be a format that is specific for the application.
And even if it has to change at some point, it can still include
a version number.
I still have no idea why the heck you actively want to load way more
work on yourself for no benefit whatsoever. Why deal with version
numbers, and compatibility issues, and manual parsing, and blah blah?
Very many problems, very few (if any) benefits.
-Dave Robillard
7:20 p.m.
On Fri, May 14, 2004 at 04:03:55PM -0400, Dave Robillard wrote:
Depends on you point of view.
--
FA
On Fri, 2004-05-14 at 14:09, Fons Adriaensen wrote:
And by your logic every program that needs to write ogg files should do
all the encoding manually by itself.
This is not my logic. Please do not make me say thing that I did never
say.
I suppose
the question is _why_ would you "fiercely resist" this good
design practise?
System interfaces are often defined by an API (and even that is
questionable since it imposes a language), but file formats and
network protocols most certainly are *not* defined this way.
AFAIK, wav, ogg, mp3, mid, and hundreds of others are defined at
the file data level, not by an API. This is most certainly not the
case for brutally obvious reasons.. these reasons apply to our situation
just as well (if on a lesser scale). If you want to write an ogg file,
you use the ogg library.
Very probably yes, but I'm not forced to do so, and the ogg format is
not defined by any library. Anyway, we're talking about something much
more complicated than a file that should describe a plugin interface.
It's not like the file format isn't going to
be defined at all.. of
course it's going to be "defined at the file data level". That
doesn't
mean every single application should be mucking with that file
manually. That would be stupid and counterproductive.
Again, I never implied that every single application should do that.
Having a defined file format does not in any way preclude the existence
of a library that is designed make dealing with that format easier.
It's up to the author of the application to decide how to do things, and
if he / she does it in a way that you do not like, you're not obliged
at all to use the application, and even less so if it comes for free.
And in this case there is no reason at all to make things so complicated
that using a library is the only practical option.
As to changing
the file format, it should be defined from the start
to be extensible, which does not mean it should be as general as XML,
It can still be a format that is specific for the application.
And even if it has to change at some point, it can still include
a version number.
I still have no idea why the heck you actively want to load way more
work on yourself for no benefit whatsoever. Why deal with version
numbers, and compatibility issues, and manual parsing, and blah blah?
Very many problems, very few (if any) benefits.
3:27 p.m.
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis
wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
I think this is a mistake. Although I know that X does have a protocol
at its core, I am convinced that the reason it has been so successful
(in addition to its feature set) is that it has had a single, standard
stable library interface. I don't know anyone now who *ever* writes X
protocol code, and I've never met anyone (except a few people I once
knew who worked on a commercial X server, and even that was more than
15 years ago).
Wrapping file formats in libraries allows the formats to change
without us forcing recompilation on anyone. Defining a file format and
believing we got it right is tantamount to a religious act
IMHO. Nobody ever gets it right first time. Even if you use a
framework like XML or xrm, you still have to define the contents.
Its also been a *very* useful approach as JACK has evolved. We have
modified the protocol several times without requiring client
recompilation.
I
don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess. The plugins I made for AMS have modulation inputs, and
I don't see what's
Take a side-chain compressor: how can a host know that one input is
for the "main signal" and the other is the side-chain? If you leave
all connections to the user (as in AMS, i think), this is discernible
by a human intelligence, but in something like ardour where the user
expects basic connectivity to be done for them, its a problem.
special about them. An we still have 20 + something
hint bits...
But that's the whole issue. Adding hint after hint after hint
... every one requires a new header file.
--p
4:10 p.m.
On Fri, May 14, 2004 at 01:19:11PM -0400, Paul Davis wrote:
This is irrelevant. Xrm has nothing to do with the X protocal, and you can
use it without having an X server. It's just a database manager that was
originally designed to hold X resources, but it's general enough to use
it for whatever you want.
One header file, yes, and then only if you want to support the new
bits.
--
FA
On Fri, May 14,
2004 at 12:01:01PM -0400, Paul Davis wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
I think this is a mistake. Although I know that X does have a protocol
at its core, I am convinced that the reason it has been so successful
(in addition to its feature set) is that it has had a single, standard
stable library interface. I don't know anyone now who *ever* writes X
protocol code, and I've never met anyone (except a few people I once
knew who worked on a commercial X server, and even that was more than
15 years ago). I
don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess. Wrapping file formats in libraries allows the formats
to change
without us forcing recompilation on anyone. Defining a file format and
believing we got it right is tantamount to a religious act
IMHO. Nobody ever gets it right first time. Even if you use a
framework like XML or xrm, you still have to define the contents.
Its also been a *very* useful approach as JACK has evolved. We have
modified the protocol several times without requiring client
recompilation.
This is an API, not a file format.
The plugins I
made for AMS have modulation inputs, and I don't see what's
Take a side-chain compressor: how can a host know that one input is
for the "main signal" and the other is the side-chain? If you leave
all connections to the user (as in AMS, i think), this is discernible
by a human intelligence, but in something like ardour where the user
expects basic connectivity to be done for them, its a problem.
special about them. An we still have 20 +
something hint bits...
But that's the whole issue. Adding hint after hint after hint
... every one requires a new header file.
4:29 p.m.
stable library
interface. I don't know anyone now who *ever* writes X
protocol code, and I've never met anyone (except a few people I once
knew who worked on a commercial X server, and even that was more than
15 years ago).
This is irrelevant. Xrm has nothing to do with the X protocal, and you can Its also been
a *very* useful approach as JACK has evolved. We have
modified the protocol several times without requiring client
recompilation.
This is an API, not a file format.
8:32 p.m.
On Fri, May 14, 2004 at 02:21:46PM -0400, Paul Davis wrote:
fons - i wasn't talking about xrm at all. i was referring to the way
that X encapulsates the X protocol in Xlib, and nobody ever deals with
the protocol itself. The protocol is the true definition of X, but
nobody uses it, and with good reason.
OK, good example. But I'm straining myself to find a second one.
And X is something immensely more complicated than a plugin description.
Also, there is not one X client lib but lots of them, and nobody could stop
me if I were foolish enough to write my own...
There's maybe a 'political' motivation behind my point of vieuw: forcing
application writers to use a library to access an otherwise undocumented
interface reminds me too much of some commercial practices that I dislike.
I really feel this goes against the spirit of any open source project.
There is a protocol involved in server/client communication. Its
isomorphous to a file format.
OK, I see your point. But this is really a protocol that is internal
to JACK and the way JACK is implemented. In the LADSPA context, we are
talking about a file format that is not internal at all - the file
is there for everyone to read or write, and its format is shared
among hundreds of plugins and tens of hosts. And we expect a plugin
author to deliver a file, not an abstraction of it.
That, for me, means that the file format itself is public, and not an
implementation detail.
--
FA
stable library interface. I don't know anyone now
who *ever* writes X
protocol code, and I've never met anyone (except a few people I once
knew who worked on a commercial X server, and even that was more than
15 years ago).
This is irrelevant. Xrm has nothing to do with the X protocal, and you can Its also been a *very* useful approach as JACK has
evolved. We have
modified the protocol several times without requiring client
recompilation.
This is an API, not a file format.
15 May
15 May
6:16 a.m.
On Sat, May 15, 2004 at 12:40:58 +0200, Fons Adriaensen wrote:
There's maybe a 'political' motivation
behind my point of vieuw: forcing
application writers to use a library to access an otherwise undocumented
interface reminds me too much of some commercial practices that I dislike.
I really feel this goes against the spirit of any open source project.
Yup, I agree, we should be forcing developers to use a single library.
If we use an open, well-known format with plenty of parsers available
(hint-hint ;) then its a non-requirement.
- Steve
14 May
14 May
5:18 p.m.
On Fri, May 14, 2004 at 07:07:59 +0200, Fons Adriaensen wrote:
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis
wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
Me too, I'd like generic metadata handlign engines to be bale to process
the plugin descriptions (eg. for documentation servers and whatnot).
- Steve
I
don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.
7:20 p.m.
On Fri, May 14, 2004 at 08:10:32PM +0100, Steve Harris wrote:
On Fri, May 14, 2004 at 07:07:59 +0200, Fons
Adriaensen wrote:
For this application, I'd very much like to see something based on OSC,
or a subset of it. After all, we're dealing with sound plugins here.
For example:
(<plugin> stands for the unique name of a plugin)
/<plugin>/addport <name>
/<plugin>/port/<name>/range 0 10
/<plugin>/port/<name>/default 5
/<plugin>/port/<name>/unit octaves
This is a trivial example of course, for a real format we'll have to
think about grouping, port types, etc.
The underlying idea here is that a command language can be used for
configuration as well, and that the _description_ of a plugin is in fact
used to _configure_ its host in order for it to be able to host the plugin.
Now if a host has already the code to accept OSC commands for plugins,
why not use a simple extension of the same code for initialisation as
well?
For example, AMS allows the user to redefine the range of a control
port. Imagine an implementation where the audio part and the GUI are
separete processes, talking to each other via OSC. The same message
that is used to dynamically redefine a slider range can be used to
set its initial range, so it would be natural to already have it
in that format in the plugin description.
Maybe I'm just dreaming...
--
Fons
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul
Davis wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
Me too, I'd like generic metadata handlign engines to be bale to process
the plugin descriptions (eg. for documentation servers and whatnot). I
don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.
7:58 p.m.
On Fri, May 14, 2004 at 11:28:42 +0200, Fons Adriaensen wrote:
For example:
(<plugin> stands for the unique name of a plugin)
/<plugin>/addport <name>
/<plugin>/port/<name>/range 0 10
/<plugin>/port/<name>/default 5
/<plugin>/port/<name>/unit octaves
This is a trivial example of course, for a real format we'll have to
think about grouping, port types, etc.
I dont really see the avantage of this - control and description are
seperate tasks, and not even closely related.
OSC is also not equiped to describe the kind of graph structures you need
to describe plugins - you could arbitrarily extend it, but what not use a
language with native graph structures?
- Steve
9:04 p.m.
On Fri, May 14, 2004 at 10:50:31PM +0100, Steve Harris wrote:
I dont really see the avantage of this - control and
description are
seperate tasks, and not even closely related.
Very closely related if you consider that the ultimate purpose of a
description is to control something. Why should there be any difference
between
A. a description of a plugin's interface,
B. a set of commands that make a host accomodate the plugin ?
Just imagine that the plugin is something that is created dynamically
by a client of the host, rather than a set of static files.
I've been using this 'pattern' for years now in all my professional
work, and it's immensely practical. All of my major applications are
MCV based, and none of them have any specific initialisation or
configuration code - all of that is done just by sourcing a command
file that is parsed by the same code that handles client commands.
In some cases they do not even read a file, they just connect to a
default client that will configure them and then log off.
If you find the use of the term 'client' strange in this context,
just consider that in an MCV based system, the GUI is a 'client'.
--
FA
15 May
15 May
6:13 a.m.
On Sat, May 15, 2004 at 01:12:13 +0200, Fons Adriaensen wrote:
On Fri, May 14, 2004 at 10:50:31PM +0100, Steve Harris
wrote:
It depends on the task the app is trying to achieve, if its trying to find
a plugin thats a "compressor" with stereo inputs then evaluating all the
instructions in the pile to try and find a match is not very convienient.
- Steve
I dont really see the avantage of this - control
and description are
seperate tasks, and not even closely related.
Very closely related if you consider that the ultimate purpose of a
description is to control something. Why should there be any difference
between
A. a description of a plugin's interface,
B. a set of commands that make a host accomodate the plugin ?
10:38 p.m.
On Sat, May 15, 2004 at 09:05:57AM +0100, Steve Harris wrote:
On Sat, May 15, 2004 at 01:12:13 +0200, Fons
Adriaensen wrote:
Just use a command that will add the necessary information to a database
maintained by the host. Searching for a plugin and actually hosting it
are two separate actions.
--
FA
On Fri, May 14, 2004 at 10:50:31PM +0100, Steve
Harris wrote:
It depends on the task the app is trying to achieve, if its trying to find
a plugin thats a "compressor" with stereo inputs then evaluating all the
instructions in the pile to try and find a match is not very convienient. I dont really see the avantage of this - control
and description are
seperate tasks, and not even closely related.
Very closely related if you consider that the ultimate purpose of a
description is to control something. Why should there be any difference
between
A. a description of a plugin's interface,
B. a set of commands that make a host accomodate the plugin ?
11:23 p.m.
On Sun, May 16, 2004 at 02:43:17 +0200, Fons Adriaensen wrote:
Just use a command that will add the necessary information to a database
maintained by the host. Searching for a plugin and actually hosting it
are two separate actions.
If oyu regrard that as a command then surely every piece of data is a
command, and its a bit of a pointless distinction.
- Steve
A. a description of a plugin's interface,
B. a set of commands that make a host accomodate the plugin ?
It depends on the task the app is trying to achieve, if its trying to find
a plugin thats a "compressor" with stereo inputs then evaluating all the
instructions in the pile to try and find a match is not very convienient.
16 May
16 May
9:42 a.m.
On Sun, May 16, 2004 at 02:15:11AM +0100, Steve Harris wrote:
Every piece of data (in this context) will eventually be used to
specify some action, but not always the same one.
The advantage of using a command to add something to a table is
that you can also have commands to remove or modify that data.
For example you can tell the app that something is no longer
available, or has changed.
--
FA
On Sun, May 16, 2004 at 02:43:17 +0200, Fons
Adriaensen wrote:
Just use a
command that will add the necessary information to a database
maintained by the host. Searching for a plugin and actually hosting it
are two separate actions.
If oyu regrard that as a command then surely every piece of data is a
command, and its a bit of a pointless distinction.
17 May
17 May
6:16 a.m.
Fons Adriaensen wrote:
For this application, I'd very much like to see
something based on OSC,
or a subset of it. After all, we're dealing with sound plugins here.
For example:
(<plugin> stands for the unique name of a plugin)
/<plugin>/addport <name>
^^^^^^^^
see how the magic of angle brackets has begun to work on fons
already? there is hope ;-)
/me runs
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
6:44 a.m.
On Mon, May 17, 2004 at 09:26:31AM +0200, Joern Nettingsmeier wrote:
Aaaaarrrggghh ! My reputation is going down the drain !
Seriously now, having to choose between LISP or XML, I'd be 100%
on the LISP side. For those who really want XML, it should be
possible to come up with a LISP function that will just generate
it from the LISP description - the inverse seems to be a bit
more difficult.
ISTR someone at LADconf 2 also proposed to use LISP for configuration
and I kind of liked the idea.
--
FA
/<plugin>/addport <name>
^^^^^^^^
see how the magic of angle brackets has begun to work on fons
already? there is hope ;-)
7:03 a.m.
On Mon, May 17, 2004 at 10:36:27 +0200, Alfons Adriaensen wrote:
Seriously now, having to choose between LISP or XML,
I'd be 100%
on the LISP side. For those who really want XML, it should be
possible to come up with a LISP function that will just generate
it from the LISP description - the inverse seems to be a bit
more difficult.
I have to assume you're joking here ;)
Even if you just mean s-expressions, theres a reason why they flopped as a
data format - their really hard to prettyprint and really hard to read if
their not prettprinted. XML has been described as s-expressions with names
attributes - and thats exactly what it is (give or take), but naming the
attributes is important for human readability.
In any case, the syntax is only a part of any metadata language, the
semantics and guaranteeing extensibility are the hard part.
Guaranteeing extensibility with a naive XML Schema is hard, guaranteeing
it with an agreed s-expression syntax is almost impossible.
- Steve
3 p.m.
On Mon, May 17, 2004 at 10:36:27AM +0200, Alfons Adriaensen wrote:
On Mon, May 17, 2004 at 09:26:31AM +0200, Joern
Nettingsmeier wrote:
Aaaaarrrggghh ! My reputation is going down the drain
!
Seriously now, having to choose between LISP or XML, I'd be 100%
on the LISP side. For those who really want XML, it should be
possible to come up with a LISP function that will just generate
it from the LISP description - the inverse seems to be a bit
more difficult.
ISTR someone at LADconf 2 also proposed to use LISP for configuration
and I kind of liked the idea.
I think that was Jaroslav proposing LISP for replacing the current
.asoundrc configuration syntax.
-Eric Rz.
/<plugin>/addport <name>
^^^^^^^^
see how the magic of angle brackets has begun to work on fons
already? there is hope ;-)
5:01 p.m.
On Mon, 2004-05-17 at 04:36, Alfons Adriaensen wrote:
On Mon, May 17, 2004 at 09:26:31AM +0200, Joern
Nettingsmeier wrote:
Aaaaarrrggghh ! My reputation is going down the drain !
Seriously now, having to choose between LISP or XML, I'd be 100%
on the LISP side. For those who really want XML, it should be
possible to come up with a LISP function that will just generate
it from the LISP description - the inverse seems to be a bit
more difficult.
ISTR someone at LADconf 2 also proposed to use LISP for configuration
and I kind of liked the idea.
How about scheme?
Hey, it's the official scripting language of the GNU system.. :)
-Dave Robillard
/<plugin>/addport <name>
^^^^^^^^
see how the magic of angle brackets has begun to work on fons
already? there is hope ;-)
7:12 p.m.
On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard wrote:
We don't have a scripting language problem, we have a metadata problem.
Square peg, round hole.
- Steve
ISTR someone
at LADconf 2 also proposed to use LISP for configuration
and I kind of liked the idea.
How about scheme?
Hey, it's the official scripting language of the GNU system.. :)
18 May
18 May
6:44 a.m.
On Mon, May 17, 2004 at 10:04:22PM +0100, Steve Harris wrote:
On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard
wrote:
> How about scheme?
>
> Hey, it's the official scripting language of the GNU system.. :)
Indeed it is, and a good choice IMHO.
We don't have a scripting language problem, we
have a metadata problem.
Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
--
FA
19 May
19 May
8:32 a.m.
On Tue, May 18, 2004 at 10:36:03 +0200, Alfons Adriaensen wrote:
This is not right. A scripting language (well, nay suitably expressive
syntax for that matter) can express metadata structures, but thats only a
partial solution.
- Steve
We don't
have a scripting language problem, we have a metadata problem.
Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
8:41 a.m.
On Wed, May 19, 2004 at 11:24:36AM +0100, Steve Harris wrote:
On Tue, May 18, 2004 at 10:36:03 +0200, Alfons
Adriaensen wrote:
This is not right. A scripting language (well, nay suitably expressive
syntax for that matter) can express metadata structures, but thats only a
partial solution.
What's missing ?
--
FA
We
don't have a scripting language problem, we have a metadata problem.
Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
9:05 a.m.
On Wed, May 19, 2004 at 11:24:36AM +0100, Steve Harris
wrote:
fons, do you know what steve actually gets paid for? :))
On Tue, May 18, 2004 at 10:36:03 +0200, Alfons
Adriaensen wrote:
This is not right. A scripting language (well, nay suitably expressive
syntax for that matter) can express metadata structures, but thats only a
partial solution.
What's missing ? We
don't have a scripting language problem, we have a metadata problem.
Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
9:26 a.m.
What's missing ?
Semantics. You can define a single layer metadata system with virtually no
(machine) semnatics, eg.
hasTitle: "my plugin"
hasPortCount: "3"
...
but you quickly run into problems when trying to encode anything
interesting, like port 3 is a "contol in port" with a lower range of 0 and an
upper range of the "max delay" port, it uses milliseconds as its units,
should be controlled logarithmically...
You can hack it all in lexically, but then your back to a sitatution where
you can paint yourself into a corner w.r.t. back/forward compatibility.
To get round this, good metadata languages are defined so that they are
monotonic and with a few other interesting properties that logicians care
about.
If you are interested in the mathematical properties, then read the RDF
model theory: http://www.w3.org/TR/rdf-mt/ its a bit dry though :)
NB I wouldnt suggest we require RDFS for LADSPA, just RDF. RDFS makes it
much more challenging to implement if you dont want to use a standard
library, and we really wouldn't gain much.
- Steve
11:46 a.m.
On Wed, May 19, 2004 at 12:18:25PM +0100, Steve Harris wrote:
As far as I can see, everything that can be expressed by an RDF graph or
a set of triplets or the eqeuivalent XML can be equally well expressed by
nested property lists in LISP or even nested structs in C/C++.
The use of URIs in this case seems to me like complete overkill, there is
no requirement that every identifier is webwide uinique since we have a
well defined context.
What's
missing ?
Semantics. You can define a single layer metadata system with virtually no
(machine) semnatics, eg.
hasTitle: "my plugin"
hasPortCount: "3"
...
but you quickly run into problems when trying to encode anything
interesting, like port 3 is a "contol in port" with a lower range of 0 and an
upper range of the "max delay" port, it uses milliseconds as its units,
should be controlled logarithmically...
You can hack it all in lexically, but then your back to a sitatution where
you can paint yourself into a corner w.r.t. back/forward compatibility. To get round this, good metadata languages are defined
so that they are
monotonic and with a few other interesting properties that logicians care
about.
At some point in your program, metadata will be translated into variable
values. If at that point you decide that B overrides A, things are no
longer monotonic, and there's nothing to stop you from doing that even
if the values of A and B were originally derived from RDF.
When you add a field to a C struct, that does not change the value of any
other, so I'd say that is monotonic as well, unless you decide to destroy
that property as described above.
If you are interested in the mathematical properties,
then read the RDF
model theory: http://www.w3.org/TR/rdf-mt/ its a bit dry though :)
NB I wouldnt suggest we require RDFS for LADSPA, just RDF. RDFS makes it
much more challenging to implement if you dont want to use a standard
library, and we really wouldn't gain much.
Do you mean you would have a dedicated parser that must be updated each
time a property is added, rather than a general one driven by a schema ?
In that case nothing is gained at all.
--
FA
1:43 p.m.
On Wed, May 19, 2004 at 03:38:09 +0200, Alfons Adriaensen wrote:
Thats an API issue. You and I both agree we shouldn't be tied to a single
API (though thats not a widespread belief).
No, the parser is generic. The only thing that changes is what happens in
the API - if you dont update your API then you dont get new stuff, but
also it wont break. This beats trivial XML encodings and fixed structures
in my experience.
An NTriples parser has two rules:
<uri> <uri> <uri> .
<uri> <uri> "literal" .
- Steve
As far as I can see, everything that can be expressed
by an RDF graph or
a set of triplets or the eqeuivalent XML can be equally well expressed by
nested property lists in LISP or even nested structs in C/C++.
Pretty much, yes, however you loose the guarantee of monotinicity, and you
need some language specific constructs to deal with the data structres.
RDF graphs are just graphs.
The use of URIs in this case seems to me like complete
overkill, there is
no requirement that every identifier is webwide uinique since we have a
well defined context.
Maybe, but to mee it seems like one of the few problems with LADSPA is the
mess of the label+file+uid, using URIs would do away with that, is very
simple, and doesnt require central administration.
To get round
this, good metadata languages are defined so that they are
monotonic and with a few other interesting properties that logicians care
about.
At some point in your program, metadata will be translated into variable
values. If at that point you decide that B overrides A, things are no
longer monotonic, and there's nothing to stop you from doing that even
if the values of A and B were originally derived from RDF. When you add a field to a C struct, that does not
change the value of any
other, so I'd say that is monotonic as well, unless you decide to destroy
that property as described above.
But when you add a field to an array of structs thats no longer true (eg.
adding unints to the port structure). You have to either sacrifice
clenliness or break binary compatibility.
If you use graph structures you can just add additional edges to the port
node (vertex), without changing the representation of the metadata from the
older schema.
If you are
interested in the mathematical properties, then read the RDF
model theory: http://www.w3.org/TR/rdf-mt/ its a bit dry though :)
NB I wouldnt suggest we require RDFS for LADSPA, just RDF. RDFS makes it
much more challenging to implement if you dont want to use a standard
library, and we really wouldn't gain much.
Do you mean you would have a dedicated parser that must be updated each
time a property is added, rather than a general one driven by a schema ?
In that case nothing is gained at all.
11:20 a.m.
On Wed, May 19, 2004 at 06:57:27AM -0400, Paul Davis wrote:
No, and whatever it is does not IMHO imply that no questions
can be asked.
--
FA
On Wed, May 19,
2004 at 11:24:36AM +0100, Steve Harris wrote:
fons, do you know what steve actually gets paid for? :)) On Tue, May 18, 2004 at 10:36:03 +0200, Alfons
Adriaensen wrote:
What's missing ? > We don't have a scripting language
problem, we have a metadata problem.
> Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
This is not right. A scripting language (well, nay suitably expressive
syntax for that matter) can express metadata structures, but thats only a
partial solution.
3:57 p.m.
This is not
right. A scripting language (well, nay suitably expressive
syntax for that matter) can express metadata structures, but thats only a
partial solution.
What's missing ? 
26 May
26 May
11:05 p.m.
On tis, 2004-05-18 at 10:36, Alfons Adriaensen wrote:
On Mon, May 17, 2004 at 10:04:22PM +0100, Steve Harris
wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Uhmm .. This is a mistake already well documented with the Microsoft
Office/Visual Basic combo.
/jens
On Mon, May 17, 2004 at 02:55:16 -0400, Dave
Robillard wrote:
> How about scheme?
>
> Hey, it's the official scripting language of the GNU system.. :)
Indeed it is, and a good choice IMHO.
We don't have a scripting language problem,
we have a metadata problem.
Square peg, round hole.
Scripting will handle metadata without any problem.
Universal peg, hole shape doesn't matter.
18 May
18 May
10:26 a.m.
On Mon, 2004-05-17 at 17:04, Steve Harris wrote:
On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard
wrote:
We don't have a scripting language problem, we have a metadata problem.
Square peg, round hole.
- Steve
This is where, if I was actually a LISP-ish language advocate, would go
on some silly rant about code being data or somesuch.
Buuuut I was joking really. XML was designed specifically for this sort
of thing, scheme was not. As nice and elegant as scheme is, more people
are more comfortable with XML-ey things than LISP-ey things (mostly due
to HTML.. every idiot has done some HTML, but functional programming
languages are more in the domain of us academic weenies and thus more
exclusive).
I think easing the burden on (potential) developers is pretty high up on
the priority list. Plus, we just don't need the power of scheme; and as
people have already mentioned, libxml2 is used damn near everywhere
anyway, so might as well use it. (Guile is, unfortunately, not even
remotely as commonly used..)
So, ++xml, because reinventing the wheel is stupid. While I understand
the kneejerk anti-xml reaction (damn buzzwords) it just seems like the
right tool for the job...
-Dave Robillard
ISTR
someone at LADconf 2 also proposed to use LISP for configuration
and I kind of liked the idea.
How about scheme?
Hey, it's the official scripting language of the GNU system.. :)
1:37 p.m.
Dave Robillard <drobilla(a)connect.carleton.ca> writes:
So, ++xml, because reinventing the wheel is stupid.
While I understand
the kneejerk anti-xml reaction (damn buzzwords) it just seems like the
right tool for the job...
I've been reading up on Steve's N-triples suggestion...
NTriples is defined in
http://www.w3.org/TR/rdf-testcases/#ntriples
General RDF stuff is at
http://www.w3.org/RDF/
This approach has considerable merit...
(1) It is a W3C standard.
(2) It is mathematically deep and well thought out.
(3) It is specifically intended for adding property lists to the web
(4) The syntax is well-defined
(5) No large parsing library is needed
(6) There are tools for converting to XML
While I like both XML and LISP for various reasons, I really think
this proposal deserves a closer look. It looks like a wonderful
solution for LADSPA metadata. ++N_triples.
--
joq
19 May
19 May
8:39 a.m.
On Tue, May 18, 2004 at 10:29:56 -0500, Jack O'Quin wrote:
I've been reading up on Steve's N-triples
suggestion...
And from, more importantly. It can also be converted to from the other human
friendly RDF syntaxes; N3 and Turtle. Infact NTriples is a valid subset of
both those.
For clarity, and backing up what I was saying eariler about syntax and
semantics being inpependent problems, RDF is the semnatics, and RDF/XML,
/NTriples etc. are the syntaxes. ITs not neccesary for people to
understand the semantics to write RDF docuemnts, but it is neccesary for
them to understan the syntax.
An RDF (and most ofther metadata languages) syntax just needs to have a
way of expressing a list of graph edge triples, so you could do
('http://foo.com#bar 'http://a.com#b "qux")
if you wanted ;) but why reinvent the wheel?
- Steve
NTriples is defined in
http://www.w3.org/TR/rdf-testcases/#ntriples
General RDF stuff is at
http://www.w3.org/RDF/
This approach has considerable merit...
(1) It is a W3C standard.
(2) It is mathematically deep and well thought out.
(3) It is specifically intended for adding property lists to the web
(4) The syntax is well-defined
(5) No large parsing library is needed
(6) There are tools for converting to XML 
26 May
26 May
8:54 p.m.
[Steve Harris]
i like this approach better than the lisp proposal, most importantly
because it gives us free choice of language for the metadata file
parser. besides, imo it offers much more intuitive syntax, not to
mention existing support software for machine-based data mangling.
other than that, i'm eager to know how plugin ports are to be
referenced in the metadata file. by ID or numerical index? if by ID,
is it the full path to the port: "/SupaPlug/LFO 1/Frequency", or
something more concise? (i'm for a full path scheme because it
allows the plugin writer to reorder ports painlessly.)
tim
On Tue, May 18, 2004 at 10:29:56 -0500, Jack O'Quin
wrote:
> I've been reading up on Steve's N-triples suggestion...
[...]
(1) It is a
W3C standard.
(2) It is mathematically deep and well thought out.
(3) It is specifically intended for adding property lists to the web
(4) The syntax is well-defined
(5) No large parsing library is needed
(6) There are tools for converting to XML
And from, more importantly. It can also be converted to from the other human
friendly RDF syntaxes; N3 and Turtle. Infact NTriples is a valid subset of
both those.
10:22 p.m.
On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze wrote:
other than that, i'm eager to know how plugin
ports are to be
referenced in the metadata file. by ID or numerical index? if by ID,
is it the full path to the port: "/SupaPlug/LFO 1/Frequency", or
something more concise? (i'm for a full path scheme because it
allows the plugin writer to reorder ports painlessly.)
I think thats an open question, it depends on the metadata language - RDF
has some sequence primatives, but I prefer not to use them.
In lrdf you call the ports <foo>.0, <foo>.1 etc. where <foo> if the URI
of
the plugin. It doesnt really matter how you do it.
- Steve
11:30 p.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze
wrote:
How about <foo>/port/0, <foo>/port/1, etc.?
Slashes are a natural separator for forming URI's. The plugin writer
can organize them as desired.
--
joq
other than that, i'm eager to know how plugin
ports are to be
referenced in the metadata file. by ID or numerical index? if by ID,
is it the full path to the port: "/SupaPlug/LFO 1/Frequency", or
something more concise? (i'm for a full path scheme because it
allows the plugin writer to reorder ports painlessly.)
I think thats an open question, it depends on the metadata language - RDF
has some sequence primatives, but I prefer not to use them.
In lrdf you call the ports <foo>.0, <foo>.1 etc. where <foo> if the URI
of
the plugin. It doesnt really matter how you do it.
27 May
27 May
8:30 a.m.
On Wed, May 26, 2004 at 08:22:17 -0500, Jack O'Quin wrote:
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
Yeah you can do that as long as you dont use qnames in your URIs (eg.
http://foo.com/bar#baz) but that might be a good idea anyway.
- Steve
On Thu, May 27, 2004 at 12:41:36 +0200, Tim
Goetze wrote:
How about <foo>/port/0, <foo>/port/1, etc.?
Slashes are a natural separator for forming URI's. The plugin writer
can organize them as desired. other than that, i'm eager to know how plugin
ports are to be
referenced in the metadata file. by ID or numerical index? if by ID,
is it the full path to the port: "/SupaPlug/LFO 1/Frequency", or
something more concise? (i'm for a full path scheme because it
allows the plugin writer to reorder ports painlessly.)
I think thats an open question, it depends on the metadata language - RDF
has some sequence primatives, but I prefer not to use them.
In lrdf you call the ports <foo>.0, <foo>.1 etc. where <foo> if the URI
of
the plugin. It doesnt really matter how you do it. 
14 May
14 May
1:37 p.m.
On Fri, May 14, 2004 at 08:36:24AM -0400, Paul Davis wrote:
well, it appears that there is little to no response
to the proposal
from the LADSPA meeting at ZKM. just to be sure that the silence is an
accurate reflection of what people think, i want to take a harsh
stance on the proposal and see if it generates any response...
if we follow through with the proposal, LADSPA will no longer be a
header file. it will require the use of a library. the actual struct
in the header file will contain the absolute bare minimum information
required to actually run a plugin, nothing more. No port names, no
hints, no default values. we will try to make the library
self-contained, dependency-free, but it will still be more complex
than the current model.
moreover, there will be 2 versions of LADSPA floating around, thus
leading to problems with host/plugin compatibility issues.
there will be LADSPA and LADSPA2.
i dont see what the problem would be ?
we should make sure that the v2plugin metadata contains a hint which
v1 plugin is made obsolete by this v2plugin, so that i can have ladspa 1
and 2 support in the host without the user seeing the same plugin 2 times.
personally, i think its worth going through this pain.
we will end up
with a system in which new LADSPA extensions do not require changes to
the API, which is a great thing. but it will be painful to get there,
and i want to check that people don't mind doing it.
votes++
metadata is metadata.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
1:46 p.m.
On Friday 14 May 2004 15:33, torbenh(a)gmx.de wrote:
we should make sure that the v2plugin metadata
contains a hint which
v1 plugin is made obsolete by this v2plugin
Will it be possible for the same plugin to implement both v1 and v2?
(I would have thought that was probably a necessity, but then I don't write
plugins.)
Chris
3:02 p.m.
--- Chris Cannam <cannam(a)all-day-breakfast.com> wrote: > On Friday 14 May 2004
15:33, torbenh(a)gmx.de wrote:
Ooh. That's a good point...
I've written a few plugins, and the thought of maintaining two versions of
otherwise identical plugins doesn't appeal. It is possible to combine two
versions in the source, and determine which version to build at compile time.
I don't think it is feasible to have a single plugin provide both v1 and v2 at
run time (say, if a 1.x only host and a 2.x only host are wanting the same
plugin) - the plugin descriptors won't be binary compatible.
-
Myk
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
we should make
sure that the v2plugin metadata contains a hint which
v1 plugin is made obsolete by this v2plugin
Will it be possible for the same plugin to implement both v1 and v2?
(I would have thought that was probably a necessity, but then I don't write
plugins.)
5:25 p.m.
On Fri, May 14, 2004 at 05:45:58 +0100, Mike Rawes wrote:
My vague plan was to stop supporting v1 directly and to provide a v1
meta plugin wrapper that presents my v2 plugins via a v1 interface.
The alternaive is that I stop supporting v1 alltogether. The old versions
will still be avialable ofcourse.
- Steve
Will it be
possible for the same plugin to implement both v1 and v2?
(I would have thought that was probably a necessity, but then I don't write
plugins.)
Ooh. That's a good point...
I've written a few plugins, and the thought of maintaining two versions of
otherwise identical plugins doesn't appeal. It is possible to combine two
versions in the source, and determine which version to build at compile time. 
5:52 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
re,
On Fri, May 14, 2004 at 08:17:30PM +0100, Steve Harris wrote:
On Fri, May 14, 2004 at 05:45:58 +0100, Mike Rawes
wrote:
My vague plan was to stop supporting v1 directly and to provide a v1
meta plugin wrapper that presents my v2 plugins via a v1 interface.
The alternaive is that I stop supporting v1 alltogether. The old versions
will still be avialable ofcourse.
gosh, i'm just writing a library for video plugins, inspired to LADSPA
"inspired" means that it is about a simple header, which doesn't
requires a library. see
http://livido.dyne.org/livido-22apr04.tar.gz
we are allready quite some people focusing on it, from different
emerging video applications as FreeJ, VeeJay, PD/PDP, LiVES
what do you say guys, on the long term it's really bad to have this
header-oriented spec? or you're doing the change just now that everybody
joined the train, wouldn't have been a good choice since the beginning? ;>
i'm not provoking, i'm just trying to learn :)
from what i could really understand from this thread. the header/lib
dependency is the main thing which differentiates the LADSPA v1 from v2,
seen from an architectural point of view.
would have been a good choice since the beginning, to have it as a lib?
thanks & respect,
- --
jaromil, dyne.org rasta coder, http://rastasoft.org
Will it
be possible for the same plugin to implement both v1 and
v2?
(I would have thought that was probably a necessity, but then I
don't write plugins.)
Ooh. That's a good point...
I've written a few plugins, and the thought of maintaining two versions of
otherwise identical plugins doesn't appeal. It is possible to combine two
versions in the source, and determine which version to build at compile time. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Cryptographically signed mail, see http://gnupg.org
iD8DBQFApSLwWLCC1ltubZcRAohEAJ95ZHdJ+8KfIvKDks83yFvi71/WDACePJPO
EZgd5JGmJcvE09DfrupTeq0=
=LF+l
-----END PGP SIGNATURE-----
6:04 p.m.
jaromil <jaromil(a)dyne.org> writes:
would have been a good choice since the beginning, to
have it as a lib?
Maybe so. But, it's important to keep this in perspective.
LADSPA has been a great success, and simplicity was one of the main
reasons. Now that the concept is proven, people are willing to invest
more time and effort into its evolution. In the beginning, to get a
foothold, it had to be extremely simple.
"A complex system that works has always evolved from a simpler
system that worked."
--
joq
17 May
17 May
4:21 p.m.
On Fri, 2004-05-14 at 20:50, jaromil wrote:
what do you say guys, on the long term it's really
bad to have this
header-oriented spec? or you're doing the change just now that everybody
joined the train, wouldn't have been a good choice since the beginning? ;>
The main thing that came out of the LAC meeting was that the header file
was the wrong place for metadata. The port hints, port names, plugin
information, etc, etc, should be elsewhere in an easy to use metadata
language. It's the use of external data that suggests a client
library. Of course, there is no need to employ any particular library,
or even any 3rd party library, dependant on the ease of parsing the
metadata language.
HTH,
Bob
--
Bob Ham <rah(a)bash.sh>
14 May
14 May
2:16 p.m.
--- Paul Davis <paul(a)linuxaudiosystems.com> wrote:
well, it appears that there is little to no response
to the proposal
from the LADSPA meeting at ZKM. just to be sure that the silence is an
accurate reflection of what people think, i want to take a harsh
stance on the proposal and see if it generates any response...
if we follow through with the proposal, LADSPA will no longer be a
header file. it will require the use of a library. the actual struct
in the header file will contain the absolute bare minimum information
required to actually run a plugin, nothing more. No port names, no
hints, no default values. we will try to make the library
self-contained, dependency-free, but it will still be more complex
than the current model.
I'm OK with the proposal. The complexity can be hidden in the library - at the
moment hosts effectively have their own built in library for LADSPA 1.x anyway
(I wrote one for Spiral Synth Modular).
Minor nitpick regarding what is carried over as metadata from 1.x: Can we get
rid of the label? - I never did see the use for it. The ID is sufficient for
identifying plugins, and the name (as metadata) for presenting in a UI.
-
Myk
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
5:23 p.m.
On Fri, May 14, 2004 at 05:08:53 +0100, Mike Rawes wrote:
Minor nitpick regarding what is carried over as
metadata from 1.x: Can we get
rid of the label? - I never did see the use for it. The ID is sufficient for
identifying plugins, and the name (as metadata) for presenting in a UI.
Actually I'd like to get rid if the UID (its useless for generated plugins
and has a significant adminstrative overhead) and just roll it into the
label with a URI scheme.
that way everyone can administer thier own unique ID scheme.
- Steve
15 May
15 May
7:12 a.m.
On Fri, 14 May 2004 20:15:39 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Fri, May 14, 2004 at 05:08:53 +0100, Mike Rawes
wrote:
Fair enough. My gripe about the label is that it can be used as an
identifier (together with the filename), which can break things. So long
as there's only one identifier in 2.x I'm happy!
-
Myk
Minor nitpick regarding what is carried over as
metadata from 1.x:
Can we get rid of the label? - I never did see the use for it. The
ID is sufficient for identifying plugins, and the name (as metadata)
for presenting in a UI.
Actually I'd like to get rid if the UID (its useless for generated
plugins and has a significant adminstrative overhead) and just roll it
into the label with a URI scheme.
that way everyone can administer thier own unique ID scheme.
12:17 p.m.
On Sat, May 15, 2004 at 10:04:24 +0100, Mike Rawes wrote:
The .h file says you should use label+filename IIRC, its just a mess.
- Steve
Actually
I'd like to get rid if the UID (its useless for generated
plugins and has a significant adminstrative overhead) and just roll it
into the label with a URI scheme.
that way everyone can administer thier own unique ID scheme.
Fair enough. My gripe about the label is that it can be used as an
identifier (together with the filename), which can break things. So long
as there's only one identifier in 2.x I'm happy!
7425
days inactive
7438
days old
linux-audio-dev@lists.linuxaudio.org
81 comments
18 participants
participants (18)
-
Alfons Adriaensen -
Bob Ham -
Chris Cannam -
Dave Robillard -
Eric Dantan Rzewnicki -
Fons Adriaensen -
Jack O'Quin -
jaromil -
Jens M Andreasen -
Joern Nettingsmeier -
Marcus Andersson -
Mike Rawes -
Paul Davis -
Steve Harris -
Taybin Rutkin -
Tim Goetze -
torbenh＠gmx.de -
Uwe Koloska