22 Apr
2006
22 Apr
'06
7:54 a.m.
Almost two years ago at the LA conference a bunch of us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
The .ladspa2 plugin is a "bundle", ie. a directory with all the data the
plugin needs in it. This idea is nicked from OPENSTEP. I'm not 100%
convinced it's a good idea, but I think it makes sense for plugins.
The dsp core (amp.c) is just a LADSPA 1.1 plugin with all the fixed data
fields taken out, and a URI field added, to allow for working
identification. I also dropped the runAdding method, as I dont think it
is used enough to justify the effort of supporting it. The plugin is
untested, but it compiles and nm reports sane contents for it.
The data is in the amp.ttl file (it's in Turtle
http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax).
We could mandate a particular syntax for the spec.
There's a shell script (show-data.sh) which, if you have raptor and rasqal
installed will do something similar to what analyseplugin does for LADSPA
1.x, but it's very crude.
Overall I think this is a much better approach than LADSPA 1.x, it has
usable identifiers, a clear route for extensions without compatibility
problems and each plugin is quite a lot simpler.
- Steve
22 Apr
22 Apr
8:19 a.m.
On Sat, 2006-04-22 at 10:53 +0100, Steve Harris wrote:
Almost two years ago at the LA conference a bunch of
us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
Nice. The header and the plugin code really looks a lot cleaner without
all the metadata embedded in it.
The data is in the amp.ttl file (it's in Turtle
http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax).
We could mandate a particular syntax for the spec.
It looks a lot nicer than the XML syntax.
Overall I think this is a much better approach than
LADSPA 1.x, it has
usable identifiers, a clear route for extensions without compatibility
problems and each plugin is quite a lot simpler.
What type of extensions are you talking about here, and what is the
clear route?
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
2:46 p.m.
On 4/22/06, Lars Luthman <larsl(a)users.sourceforge.net> wrote:
On Sat, 2006-04-22 at 10:53 +0100, Steve Harris
wrote:
Agreed. I really like getting all that XML out of the C sources. Much
cleaner and more accessible.
A minor suggestion: how about moving that SYMBOL_EXPORT definition
into ladspa-2.h, presumably with a LADSPA_ prefix?
#ifdef WIN32
#define SYMBOL_EXPORT __declspec(dllexport)
#else
#define SYMBOL_EXPORT
#endif
--
joq
Almost two years ago at the LA conference a bunch
of us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
Nice. The header and the plugin code really looks a lot cleaner without
all the metadata embedded in it.
2:56 p.m.
On Sat, Apr 22, 2006 at 11:46:28AM -0500, Jack O'Quin wrote:
The XML+C thing was a Steve-brand hack, not part of the spec, I dont think
anyone else was doing it. The metadata was generally static C char *'s,
but that was very limiting, and led to a lot of tedious cut-and-paste
code, compatibility dead-ends and i18n excitement.
Nice. The
header and the plugin code really looks a lot cleaner without
all the metadata embedded in it.
Agreed. I really like getting all that XML out of the C sources. Much
cleaner and more accessible. A minor suggestion: how about moving that
SYMBOL_EXPORT definition
into ladspa-2.h, presumably with a LADSPA_ prefix?
#ifdef WIN32
#define SYMBOL_EXPORT __declspec(dllexport)
#else
#define SYMBOL_EXPORT
#endif
Not a bad idea, I could go for that.
- Steve
3:30 p.m.
On Sat, Apr 22, 2006 at 12:19:42PM +0200, Lars Luthman wrote:
Extensions to the metadata, eg. port groups, new kinds of port (assuming
they can still be float *s), additional hints etc.
The clear route is the RDF namespacing mechanism, if someone wants to try
a new extension they can just start using it under thier own namespace,
then it can be added to the core spec if it's popular.
- Steve
Overall I
think this is a much better approach than LADSPA 1.x, it has
usable identifiers, a clear route for extensions without compatibility
problems and each plugin is quite a lot simpler.
What type of extensions are you talking about here, and what is the
clear route? 
9:44 a.m.
On Sat, 2006-04-22 at 10:53 +0100, Steve Harris wrote:
Almost two years ago at the LA conference a bunch of
us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
Great!
The .ttl file syntax looks really good.
I have a few suggestions, though:
- GUI support. A standardized, well defined way for plugins
to supply a graphical user interface of it's own.
- Port units should be defined in a way that plugin hosts know
what these units are. The label is not good enough for hosts.
Instead of:
ladspa:units "dB"
We could have:
ladspa:units#db
rdfs:label "dB"
(thanks for the syntax Steve. I hope I understood correctly)
If hosts understand which units are used it gives the them a possibility
to create better GUIs for the plugins. For example, if a parameter is in
dB, the host can provide a widget more suitable for gain entry.
But this would offer even greater benefits than widget selection: hosts
could give users the possibility to give time values relative to
beats/bars. (Without any need for the plugin to know about the tempo).
Think delays synchronized with the song tempo, for example.
The plugin could also give hints if a parameter should/could be given in
beats/bars or absolute time.
--
Sampo Savolainen <v2(a)iki.fi>
2:10 p.m.
On Sat, Apr 22, 2006 at 02:44:22PM +0300, Sampo Savolainen wrote:
Yes, it's nice to write, unlike RDF/XML, which is a PITA. There aren't as
many RDF librries tha can read it, but the majority (including raptor) can.
Anyway, I
finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
Great!
The .ttl file syntax looks really good. I have a few suggestions, though:
- GUI support. A standardized, well defined way for plugins
to supply a graphical user interface of it's own.
I would advocate the DSSI protocol, and placing the executable in the
bundle.
- Port units should be defined in a way that plugin
hosts know
what these units are. The label is not good enough for hosts.
Instead of:
ladspa:units "dB"
We could have:
ladspa:units#db
rdfs:label "dB"
(thanks for the syntax Steve. I hope I understood correctly)
I think you have, to be perfectly clear, I think you mean (in longhand):
In the plugin file
<some plugin> ladspa:unit units:db .
and then in the schema file:
units:db rdfs:label "dB" .
ie. label the plugins with a URI (symbol) and then annotate the symbol
with its name globally.
I thought about doing that in the example, but I though maybe the extra
level of indirection would put people off. It would let the hosts do more
intelligent things with control ports though, like you suggested.
- Steve
10:27 a.m.
On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote:
Almost two years ago at the LA conference a bunch of
us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
I'm not competent to comment on header files or implementation details.
But via Om, I'm a LADSPA power user and would like to bring up
some issues ;)
Distribution / finding plugins:
I would like to have an app, where I can put checkmarks to all plugins
and they will be fetched and installed (buidling from source / binaries
as option).
But just a way to get from the host not finding a plugin to the name
of the collection it's in would be nice already (so an app like Om can
not only say plugin-x not found, but also point to the package).
Stability:
There are some plugins that will die if fed with values out of their
range (and this happens easily in a modular system). Maybe some mechanism
to protect against this could be build into the framework?
Control/audio rate:
Having several variations of the same plugin to allow varying audio/
control rate port setups makes for unnecessary long plugin lists and
requires the user to delete and insert a different one, should he find
out some port should be audio, not control rate. Just look at the
sine oscillator(s) ...
The rate of a port should be switchable (at leat in all cases where
we have both versions now).
Port grouping:
Hosts should be able to see, wether 2 ports are independent, or happen
to be a stereo pair (or any multi-channel setup).
Also a way to specify that things like frequency and amount ports of
an EQ form pairs might be nice. Should be helpful for generative plugin
GUIs.
Port Roles:
Ports could have roles assigned to them, like signal_input, sidechain,
latency or bpm (the last for transport awareness and to make it possible
hosts assign values to it automaticaly).
Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Hints:
Maybe I just didn't see it, but shouldn't there be a hint for lists?
Like for plugins that have modes/presets?
Presets:
Cross-host preset loading/saving.
Help / Discription:
A way to bring up a short discription of a plugin and what the
ports are about.
MIDI/OSC
Don't know if the new LADSPAs should be able to handle MIDI/OSC,
but there should be plugins that do it ;)
GUI lib:
There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs,
for hosts not having to reinvent the wheel and for consistency.
---
Thorsten Wilms
10:48 a.m.
On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote:
Distribution / finding plugins:
Stability:
Control/audio rate:
Port grouping:
Port Roles:
Referencing:
Hints:
Presets:
Help / Discription:
MIDI/OSC
GUI lib:
To which I'd add:
Polyphony/Multiple channels:
Plugin instances should be able to discover that they are
part of a group sharing control parameters. In many cases
the calculation of internal parameters from user supplied
ones and their interpolation takes more CPU than the rest
of the code. That work should be performed once in poly
setups.
The new syntax lools a lot cleaner than the existing system,
to the point that I'd support it :-)
--
FA
Follie! Follie! Delirio vano e' questo!
11:01 a.m.
On Sat, 2006-04-22 at 14:56 +0200, fons adriaensen wrote:
On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten
Wilms wrote:
I'm not sure that all of this belongs in LADSPA (the Simple Plugin
Architecture). DSSI has support for presets, MIDI in, GUIs and some
support for polyphony (you can run several plugin instances as a
polyphony group with a single call to run_multiple() which lets you do
common calculations once).
About referencing: isn't the port index the common way to identify
LADSPA ports?
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
Distribution / finding plugins:
Stability:
Control/audio rate:
Port grouping:
Port Roles:
Referencing:
Hints:
Presets:
Help / Discription:
MIDI/OSC
GUI lib:
To which I'd add:
Polyphony/Multiple channels:
Plugin instances should be able to discover that they are
part of a group sharing control parameters. In many cases
the calculation of internal parameters from user supplied
ones and their interpolation takes more CPU than the rest
of the code. That work should be performed once in poly
setups.
11:14 a.m.
On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote:
I'm not sure that all of this belongs in LADSPA (the Simple Plugin
Architecture). DSSI has support for presets, MIDI in, GUIs and some
support for polyphony (you can run several plugin instances as a
polyphony group with a single call to run_multiple() which lets you do
common calculations once).
I was about generated GUIs, not plugin specific ones.
What's the reason that Om can treat DSSIs only as monophonic nodes
again?
About referencing: isn't the port index the common
way to identify
LADSPA ports?
Might be. A human readable, not to be translated english name per
port would be nice, though.
---
Thorsten Wilms
11:25 a.m.
On Sat, 2006-04-22 at 15:14 +0200, Thorsten Wilms wrote:
On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman
wrote:
I meant generated GUIs too - I've seen at least one generic (as in works
for any plugin) DSSI GUI somewhere, although I don't remember where at
the moment.
I'm not sure that all of this belongs in LADSPA (the Simple Plugin
Architecture). DSSI has support for presets, MIDI in, GUIs and some
support for polyphony (you can run several plugin instances as a
polyphony group with a single call to run_multiple() which lets you do
common calculations once).
I was about generated GUIs, not plugin specific ones. What's the reason that Om can treat DSSIs only as
monophonic nodes
again?
As far as I know there isn't a hard reason.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
2:37 p.m.
On Sat, 2006-04-22 at 15:14 +0200, Thorsten Wilms wrote:
On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman
wrote:
I'm not sure that all of this belongs in LADSPA (the Simple Plugin
Architecture). DSSI has support for presets, MIDI in, GUIs and some
support for polyphony (you can run several plugin instances as a
polyphony group with a single call to run_multiple() which lets you do
common calculations once).
I was about generated GUIs, not plugin specific ones.
What's the reason that Om can treat DSSIs only as monophonic nodes
again? From the host perspective, DSSI plugins /are/
monophonic. There is no
access to the individual voices, they're mixed down in
the plugin.
If LADSPA2 is to be polyphonic, it MUST not be like this. The host
needs access to individual voices.
-DR-
3:11 p.m.
On Sat, Apr 22, 2006 at 03:14:28PM +0200, Thorsten Wilms wrote:
I dont see enough value to justify making plugin authors come up with a
neutral string that will never be displayed to users.
- Steve
About
referencing: isn't the port index the common way to identify
LADSPA ports?
Might be. A human readable, not to be translated english name per
port would be nice, though.
11:16 a.m.
On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote:
...
support for polyphony (you can run several plugin instances as a
polyphony group with a single call to run_multiple() which lets you do
common calculations once).
That's not the point. Even in that case each plugin instance does
all the calculations, while they should be able to share some.
--
FA
Follie! Follie! Delirio vano e' questo!
2:33 p.m.
On Sat, Apr 22, 2006 at 02:56:35PM +0200, fons adriaensen wrote:
Polyphony/Multiple channels:
Plugin instances should be able to discover that they are
part of a group sharing control parameters. In many cases
the calculation of internal parameters from user supplied
ones and their interpolation takes more CPU than the rest
of the code. That work should be performed once in poly
setups.
Agreed. But I'd like to spec out a 2.0 that is no more capable than 1.1
first, then think about extensions seperatly. That sounds quite complex,
and I think its the sort of the DSSI addresses, as it has instancing and
polyphony control - at some level.
The new syntax lools a lot cleaner than the existing
system,
to the point that I'd support it :-)
Wow, praise indeed :)
- Steve
2:31 p.m.
On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote:
I'm not competent to comment on header files or
implementation details.
But via Om, I'm a LADSPA power user and would like to bring up
some issues ;)
*gulp* ;)
Distribution / finding plugins:
I would like to have an app, where I can put checkmarks to all plugins
and they will be fetched and installed (buidling from source / binaries
as option).
But just a way to get from the host not finding a plugin to the name
of the collection it's in would be nice already (so an app like Om can
not only say plugin-x not found, but also point to the package).
So... that is one thing that using RDF/web tech /can/ give you. eg. the
URI for the example plugin is http://plugin.org.uk/swh-plugins/amp/ if you
dereference that (ie. click on it ;) you will see some docs, but if you
use HTTP content negotiation and ask for it in Trutle you will get the RDF
description back, which /could/ have a machine readable bit telling you
where to get the package.
In combination with bundles that gives you the possibility to install
individual plugins.
It's a little bit sci-fi, but hopeful you can see that it's not too far
off.
Stability:
There are some plugins that will die if fed with values out of their
range (and this happens easily in a modular system). Maybe some mechanism
to protect against this could be build into the framework?
It would be 100% opposed to that. Plugins that crash when given odd values
are buggy (spec says they mustn't), and should be fixed. Use demolition,
report bugs.
Control/audio rate:
Having several variations of the same plugin to allow varying audio/
control rate port setups makes for unnecessary long plugin lists and
requires the user to delete and insert a different one, should he find
out some port should be audio, not control rate. Just look at the
sine oscillator(s) ...
The rate of a port should be switchable (at leat in all cases where
we have both versions now).
I might consider that for the future, but not for 2.0. I think its
important to get a more capable platform, before adding features.
Port grouping:
Hosts should be able to see, wether 2 ports are independent, or happen
to be a stereo pair (or any multi-channel setup).
Also a way to specify that things like frequency and amount ports of
an EQ form pairs might be nice. Should be helpful for generative plugin
GUIs.
This has been propsed using labels, eg "OSC 1/frequency" and "OSC
1/amplitude", that's an informal part of the spec IIRC. You could encode
it in RDF if you wanted to:
[ # port defintion
ladspa:index 1 ;
ladspa:label "frequency" ;
ladspa:inGroup <groupO1>
] , [
ladspa:index 1 ;
ladspa:label "frequency" ;
ladspa:inGroup <groupO1>
] .
<groupO1> ladspa:label "OSC 1" .
But I dint think it offers much more.
Port Roles:
Ports could have roles assigned to them, like signal_input, sidechain,
latency or bpm (the last for transport awareness and to make it possible
hosts assign values to it automaticaly).
Ugh. Maybe sometime in the future. That sounds hard to use. c.f. 2.0
plans.
Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far.
Hints:
Maybe I just didn't see it, but shouldn't there be a hint for lists?
Like for plugins that have modes/presets?
Yes, there is, but I didnt show it in that example as the simple amp
doesnt need it. It looks like:
# ... inside port defn
ladspa:scalePoint [
ladspa:label "sine" ;
ladspa:value 0.0 .
], [
ladspa:label "square" ;
ladspa:value 1.0 .
], [
ladspa:label "saw" ;
ladspa:value 2.0 .
]
Presets:
Cross-host preset loading/saving.
Right, there are some obvious ways to do it. Later.
Help / Discription:
A way to bring up a short discription of a plugin and what the
ports are about.
Just dereference the plugin URI as text/html or text/plain.
MIDI/OSC
Don't know if the new LADSPAs should be able to handle MIDI/OSC,
but there should be plugins that do it ;)
DSSI. If this gets momentum retorfitting LADSPA 2 to DSSI will be easy. It
was designed with that in mind.
GUI lib:
There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs,
for hosts not having to reinvent the wheel and for consistency.
Nope. Too hard, use the DSSI protocol.
- Steve
3:06 p.m.
On Sat, 2006-04-22 at 17:30 +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten
Wilms wrote:
I'm not going to suggest ID numbers go away, but I do think ports should
have a uniquely identifying string label. Primary reason being OSC
control, and using plugins in language bindings (ie python) - both
things that are getting much more prevalent now than when LADSPA first
arrived.
Noone wants to set the frequency of an oscillator with the OSC message
"/set oscillator/4 440" when they could "/set oscillator/freq 440".
Or
plugin.port(4).set_value(440) when it could be
plugin.port("frequency").set_value(440). Code (or OSC messages) using
plugin indexes as IDs is completely unreadable.
This is actually very important to me, I would very much like unique
port string ID's for the above reasons unless there's a good reason
there can't be.
-DR-
Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far.
3:25 p.m.
On Sat, Apr 22, 2006 at 01:06:26PM -0400, Dave Robillard wrote:
On Sat, 2006-04-22 at 17:30 +0100, Steve Harris
wrote:
OK, that's an argument I could buy. i'm still not completly convinced, but
it does make some sense.
On Sat, Apr 22, 2006 at 02:26:57PM +0200,
Thorsten Wilms wrote:
I'm not going to suggest ID numbers go away, but I do think ports should
have a uniquely identifying string label. Primary reason being OSC
control, and using plugins in language bindings (ie python) - both
things that are getting much more prevalent now than when LADSPA first
arrived. Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far. Noone wants to set the frequency of an oscillator with
the OSC message
"/set oscillator/4 440" when they could "/set oscillator/freq 440".
Or
plugin.port(4).set_value(440) when it could be
plugin.port("frequency").set_value(440). Code (or OSC messages) using
plugin indexes as IDs is completely unreadable.
This is actually very important to me, I would very much like unique
port string ID's for the above reasons unless there's a good reason
there can't be.
I guess you mean unique in plugin scope? It would also have to have some
restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some
kind of lowest common denominator between symbols for various languages
would make sense.
- Steve
3:47 p.m.
On Sat, 2006-04-22 at 18:25 +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 01:06:26PM -0400, Dave
Robillard wrote:
It's not useful from the perspective of writing a LADSPA host in C, but
I think the above two (actual real world) examples of where port ID's
are user exposed are justification enough.
On Sat, 2006-04-22 at 17:30 +0100, Steve Harris
wrote:
OK, that's an argument I could buy. i'm still not completly convinced, but
it does make some sense. On Sat, Apr 22, 2006 at 02:26:57PM +0200,
Thorsten Wilms wrote:
I'm not going to suggest ID numbers go away, but I do think ports should
have a uniquely identifying string label. Primary reason being OSC
control, and using plugins in language bindings (ie python) - both
things that are getting much more prevalent now than when LADSPA first
arrived. Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far. I guess you mean unique in plugin scope? It would also
have to have some
restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some
kind of lowest common denominator between symbols for various languages
would make sense.
Yeah, just unique to the plugin. (Though I guess that would imply the
port could have a URI like pluginuri/porturi but whatever).
I think the regexp you mentioned there is fine, though I think we should
add one separator character other than underscore for various reasons.
":" maybe?
As a side effect of this, what is now "label" should become
"description" and implicitly be Nice Human Readable Text, not
ugly_c_looking_identifiers (and units definitely need to be seperated).
"Description" is metadata though, so I guess it doesn't belong in the C
file.
-DR-
4:21 p.m.
On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave Robillard wrote:
You could do pluginUri#portShortName, it's a fairly common convention (eg.
in HTML). But youre only allowed a small set of characters after the #.
I guess you
mean unique in plugin scope? It would also have to have some
restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some
kind of lowest common denominator between symbols for various languages
would make sense.
Yeah, just unique to the plugin. (Though I guess that would imply the
port could have a URI like pluginuri/porturi but whatever). I think the regexp you mentioned there is fine, though
I think we should
add one separator character other than underscore for various reasons.
":" maybe?
I'd rather not, I'm not sure its legal in Pd (they get bitten by the port
name thing too), and its not in C. Pure selfinterest, but My LADSPA code
is about 50% generated from XML, and I use short names internally for C
symbols.
As a side effect of this, what is now
"label" should become
"description" and implicitly be Nice Human Readable Text, not
ugly_c_looking_identifiers (and units definitely need to be seperated).
"Description" is metadata though, so I guess it doesn't belong in the C
file.
The C now only contains the function pointers, a vector of float pointers
and a URI char *. All this stuff belongs outside.
- Steve
4:47 p.m.
On Sat, 2006-04-22 at 19:20 +0100, Steve Harris wrote:
I'm fully in support of putting any and all metadata outside the C file,
but the unique identifier isn't metadata, it should be in the code. A
trivial OSC controlled plugin host (which would make a good bundled
example client for the SDK) would need it.
-DR-
On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave
Robillard wrote:
You could do pluginUri#portShortName, it's a fairly common convention (eg.
in HTML). But youre only allowed a small set of characters after the #.
Well, at least one kind of separator character is required (for big
plugins). If it can't be ":", then I don't know what, but there needs
to be something. Maybe "."? If you want to keep it as a valid C
identifier I guess we're pretty much screwed, aside from defining __ to
be interpreted as a sort of heirarchialish separator.
master_amp:vol
master_amp.vol
master_amp__vol
"." is definitely prettiest... is there anything other than "__" we
can
use that's as safe?
I guess
you mean unique in plugin scope? It would also have to have some
restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some
kind of lowest common denominator between symbols for various languages
would make sense.
Yeah, just unique to the plugin. (Though I guess that would imply the
port could have a URI like pluginuri/porturi but whatever). I think the regexp you mentioned there is fine,
though I think we should
add one separator character other than underscore for various reasons.
":" maybe?
I'd rather not, I'm not sure its legal in Pd (they get bitten by the port
name thing too), and its not in C. Pure selfinterest, but My LADSPA code
is about 50% generated from XML, and I use short names internally for C
symbols. As a side
effect of this, what is now "label" should become
"description" and implicitly be Nice Human Readable Text, not
ugly_c_looking_identifiers (and units definitely need to be seperated).
"Description" is metadata though, so I guess it doesn't belong in the C
file.
The C now only contains the function pointers, a vector of float pointers
and a URI char *. All this stuff belongs outside.
6:10 p.m.
On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave Robillard wrote:
I'm missing the need for heirachicalness. : is probably not safe in OSC
either.
You could do
pluginUri#portShortName, it's a fairly common convention (eg.
in HTML). But youre only allowed a small set of characters after the #.
Well, at least one kind of separator character is required (for big
plugins). If it can't be ":", then I don't know what, but there needs
to be something. Maybe "."? If you want to keep it as a valid C
identifier I guess we're pretty much screwed, aside from defining __ to
be interpreted as a sort of heirarchialish separator. I think the regexp you mentioned there is fine,
though I think we should
add one separator character other than underscore for various reasons.
":" maybe?
I'd rather not, I'm not sure its legal in Pd (they get bitten by the port
name thing too), and its not in C. Pure selfinterest, but My LADSPA code
is about 50% generated from XML, and I use short names internally for C
symbols. I'm fully in support of putting any and all
metadata outside the C file,
but the unique identifier isn't metadata, it should be in the code. A
trivial OSC controlled plugin host (which would make a good bundled
example client for the SDK) would need it.
It's only /a/ unique identifier. We can't loose the index number as thats
the efficent way you access the LADSPA_Data pointers. Only one can be
canonical.
- Steve
6:48 p.m.
On Sat, 2006-04-22 at 21:10 +0100, Steve Harris wrote:
I think the above case of a trivial C host requiring it is justification
enough to have it in the code. Think about an engine/client split
system (where the engine might be something that doesn't have the
resources to load metadata and parse RDF etc, eg a DSP). The metadata
would be client-side, but the plugin engine-side, so the engine needs
access to the label in order to provide the nicer (eg) OSC namespace.
Not having it in the code makes a device like this impossible (think
Nord Modular or Plugzilla). That'd be a shame ;)
-DR-
On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave
Robillard wrote:
I'm missing the need for heirachicalness. : is probably not safe in OSC
either.
voice_1_osc_1_volume
voice_2_osc_3_volume
Or metaplugins (which ability to load libraries will surely spawn).
subplug_1_param1
subplug_2_param4
... ugh
voice_1.osc_1.volume
... oh so much nicer. There already exists a few DSSI plugins with
ports like this. Surely there's got to be /one/ more sensible character
we can add? (It needs to be valid as a jack port name as well)
You could
do pluginUri#portShortName, it's a fairly common convention (eg.
in HTML). But youre only allowed a small set of characters after the #.
Well, at least one kind of separator character is required (for big
plugins). If it can't be ":", then I don't know what, but there needs
to be something. Maybe "."? If you want to keep it as a valid C
identifier I guess we're pretty much screwed, aside from defining __ to
be interpreted as a sort of heirarchialish separator. I think the regexp you mentioned there is fine,
though I think we should
add one separator character other than underscore for various reasons.
":" maybe?
I'd rather not, I'm not sure its legal in Pd (they get bitten by the port
name thing too), and its not in C. Pure selfinterest, but My LADSPA code
is about 50% generated from XML, and I use short names internally for C
symbols. I'm fully
in support of putting any and all metadata outside the C file,
but the unique identifier isn't metadata, it should be in the code. A
trivial OSC controlled plugin host (which would make a good bundled
example client for the SDK) would need it.
It's only /a/ unique identifier. We can't loose the index number as thats
the efficent way you access the LADSPA_Data pointers. Only one can be
canonical. 
7:43 p.m.
It is good (tm) to define broad standards that encompass a variety of
situations. But usually broad means also thin, which results in it
being less helpful for each specific situation it pretends to be
applied to.
And no matter how broad you try to make it, I bet someone comes up
with a feature that is absolutely essential for his/her purposes that
the standard should cover but fails to.
How broad do we want it? Wouldn't it be a good idea to survey what
people are doing with LADSPA and what are they missing in it?
Personally, I don't need any more modular synths, thanks.
I miss the most in LADSPA:
- Sensible GUIs.
- Tempo awareness.
Cheers,
Luis
8:31 p.m.
On Sat, 2006-04-22 at 23:43 +0200, Luis Garrido wrote:
It is good (tm) to define broad standards that
encompass a variety of
situations. But usually broad means also thin, which results in it
being less helpful for each specific situation it pretends to be
applied to.
And no matter how broad you try to make it, I bet someone comes up
with a feature that is absolutely essential for his/her purposes that
the standard should cover but fails to.
How broad do we want it? Wouldn't it be a good idea to survey what
people are doing with LADSPA and what are they missing in it?
Personally, I don't need any more modular synths, thanks.
I'm going to assume this is a shot at me for rather obvious reasons.
Since you must know, my thoughts are mostly with Ardour, which will soon
be OSC controlled. You may have noticed that Ardour isn't a modular
synth. Fancy that.
I miss the most in LADSPA:
- Sensible GUIs.
*sigh* someone just had to do it, didn't they?
We don't need another inifinitely long GUI toolkit pissing match thread
that is guaranteed to lead absolutely nowhere, thanks.
LAD_S_PA2 is not going to have GUIs. http://dssi.sf.net. Enjoy.
Now can we please have a productive discussion about fixing very real
problems with LADSPA without /that/ *&%$% topic ruining everything, yet
again, thanks?
-DR-
9:10 p.m.
I'm going to assume this is a shot at me for
rather obvious reasons.
No, I was more thinking in Phil Frost's contribution to this
discussion (contribution that I find very interesting and pertinent,
but as a musician I am not interested in LADSPA becoming another low
level LEGO api to build modular synths, there are already some good
solutions to that problem).
*sigh* someone just had to do it, didn't they?
GUIs appeared in the thread long before my post.
LAD_S_PA2 is not going to have GUIs.
http://dssi.sf.net. Enjoy.
I am well aware of that. Thanks for the pointer, anyway.
http://flam.sf.net
But still there are some parts of LADSPA that have to provide
information for effective (auto)building of GUIs.
Now can we please have a productive discussion about
fixing very real
problems with LADSPA without /that/ *&%$% topic ruining everything, yet
again, thanks?
My apologies for bothering you. I will just return silently to my
playground and let the real men do the real stuff.
Peace,
Luis
9:35 p.m.
On Sun, 2006-04-23 at 01:10 +0200, Luis Garrido wrote:
My apologies then. I've become accustomed to knee-jerk anti modular
reactions whenever I use anything remotely modular as an example for
something. :)
Frankly I don't understand the phenomenon at all, your comments are a
perfect example. The source code idea would mostly be beneficial for
building stand-alone static (ie non modular) synths. The UI
for /creating/ them would be modular probably, since that's really the
only really reasonable UI for doing so, but it wouldn't /have/ to be.
Yet, you say the word "modular" and the idea is automatically cast aside
by everyone. You make the exact same point without saying the magic M
word, and my, what an interesting idea!
I Don't Get It(TM), but whatever. I suppose it's like math, non math
people see one Sigma and their brains just turn off immediately.
I just make sure not to say the magic M word wherever possible to avoid
it. ;)
[/digression]
I am of the opinion that auto generated UIs is not the way to go in
general, but regardless that's the beauty of external metadata. You can
experiment with whatever added data you like, if it works well people
will start using it and it might become part of the standard eventually.
LADSPA has long been hindered by the draconian pre-defined nature of C
ABIs. With rigorously seperated metadata we'll finally be able to
experiment with things like this without breaking things and LADSPA can
evolve...
-DR-
I'm going
to assume this is a shot at me for rather obvious reasons.
No, I was more thinking in Phil Frost's contribution to this
discussion (contribution that I find very interesting and pertinent,
but as a musician I am not interested in LADSPA becoming another low
level LEGO api to build modular synths, there are already some good
solutions to that problem). *sigh* someone
just had to do it, didn't they?
GUIs appeared in the thread long before my post.
LAD_S_PA2 is not going to have GUIs.
http://dssi.sf.net. Enjoy.
I am well aware of that. Thanks for the pointer, anyway.
http://flam.sf.net
But still there are some parts of LADSPA that have to provide
information for effective (auto)building of GUIs.
23 Apr
23 Apr
4:56 a.m.
On Sat, Apr 22, 2006 at 11:43:07 +0200, Luis Garrido wrote:
I miss the most in LADSPA:
- Sensible GUIs.
- Tempo awareness.
I should have been clear before, but I'm not interested in adding more
features to LADSPA, right now. I want to replace the cruft-filled C ABI
metadata system with something generic. Ideally I would like LADSPA 2.0 to
be exactly as capable as LADSPA 1.1. There are some things that need ABI
changes, but lets minime that.
Once LADSPA 2.0 has been finalised, extensions can be tried, and
eventaully added without changing 2.0.
- Steve
4:53 a.m.
On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote:
voice_1_osc_1_volume
voice_2_osc_3_volume
That looks fine to me...
I think the above case of a trivial C host requiring it is justification
enough to have it in the code. Think about an engine/client split
system (where the engine might be something that doesn't have the
resources to load metadata and parse RDF etc, eg a DSP). The metadata
would be client-side, but the plugin engine-side, so the engine needs
access to the label in order to provide the nicer (eg) OSC namespace.
It would use the index numbers. DSP chips and trivial C hosts are not going
to strcmp() to match ports up. You can't run a LADSPA2 plugin without some
part of the system being able to parse some data anyway, because you dont
know what the ports are for. It's OK, the host CPU can do it, and pass the
information to the DSP chip.
- Steve
Well, at least one kind of separator character is
required (for big
plugins). If it can't be ":", then I don't know what, but there needs
to be something. Maybe "."? If you want to keep it as a valid C
identifier I guess we're pretty much screwed, aside from defining __ to
be interpreted as a sort of heirarchialish separator.
I'm missing the need for heirachicalness. : is probably not safe in OSC
either. Or metaplugins (which ability to load libraries will
surely spawn).
subplug_1_param1
subplug_2_param4
... ugh
voice_1.osc_1.volume
Hum, that looks suspiciously like its expressing some semantics that don't
exist to me, and could potentially conflict with the port name (UI)
semantics "Osc 1/Frequency" etc.
... oh so much nicer. There already exists a few DSSI
plugins with
ports like this. Surely there's got to be /one/ more sensible character
we can add? (It needs to be valid as a jack port name as well)
But you're not talking about anything hard, its just a symbol name, used
to refer to the port, sometimes... I'm starting to go off this idea, noone
else has spoken in defense of it, and it raises some issues.
I'm fully in support of putting any and all
metadata outside the C file,
but the unique identifier isn't metadata, it should be in the code. A
trivial OSC controlled plugin host (which would make a good bundled
example client for the SDK) would need it.
It's only /a/ unique identifier. We can't loose the index number as thats
the efficent way you access the LADSPA_Data pointers. Only one can be
canonical.
1:17 p.m.
On Sun, 2006-04-23 at 07:53 +0100, Steve Harris wrote:
I think the above case of a trivial C host requiring it is justification
enough to have it in the code. Think about an engine/client split
system (where the engine might be something that doesn't have the
resources to load metadata and parse RDF etc, eg a DSP). The metadata
would be client-side, but the plugin engine-side, so the engine needs
access to the label in order to provide the nicer (eg) OSC namespace.
It would use the index numbers. DSP chips and trivial C hosts are not going
to strcmp() to match ports up. You can't run a LADSPA2 plugin without some
part of the system being able to parse some data anyway, because you dont
know what the ports are for. It's OK, the host CPU can do it, and pass the
information to the DSP chip.
It wouldn't use the index numbers if it wants to provide the sensible
OSC namespace (as for strcmp you can do the symbol thing w/ (perfect)
hashing to make it fast). Ditto for a language providing a sensible
API. The label is not metadata, it is a unique identifier.
But anyway, why can't it go in the code? I want to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.
If any LADSPA devs are opposed (or not) to giving each port a unique
label in the code, feel free weigh in...
-DR-
On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard
wrote:
voice_1_osc_1_volume
voice_2_osc_3_volume
That looks fine to me...
*shrug* All I want is one character that would be useful for organizing
port names in a much nicer looking fashion. I can live without if it's
really a big deal and there's no safe character, it'd just make for much
nicer looking port names on complicated plugins is all. Dropped.
Well, at least one kind of separator character is
required (for big
plugins). If it can't be ":", then I don't know what, but there needs
to be something. Maybe "."? If you want to keep it as a valid C
identifier I guess we're pretty much screwed, aside from defining __ to
be interpreted as a sort of heirarchialish separator.
I'm missing the need for heirachicalness. : is probably not safe in OSC
either. Or metaplugins (which ability to load libraries
will surely spawn).
subplug_1_param1
subplug_2_param4
... ugh
voice_1.osc_1.volume
Hum, that looks suspiciously like its expressing some semantics that don't
exist to me, and could potentially conflict with the port name (UI)
semantics "Osc 1/Frequency" etc.
... oh so much nicer. There already exists a few
DSSI plugins with
ports like this. Surely there's got to be /one/ more sensible character
we can add? (It needs to be valid as a jack port name as well)
But you're not talking about anything hard, its just a symbol name, used
to refer to the port, sometimes... I'm starting to go off this idea, noone
else has spoken in defense of it, and it raises some issues. I'm fully
in support of putting any and all metadata outside the C file,
but the unique identifier isn't metadata, it should be in the code. A
trivial OSC controlled plugin host (which would make a good bundled
example client for the SDK) would need it.
It's only /a/ unique identifier. We can't loose the index number as thats
the efficent way you access the LADSPA_Data pointers. Only one can be
canonical.
4:23 p.m.
On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote:
But anyway, why can't it go in the code? I want
to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from.
- Steve
4:32 p.m.
On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote:
On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave
Robillard wrote:
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added.
Are you proposing to put the port index numbers in the metadata as well?
Otherwise you couldn't get at them without loading and linking the
plugin.
So the plugin URI should exclusively go in the metadata file as well?
Why is that in the code?
-DR-
But anyway, why can't it go in the code? I
want to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from.
4:40 p.m.
On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote:
On Sun, 2006-04-23 at 19:23 +0100, Steve Harris
wrote:
I don't see how it affects the usecase. You /always/ need to read at least
some of the data somehwere to use the plugin.
On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave
Robillard wrote:
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added.
But anyway, why can't it go in the code? I
want to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from. Are you proposing to put the port index numbers in the
metadata as well?
Otherwise you couldn't get at them without loading and linking the
plugin.
Of course, it's ladspa:index if the numbers aren't there then theres
nothing to link the port data to the float *.
So the plugin URI should exclusively go in the
metadata file as well?
Why is that in the code?
It has to be in the struct, otherwise you don't know what functions to
call to get a particular plugin.
- Steve
5:02 p.m.
On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote:
In other words it's there because it's a unique identifier for the
plugin, used to reference it. I say port IDs need to be there for the
same reason. Ports should be first class citizens with a proper
identifier and all, IMO.
Anyway, putting IDs in the metadata implies that, well, they're
metadata, and can be fiddled with without breaking things. This is not
true. They are unique identifiers (along with their plugin's URIs they
define a URI) and as such are set in stone and must not change. They're
just not metadata.
But I want to emphasize the 'device' (or trivial host app, etc) over
arguments about word definitions etc. I really don't want to have to
fork LADSPA into an ABI incompatible derivative over something silly
like this.
-DR-
On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave
Robillard wrote:
Well, the plugin should be at least runnable without the metadata. Sure
you'll know almost nothing about it, but you should be able to run it
(eg in fixed code where you know the parameters and whatnot you're using
are fine). (No user interacting app could feasibly do so though)
The "somewhere" part is my point. This 'device' can not read metadata
files, yet it needs to know the port IDs. Therefore the port IDs need
to be in the code.
On Sun, 2006-04-23 at 19:23 +0100, Steve Harris
wrote:
I don't see how it affects the usecase. You /always/ need to read at least
some of the data somehwere to use the plugin. On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave
Robillard wrote:
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added. But anyway, why can't it go in the code? I
want to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from. Are you
proposing to put the port index numbers in the metadata as well?
Otherwise you couldn't get at them without loading and linking the
plugin.
Of course, it's ladspa:index if the numbers aren't there then theres
nothing to link the port data to the float *.
So the plugin URI should exclusively go in the
metadata file as well?
Why is that in the code?
It has to be in the struct, otherwise you don't know what functions to
call to get a particular plugin.
7:37 p.m.
On Sun, Apr 23, 2006 at 04:26:03 -0400, Dave Robillard wrote:
Well, the plugin should be at least runnable without the metadata. Sure
you'll know almost nothing about it, but you should be able to run it
(eg in fixed code where you know the parameters and whatnot you're using
are fine). (No user interacting app could feasibly do so though)
Sure, but that doesn't require you to be able to load the shortnames from
the plugin binary.
They are, they have integers. The integers map to something very real in
the plugin structure. Shortnames are just shortnames, you can't map them
to ports unless they appear in the external data or you load and link the
plugin.
The advantage is the mentioned use case which your
suggestion destroys.
The array can be static anyway, there's not really any "code" added.
I don't see how it affects the usecase. You /always/ need to read at least
some of the data somehwere to use the plugin. The "somewhere" part is my point. This
'device' can not read metadata
files, yet it needs to know the port IDs. Therefore the port IDs need
to be in the code.
It can't speak OSC either, so the integers are just fine.
It has to be
in the struct, otherwise you don't know what functions to
call to get a particular plugin.
In other words it's there because it's a unique identifier for the
plugin, used to reference it. I say port IDs need to be there for the
same reason. Ports should be first class citizens with a proper
identifier and all, IMO. Anyway, putting IDs in the metadata implies that,
well, they're
metadata, and can be fiddled with without breaking things. This is not
true. They are unique identifiers (along with their plugin's URIs they
define a URI) and as such are set in stone and must not change. They're
just not metadata.
Please dont use the word metadata, it's confusing, what's meta depends on
your context. Not all the data can be fiddled with without breaking
things. If you change the URI all your presets will stop working, if you
change the port indexes then the structure of the plugin changes, etc.
- Steve
8:41 p.m.
On Sun, 2006-04-23 at 16:26 -0400, Dave Robillard wrote:
On Sun, 2006-04-23 at 19:39 +0100, Steve Harris
wrote:
In other words it's there because it's a unique identifier for the
plugin, used to reference it. I say port IDs need to be there for the
same reason. Ports should be first class citizens with a proper
identifier and all, IMO.
Anyway, putting IDs in the metadata implies that, well, they're
metadata, and can be fiddled with without breaking things. This is not
true. They are unique identifiers (along with their plugin's URIs they
define a URI) and as such are set in stone and must not change. They're
just not metadata.
But I want to emphasize the 'device' (or trivial host app, etc) over
arguments about word definitions etc. I really don't want to have to
fork LADSPA into an ABI incompatible derivative over something silly
like this.
For the sake of the record, it's been duked out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
The RDF file is required to run the plugin anyway, since port type and
direction etc. is contained there, making my argument about keeping the
data file parsing off the 'server side' invalid.
The data file is not a "metadata" file, it's required to execute the
plugin at all (and I fully agree with this now, even if it does throw a
bit of a monkey wrench in some embedded development plans of mine; it's
for the greater good....)
-DR-
On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave
Robillard wrote:
Well, the plugin should be at least runnable without the metadata. Sure
you'll know almost nothing about it, but you should be able to run it
(eg in fixed code where you know the parameters and whatnot you're using
are fine). (No user interacting app could feasibly do so though)
The "somewhere" part is my point. This 'device' can not read metadata
files, yet it needs to know the port IDs. Therefore the port IDs need
to be in the code.
On Sun, 2006-04-23 at 19:23 +0100, Steve Harris
wrote:
I don't see how it affects the usecase. You /always/ need to read at least
some of the data somehwere to use the plugin. On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave
Robillard wrote:
> But anyway, why can't it go in the code? I want to keep the C part
> minimal as well, but this is a unique identifier, the sole thing that
> actually does belong in the code. I need this to create an app/device
> like the above. What's the better reason it's a bad idea? Plugins have
> a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from.
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added. Are you
proposing to put the port index numbers in the metadata as well?
Otherwise you couldn't get at them without loading and linking the
plugin.
Of course, it's ladspa:index if the numbers aren't there then theres
nothing to link the port data to the float *.
So the plugin URI should exclusively go in the
metadata file as well?
Why is that in the code?
It has to be in the struct, otherwise you don't know what functions to
call to get a particular plugin.
24 Apr
24 Apr
5:59 a.m.
On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote:
For the sake of the record, it's been duked out on
IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
Actually I didn't mean to say that they /will/ be required, just that I
don't have a problem with it. I've not heard anyone else speak in favour
of this, and it is a feature. If theres a critical mass of support I'm OK
with adding it, as it should make the lives of some hosts much easier.
At the risk of upsetting Dave, it can be added a a 3rd party extension
without anything really bad happening. It just means that the Pd messages
/ OSC paths / whatever for some plugins will be ugly. "Market pressure"
will ensire that all plugins support it if its useful to enough users.
- Steve
10:59 a.m.
On Mon, 2006-04-24 at 08:57 +0100, Steve Harris wrote:
On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard
wrote:
Not so much a new feature as a clearer definition of existing things
(port labels).
It's a "feature" perhaps, but just something that needs to be defined in
the data file. The features we need to avoid here are ones that mess
with the code IMO. There are a few new bits of data that experience has
shown we need to add to the data file (not mandatory like this one, just
possible keys). Given how easy and un-breakey it is to do so (which is
the entire point of doing this after all), we should take advantage.
Anyway, at this point that's not very important, just definition of
possible keys in the data file. We can discuss those once we're sure
the code side of things (and existing data bits) is sound.
-DR-
For the sake of the record, it's been duked
out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
Actually I didn't mean to say that they /will/ be required, just that I
don't have a problem with it. I've not heard anyone else speak in favour
of this, and it is a feature. If theres a critical mass of support I'm OK
with adding it, as it should make the lives of some hosts much easier.
At the risk of upsetting Dave, it can be added a a 3rd party extension
without anything really bad happening. It just means that the Pd messages
/ OSC paths / whatever for some plugins will be ugly. "Market pressure"
will ensire that all plugins support it if its useful to enough users.
12:54 p.m.
On Mon, Apr 24, 2006 at 08:58:07 -0400, Dave Robillard wrote:
Yep. Seems reasonable.
- Steve
At the risk of
upsetting Dave, it can be added a a 3rd party extension
without anything really bad happening. It just means that the Pd messages
/ OSC paths / whatever for some plugins will be ugly. "Market pressure"
will ensire that all plugins support it if its useful to enough users.
Anyway, at this point that's not very important, just definition of
possible keys in the data file. We can discuss those once we're sure
the code side of things (and existing data bits) is sound. 
2:22 p.m.
I've been following the LAD mailing list for a while now,
mostly to keep an eye the development of LADSPA.
Now seems an appropriate time to voice my thoughts.
Separating out the metadata is certainly (IMHO) the right thing to do,
(I think Steve's proposal is a great step forward)
It mitigates the problem of making LADSPA easily extensible by moving
as much information as possible out of the fixed binary format.
However the problem remains that the core API still cannot be
extended without breaking backwards compatibility.
Surely with LADSPA 2.0 it's time to change the struct based API
to a library call based API.
# ie. the currently proposed API looks like...
ladspa_descriptor(index)
descriptor {
uri
port_count
implementation_data
instantiate(descriptor, ...)
connect_port(instance, ...)
activate(instance)
run(instance, ...)
deactivate(instance)
cleanup(instance)
}
# a function call based API would look like...
ladspa2_descriptor(index)
uri(descriptor)
port_count(descriptor)
instantiate(descriptor, ...)
connect_port(instance, ...)
activate(instance)
run(instance, ...)
deactivate(instance)
cleanup(instance)
In the former, any change in the descriptor structure will always break
backwards compatibility.
In the later, new functions can extend the core functionality without
breaking backwards compatibility in any way.
I'd be very interested in hearing people's opinions on this.
Regards,
Tom
6:12 p.m.
On 4/24/06, tom christie <christie.tom(a)gmail.com> wrote:
In the former, any change in the descriptor structure
will always break
backwards compatibility.
In the later, new functions can extend the core functionality without
breaking backwards compatibility in any way.
Actually, just adding a large-ish chunk of reserved padding at the end
of the descriptor struct can accomplish the same goal, as long as you
are only adding new functions to the API. That, along with a version
field also in the struct.
jlc
25 Apr
25 Apr
6:47 a.m.
On Mon, Apr 24, 2006 at 04:12:11 -0400, Jesse Chappell wrote:
On 4/24/06, tom christie
<christie.tom(a)gmail.com> wrote:
The pluin is responsibe for allocating the descriptor, so its not
neccesary to add padding.
- Steve
In the former, any change in the descriptor
structure will always break
backwards compatibility.
In the later, new functions can extend the core functionality without
breaking backwards compatibility in any way.
Actually, just adding a large-ish chunk of reserved padding at the end
of the descriptor struct can accomplish the same goal, as long as you
are only adding new functions to the API. That, along with a version
field also in the struct.
8:28 a.m.
Okay, I ought to have qualified my 'will always break...' that's
clearly not true.
But there is still real inflexibility in using a struct based API.
eg. Say a developer comes up with a nice extension (perhaps to allow a
plugin to deal with multi-channel IO / non-causal audio effects /
alter the audio frequency / support an 'end of stream' marker / midi /
GUI / accessing metadata via function calls / or whatever...)
With the struct based API the only way(*) for that extension to make
it into LADSPA is for it to be part of the the struct in the next
version of LADSPA. We want to keep LADSPA simple, so that's unlikely
to happen.
With the library call based API the developer defines and advertises
the functions that make up the extension, and if it is useful hosts
will start to implement it. If it proves it's worth it can be adopted
as an official LADSPA *extension*, which hosts can choose (or not) to
implement.
The core API remains simple and unbloated, but LADSPA can still develop.
(*) Yes there is trickery that could be played with, eg. using
multiple discovery functions, but that's just icky.
9:59 a.m.
Sorry, I just dont feel that motivated by this. We have a bunch of code
and experience around the struct format, and we know were going to need
something equivalent for the forseeable future, so I dont see the point in
changing it over just for the sake of it.
Sure, for some possible future ABI-incomaptible extension we might want to
add functions, but equally we might not.
- Steve
On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote:
Okay, I ought to have qualified my 'will always
break...' that's
clearly not true.
But there is still real inflexibility in using a struct based API.
eg. Say a developer comes up with a nice extension (perhaps to allow a
plugin to deal with multi-channel IO / non-causal audio effects /
alter the audio frequency / support an 'end of stream' marker / midi /
GUI / accessing metadata via function calls / or whatever...)
With the struct based API the only way(*) for that extension to make
it into LADSPA is for it to be part of the the struct in the next
version of LADSPA. We want to keep LADSPA simple, so that's unlikely
to happen.
With the library call based API the developer defines and advertises
the functions that make up the extension, and if it is useful hosts
will start to implement it. If it proves it's worth it can be adopted
as an official LADSPA *extension*, which hosts can choose (or not) to
implement.
The core API remains simple and unbloated, but LADSPA can still develop.
(*) Yes there is trickery that could be played with, eg. using
multiple discovery functions, but that's just icky.
2:41 p.m.
Sorry, I just dont feel that motivated by this.
No problem :) just wanted to know if anyone else thought it was an
important point.
Two other concerns...
A) There is no built-in way of a host distinguishing between a LADSPA
1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?)
Would it make sense to change the name of the discovery function?
eg... ladspa2_descriptor() instead of ladspa_descriptor()
That way there's no chance of a 2.0 host thinking it has a 2.0 plugin
when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host)
Either case would cause the host to crash when it calls the
instantiate() function.
B) There is no way of a host distinguishing between a LADSPA 2.x and a
LADSPA 2.y plugin.
Would it make sense for the initial few bytes of the struct to
explicitly declare that this really is a LADSPA struct and give the
major and minor versions for which it was written? This would allow
the struct to change in the future if neccessary without breaking
things and without needing to change the name of the discovery
function again.
char ladspa_string[7]; // plugin must set this to "LADSPA\0"
unsigned short major_version; // plugin must set this to 2
unsigned short minor_version; // plugin must set this to 0
The host should check for the null terminated "LADSPA" string, and
should ensure that it's version is less than or equal that which the
host supports before attempting to access the plugin.
thoughts?...
On 4/25/06, Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Sorry, I just dont feel that motivated by this. We
have a bunch of code
and experience around the struct format, and we know were going to need
something equivalent for the forseeable future, so I dont see the point in
changing it over just for the sake of it.
Sure, for some possible future ABI-incomaptible extension we might want to
add functions, but equally we might not.
- Steve
On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote:
Okay, I ought to have qualified my 'will
always break...' that's
clearly not true.
But there is still real inflexibility in using a struct based API.
eg. Say a developer comes up with a nice extension (perhaps to allow a
plugin to deal with multi-channel IO / non-causal audio effects /
alter the audio frequency / support an 'end of stream' marker / midi /
GUI / accessing metadata via function calls / or whatever...)
With the struct based API the only way(*) for that extension to make
it into LADSPA is for it to be part of the the struct in the next
version of LADSPA. We want to keep LADSPA simple, so that's unlikely
to happen.
With the library call based API the developer defines and advertises
the functions that make up the extension, and if it is useful hosts
will start to implement it. If it proves it's worth it can be adopted
as an official LADSPA *extension*, which hosts can choose (or not) to
implement.
The core API remains simple and unbloated, but LADSPA can still develop.
(*) Yes there is trickery that could be played with, eg. using
multiple discovery functions, but that's just icky.
2:58 p.m.
On Tue, 2006-04-25 at 17:40 +0100, tom christie wrote:
A) There is no built-in way of a host distinguishing
between a LADSPA
1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?)
Would it make sense to change the name of the discovery function?
eg... ladspa2_descriptor() instead of ladspa_descriptor()
That makes sense to me. You could of course say that all LADSPA2
plugins/bundles/directories should be stored in different directories
from LADSPA1 (e.g. /usr/lib/ladspa2 instead of /usr/lib/ladspa) but
since the user is free to set $LADSPA_PATH to whatever he wants and
hosts are free to search whatever directories they want that wouldn't be
a very stable solution. Having a separate discovery function is a good
idea.
B) There is no way of a host distinguishing between a
LADSPA 2.x and a
LADSPA 2.y plugin.
Would it make sense for the initial few bytes of the struct to
explicitly declare that this really is a LADSPA struct and give the
major and minor versions for which it was written? This would allow
the struct to change in the future if neccessary without breaking
things and without needing to change the name of the discovery
function again.
char ladspa_string[7]; // plugin must set this to "LADSPA\0"
unsigned short major_version; // plugin must set this to 2
unsigned short minor_version; // plugin must set this to 0
I don't think that the string is needed - if the host got the descriptor
from a ladspa2_descriptor() discovery function, that should be enough to
be sure that it is a LADSPA2 descriptor. A version number might be good
though - even if the goal is to add extensions without breaking the ABI
it could still be necessary to break it at some point in the future. One
version number should be enough though, and it doesn't have to match the
actual version of the LADSPA spec. Like the DSSI_API_Version in the DSSI
descriptor.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
7:37 p.m.
On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote:
I was imagining they would be in a different path, and as they will be in
.ladspa2 directories, and the .so files are discoverable via the RDF
manifest, theres no real reason why you would find one and not be sure
what version it was, however...
Sorry, I just
dont feel that motivated by this.
No problem :) just wanted to know if anyone else
thought it was an
important point.
Two other concerns...
A) There is no built-in way of a host distinguishing between a LADSPA
1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) Would it make sense to change the name of the
discovery function?
eg... ladspa2_descriptor() instead of ladspa_descriptor()
That way there's no chance of a 2.0 host thinking it has a 2.0 plugin
when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host)
Either case would cause the host to crash when it calls the
instantiate() function.
Right, I can't see any reason not to do this.
B) There is no way of a host distinguishing between a
LADSPA 2.x and a
LADSPA 2.y plugin.
Would it make sense for the initial few bytes of the struct to
explicitly declare that this really is a LADSPA struct and give the
major and minor versions for which it was written? This would allow
the struct to change in the future if neccessary without breaking
things and without needing to change the name of the discovery
function again.
char ladspa_string[7]; // plugin must set this to "LADSPA\0"
unsigned short major_version; // plugin must set this to 2
unsigned short minor_version; // plugin must set this to 0
I made a version of the .h that does this (the version thing, not the
header), but I couldn't think if any cases where it was useful - if it
gets as far as the time you fetch the descriptor from the .so before you
find out what the version is thats problaby a mistake. You should be
able to reject descriptors you cant handle before that stage, otherwise it
will annoy users. user: "I want that one", host: "oh, sorry, I dont
understand it"
One of my aims for LADSPA 2 is to remove the need to dlload the plugin
(expensive in CPU+memory, potentially dangerous) until you need to pass
data through it.
- Steve
26 Apr
26 Apr
6:48 a.m.
don't think that the string is needed
I think that's fair.
One version number should be enough though,
and it doesn't have to match the actual version of the LADSPA spec
Both those points (especially the second) sound simple and sensible.
Okay, so on reflection...
There's a case to be made that some version information ought to go
into the struct, since it directly affects how the struct may be
properly accessed.
There are two case where you would need version information
to correctly access the struct.
1) A future version extends the struct. (does not break backwards compatibility)
version information is needed so that eg. a 2.1 host does not try to
use 2.1 functionality in a 2.0 plugin.
2) A future version modifies the struct. (breaking backwards compatibility)
case 2) is very unlikely to occur anytime soon, so let's just forget about that
(it can be solved by using a new discovery function anyhow)
case 1) could most simply be addressed like this:
The struct starts with a single unsigned short.
The host must check the version number at the start...
If the plugin version >= host version:
No problem - the host knows it's functionality is fully supported.
If the plugin version < host version:
The host may access the plugin normally and is aware of what
functionality the plugin does not support.
Why is this useful?
Well, it provides a _built-in_ way of ensuring that the struct is
properly accessed,
even if the metadata file is corrupted or lost.
Say a user meddles with the metadata file to make a 2.0 plugin look
like a 2.1 plugin. The host attempts to access 2.1 functionality and
core dumps.
Say the metadata file has been lost - the plugin contains sufficient
information to remain accessible although it no longer has any
associated metadata.
I realise that the LADSPA library should mostly enforce keeping things
okay, but it seems like a nice idea to have a protected way of making
sure that we don't accidentally attempt to access invalid memory when
things go wrong.
I would suggest then: A single unsigned short at the start of the
struct, starting at '0' for ladspa 2.0 plugins and incrementing if and
when the struct is extended.
The LADSPA major and minor versions would stay in the metadata.
Any milege in this?...
7:39 a.m.
On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie wrote:
...
Well, it provides a _built-in_ way of ensuring that
the struct is
properly accessed,
even if the metadata file is corrupted or lost.
Say a user meddles with the metadata file to make a 2.0 plugin look
like a 2.1 plugin. The host attempts to access 2.1 functionality and
core dumps.
Say the metadata file has been lost - the plugin contains sufficient
information to remain accessible although it no longer has any
associated metadata.
It's not metadata. If the data is corrupt or missing then youre SOL. It's
just as vital as the arrays of structs were in LADSPA 1; if you dont have
the data theres no way to use the plugin without causing segfaults.
This is why the "plugin" is really a directory, all the stuff in there is
neccesary.
- Steve
9:54 a.m.
It's really just an extra layer of protection...
I realise that the binary and data files will be accessed as a single unit,
but a corrupt data file should never cause a segfault.
Without a built-in struct version identifier the host (or LADSPA library)
may segfault by incorrectly accessing the struct. (if the data file is corrupt)
With a built-in struct version identifier the host (or LADSPA library)
can ensure it will never access the struct in a way which will cause a segfault.
(even if the data file is corrupt.)
Okay, I'll hold my peace now ;)
On 4/26/06, Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie
wrote:
...
Well, it provides a _built-in_ way of ensuring
that the struct is
properly accessed,
even if the metadata file is corrupted or lost.
Say a user meddles with the metadata file to make a 2.0 plugin look
like a 2.1 plugin. The host attempts to access 2.1 functionality and
core dumps.
Say the metadata file has been lost - the plugin contains sufficient
information to remain accessible although it no longer has any
associated metadata.
It's not metadata. If the data is corrupt or missing then youre SOL. It's
just as vital as the arrays of structs were in LADSPA 1; if you dont have
the data theres no way to use the plugin without causing segfaults.
This is why the "plugin" is really a directory, all the stuff in there is
neccesary.
- Steve
12:56 p.m.
On Wed, Apr 26, 2006 at 12:54:43PM +0100, tom christie wrote:
It's really just an extra layer of protection...
I realise that the binary and data files will be accessed as a single unit,
but a corrupt data file should never cause a segfault.
That's somewhat like saying a corrupt binary should never cause a
segfault... if the data file gets corrupted in a way that breaks the
syntax, then there wont be enouhg data for hte host to attempt to load the
plugin and it will refuse, but if through some miracle
ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of
crazy shit will go down.
Without a built-in struct version identifier the host
(or LADSPA library)
may segfault by incorrectly accessing the struct. (if the data file is corrupt)
I'm not interested in the case the data file is corrupt, its too much of a
special case, and theres nothing sensible you can do about it.
No-ones seriously interested in guarding against the caes where the .so is
corrupt. If you care that much, ship a sha1 checksum with your plugin.
With a built-in struct version identifier the host (or
LADSPA library)
can ensure it will never access the struct in a way which will cause a segfault.
(even if the data file is corrupt.)
No it can't :) If the data file is currupt in any plausible way the host wont
have enough information to even attept to open the plugin anyway.
- Steve
2:48 p.m.
That's somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail to be able
to load it, or to load it and produce unexpected output, but it should
*never* cause it to segfault.
No-ones seriously interested in guarding against the
caes
where the .so is corrupt.
Agreed, and neither am I.
All I'm saying is that if the discovery function may potentially
return differing structs from one LADSPA version to another, then it
ought also provide a mechanism of determining exactly which struct it
is returning.
If it does that, then the worst that can ever happen is that the
binary is accessed with duff input (no segfaulting).
Okay, I really will shut it now, I begin to suspect I'm labouring the point :)
t.
2:55 p.m.
On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote:
the only situation it can cause a segfault is where its mangled in a
somehow still structurally and syntaxically correct way (too unlikly to be
worth considering) or if the host pushes on without enough information.
The point I was making is that you will get segfaults if you try to us the
struct without the data, even if you know the version number, so dont.
That's
somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail to be able
to load it, or to load it and produce unexpected output, but it should
*never* cause it to segfault. All I'm saying is that if the discovery function
may potentially
return differing structs from one LADSPA version to another, then it
ought also provide a mechanism of determining exactly which struct it
is returning.
Sure, but its easier to version the struct in the data.
- Steve
3:13 p.m.
On Wed, 2006-04-26 at 17:55 +0100, Steve Harris wrote:
On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie
wrote:
the only situation it can cause a segfault is where its mangled in a
somehow still structurally and syntaxically correct way (too unlikly to be
worth considering) or if the host pushes on without enough information.
The point I was making is that you will get segfaults if you try to us the
struct without the data, even if you know the version number, so dont.
Thinking about this I was worried about parallel installed multiple
versions of the same plugin, but as long as the URI refers to a
compatible version of the plugin, we don't need versioning in the struct
itself, since the URI between two versions of a plugin (one of which is
LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever)
must change since it's incompatible, right?
We need to make absolutely sure multiple versions of a plugin can be
installed at once, including new incompatible versions of the spec, is
my point. I /think/ it's okay as stands though.
-DR-
That's somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail to be able
to load it, or to load it and produce unexpected output, but it should
*never* cause it to segfault. All I'm saying is that if the discovery
function may potentially
return differing structs from one LADSPA version to another, then it
ought also provide a mechanism of determining exactly which struct it
is returning.
Sure, but its easier to version the struct in the data.
4:30 p.m.
On Wed, Apr 26, 2006 at 01:14:06PM -0400, Dave Robillard wrote:
Thinking about this I was worried about parallel
installed multiple
versions of the same plugin, but as long as the URI refers to a
compatible version of the plugin, we don't need versioning in the struct
itself, since the URI between two versions of a plugin (one of which is
LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever)
must change since it's incompatible, right?
Yes, the URI changes whenever the effective ABI changes, ie add, remove or
change semantics of ports, or new struct ABI.
We need to make absolutely sure multiple versions of a
plugin can be
installed at once, including new incompatible versions of the spec, is
my point. I /think/ it's okay as stands though.
Yes, you just need to make sure the URIs and and bundle names change as
appropriate.
- Steve
4:04 p.m.
On Wed, 2006-04-26 at 15:56 +0100, Steve Harris wrote:
That's somewhat like saying a corrupt binary
should never cause a
segfault... if the data file gets corrupted in a way that breaks the
syntax, then there wont be enouhg data for hte host to attempt to load the
plugin and it will refuse, but if through some miracle
ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of
crazy shit will go down.
segfaults will only be ok as long as there are no security advisories.
beware the rdf exploits. :)
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
1:18 p.m.
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote:
This is why the "plugin" is really a
directory, all the stuff in there is
neccesary.
On the plugin bundle thing, I've got working C code that takes a path to
the directory, parses manifest.ttl, gleams the available plugin DLLs and
data files from that, and enumerates all the plugins in the DLL.
We need to clarify some things about bundles themselves:
- What is the significance of the bundle name itself? (We need to avoid
clashes somehow)
- Do they contain one plugin variant, or any number?
- One DLL or many?
- What's the relation between the two above points?
I'm not sure about number-of-plugins-per-bundle (though putting all of,
say, swh-plugins in one bundle seems counter to the intent to me?) but I
will suggest we reccommend that one DLL contains only variants of one
plugin (or a group of very similar plugins). Reasoning is to avoid
things like cmt.so which has a huge number of completely unrelated
plugins in one lib, meaning a host has to link in all that crap just to
use a simple amplifier plugin, which is no good.
-DR-
4:06 p.m.
On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote:
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris
wrote:
It shouldn't be neccesary to actually dlload() the .so file, if it is then
theres a mistake somewhere.
This is why the "plugin" is really a
directory, all the stuff in there is
neccesary.
On the plugin bundle thing, I've got working C code that takes a path to
the directory, parses manifest.ttl, gleams the available plugin DLLs and
data files from that, and enumerates all the plugins in the DLL. We need to clarify some things about bundles
themselves:
- What is the significance of the bundle name itself? (We need to avoid
clashes somehow)
Yes, its a bit awkward. It would be nice to be able to use URIs, but thats
not going to wash.
I was planning something like
[abbreviated plugin name]-[collection name].whatever/
eg. Amp-swh.ladspa2
Assuming the number of collections doesnt grow to much, the current thing
of people using thier initials or similar should work fine. The maintainer
of each colleaction is responsible for making sure noone else uses the
same collection name, and that none of thier abbreviated names collide.
If we wanted to go overboard we could do something like
[abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/
eg. amp-5491370f050fa849.ladspa2/
which guarantees uniqueness, but its a bit of a pain, and the plugin bundle
names will be a bit ugly.
- Do they contain one plugin variant, or any number?
Probably leave it as a matter of taste. Though discouraging the cmt thing
is a good idea IMHO.
- One DLL or many?
As many as you want / need.
I'm not sure about number-of-plugins-per-bundle
(though putting all of,
say, swh-plugins in one bundle seems counter to the intent to me?) but I
will suggest we reccommend that one DLL contains only variants of one
plugin (or a group of very similar plugins). Reasoning is to avoid
things like cmt.so which has a huge number of completely unrelated
plugins in one lib, meaning a host has to link in all that crap just to
use a simple amplifier plugin, which is no good.
My intention was to have a pretty much 1:1 correspondance between .so's I
have now and bundles in the future. ie. most plugins are on thier own, but
logically grouped ones are in one .so. eg. a buch ov very similar
oscialltors, filters etc.
I dont think its neccesary to specify this though, the best natural level
usually settles out. ie. people see cmt.so, and go "arrrghhh!".
- Steve
4:53 p.m.
On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote:
That is overboard, but I guess there's no real good solution to this
that doesn't involve having a URI of some variety as the name, which is
far too ugly.
We do need to prevent people from doing stupid things like calling the
directory "amp" though, so at least a recommendation in the spec is in
order.
The way your plugins are divvied up is fine, but:
On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave
Robillard wrote:
Sorry, to be clearer loading the DLL was my goal (not the means towards
enumerating the available plugins). Enumerating what indexes
ladspa_descriptor returns is just what I happened to write to be sure I
really did load the DLL successfully.
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris
wrote:
It shouldn't be neccesary to actually dlload() the .so file, if it is then
theres a mistake somewhere. This is why the "plugin" is really a
directory, all the stuff in there is
neccesary.
On the plugin bundle thing, I've got working C code that takes a path to
the directory, parses manifest.ttl, gleams the available plugin DLLs and
data files from that, and enumerates all the plugins in the DLL. We need to
clarify some things about bundles themselves:
- What is the significance of the bundle name itself? (We need to avoid
clashes somehow)
Yes, its a bit awkward. It would be nice to be able to use URIs, but thats
not going to wash.
I was planning something like
[abbreviated plugin name]-[collection name].whatever/
eg. Amp-swh.ladspa2
Assuming the number of collections doesnt grow to much, the current thing
of people using thier initials or similar should work fine. The maintainer
of each colleaction is responsible for making sure noone else uses the
same collection name, and that none of thier abbreviated names collide.
If we wanted to go overboard we could do something like
[abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/
eg. amp-5491370f050fa849.ladspa2/
which guarantees uniqueness, but its a bit of a pain, and the plugin bundle
names will be a bit ugly. - Do they
contain one plugin variant, or any number?
Probably leave it as a matter of taste. Though discouraging the cmt thing
is a good idea IMHO.
- One DLL or many?
As many as you want / need.
I'm not sure about
number-of-plugins-per-bundle (though putting all of,
say, swh-plugins in one bundle seems counter to the intent to me?) but I
will suggest we reccommend that one DLL contains only variants of one
plugin (or a group of very similar plugins). Reasoning is to avoid
things like cmt.so which has a huge number of completely unrelated
plugins in one lib, meaning a host has to link in all that crap just to
use a simple amplifier plugin, which is no good.
My intention was to have a pretty much 1:1 correspondance between .so's I
have now and bundles in the future. ie. most plugins are on thier own, but
logically grouped ones are in one .so. eg. a buch ov very similar
oscialltors, filters etc. I dont think its neccesary to specify this though, the
best natural level
usually settles out. ie. people see cmt.so, and go "arrrghhh!".
They go arrrrggghhh, but cmt.so remains with no settling in sight :)
I guess in the interests of defining as little as neccessary, it should
go unspecified (though as above a recommendation would be good). Large
bundles are okay because they ease the burden on the user, but I don't
see any benefit of a huge chunk of completely unrelated plugins being in
one .so
As long as we have this nice bundle format, I suppose both a LADSPA repo
site and a 'master package' of all LADSPA plugins can exist (both things
that are requested pretty often), though they would only be able to
usefully distribute binary builds, not source. :/
This is why I'm tempted to suggest that a bundle only contains related
plugins, so a user could easily just install the SWH amp (say on a
resource limited system). There's a lot of plugins out there that are
totally useless for some people, it would be nice if /users/ could
decide what plugins they want installed. But then of course the
directory name problem becomes a bigger one that'd need to be solved
properly..
-DR-
25 Apr
25 Apr
7:50 p.m.
Ok, some thoughts about the headerfile:
- i would find it helpful if the header also contained a definition of
a valid LADSPA URI, along with some examples.
- passing the HostFeatures in instantiate is a bit too late. i wouldnt
want to instantiate a plugin first to find out if they match i.e. when i
enumerate plugins to display them in a menu. furthermore i'm not sure if
it is an audio plugins duty to check the validity of a host. rather the
host should analyze a static string pointed member containing required
host features. this way the host programmer can choose the quickest
method to do a match check. at least i think so.
- why does the plugin require its own bundle path for instantiation?
this can usually be deduced from the dl's own runtime image information,
no? otherwise, an explanation of this choice in the comment would be
nice.
- comments still contain references to set_run_adding_gain
- LADSPA is an ugly name ;)
after reading this i do not see why a new ladspa header is required.
there are barely any changes in 2. i think this is going to become more
confusing than helpful, especially since it will not be possible to load
ladspa 1+2 plugins in the same host with ease (yes, people do not like
to fix orphaned code and recompile binaries, imagine!).
furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2.
again, looking at the slight changes that ladspa underwent, i dont see
what the big fuzz is about.
grumpily yours,
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
7:58 p.m.
On Tue, 2006-04-25 at 23:58 +0200, Leonard "paniq" Ritter wrote:
Ok, some thoughts about the headerfile:
[snip]
after reading this i do not see why a new ladspa
header is required.
there are barely any changes in 2. i think this is going to become more
confusing than helpful, especially since it will not be possible to load
ladspa 1+2 plugins in the same host with ease (yes, people do not like
to fix orphaned code and recompile binaries, imagine!).
You are completely missing the entire point of LADSPA2. All the
unecessary data has been removed from the header file (ie the plugin
code).
Look at the example plugin's code, it will be painfully obvious what the
advantage is.
-DR-
8:04 p.m.
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
On Tue, 2006-04-25 at 23:58 +0200, Leonard
"paniq" Ritter wrote:
Well, with sufficeint use of calloc and careful spec wording its possible
to get the same affect with no change to the struct, but I just dont see
the point. The plugin and host code has to change anyway, and its less
ugly if its removed.
If we ever have an ABI change in the future then the LADSPA 1
pseudo-compatibility will be lost anyway.
- Steve
Ok, some thoughts about the headerfile:
[snip]
after reading this i do not see why a new ladspa
header is required.
there are barely any changes in 2. i think this is going to become more
confusing than helpful, especially since it will not be possible to load
ladspa 1+2 plugins in the same host with ease (yes, people do not like
to fix orphaned code and recompile binaries, imagine!).
You are completely missing the entire point of LADSPA2. All the
unecessary data has been removed from the header file (ie the plugin
code).
Look at the example plugin's code, it will be painfully obvious what the
advantage is.
8:27 p.m.
If we ever have an ABI change in the future then the
LADSPA 1
pseudo-compatibility will be lost anyway.
there is a difference between fixing and recompiling code ;)
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
2 May
2 May
9:50 a.m.
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
You are completely missing the entire point of
LADSPA2. All the
unecessary data has been removed from the header file (ie the plugin
code).
Look at the example plugin's code, it will be painfully obvious what the
advantage is.
A lot of plugins create what is essentially a block of constants by
dynamically allocating and initialising every bit of it. ISTR there was
(is) even an 'offical' plugin example source doing it that way.
Compared to that the new code is indeed simpler. But it's a braindead
way of doing it really, and that makes the comparison totally invalid.
I really don't see what is 'complex' or 'difficult' about e.g.
static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] =
{
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_CONTROL,
....
};
Further, you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
--
FA
Follie! Follie! Delirio vano e' questo!
5:16 p.m.
On Tue, 2006-05-02 at 13:50 +0200, Alfons Adriaensen wrote:
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave
Robillard wrote:
That would be a valid point if all the data that people wanted to
associate with plugins was strictly defined right now (which is
impossible). That is the whole problem with LADSPA1 that we need to fix
here, hence the external data file.
You are completely missing the entire point of
LADSPA2. All the
unecessary data has been removed from the header file (ie the plugin
code).
Look at the example plugin's code, it will be painfully obvious what the
advantage is.
A lot of plugins create what is essentially a block of constants by
dynamically allocating and initialising every bit of it. ISTR there was
(is) even an 'offical' plugin example source doing it that way.
Compared to that the new code is indeed simpler. But it's a braindead
way of doing it really, and that makes the comparison totally invalid.
I really don't see what is 'complex' or 'difficult' about e.g.
static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] =
{
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_CONTROL,
....
};
Further, you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Since the plugin author writes both and they are strongly associated
with (and depend on) each other, the plugin can 'assume' eg. the type of
it's ports. Plugin code definitely won't be reading the RDF file.
-DR-
5:33 p.m.
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote:
I've not yet seen a plugin that introspects its own port hints either, but
don't take that as a challenge ;)
- Steve
Further, you
can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Since the plugin author writes both and they are strongly associated
with (and depend on) each other, the plugin can 'assume' eg. the type of
it's ports. Plugin code definitely won't be reading the RDF file.S
5:50 p.m.
On Tue, 2006-05-02 at 20:32 +0100, Steve Harris wrote:
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard
wrote:
I've not yet seen a plugin that introspects its own port hints either, but
don't take that as a challenge ;)
I suppose it does have a path to it's own bundle, and could
theoretically parse manifest.ttl to find it's own data file and do what
it wants with it.
But.. I mean... just.. no! :)
(I did actually consider adding plugin-side hooks to my ladspa2 library
but decided against it)
--
Speaking of the library, status update: I have successfully processed
data with the example plugin in about 5 lines of C code. Plugins can be
'loaded' with one LOC using only the URI (finding and loading the plugin
is all automagic), and instantiated with one more LOC.
-DR-
Further,
you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Since the plugin author writes both and they are strongly associated
with (and depend on) each other, the plugin can 'assume' eg. the type of
it's ports. Plugin code definitely won't be reading the RDF file.S
25 Apr
25 Apr
8:02 p.m.
On Tue, Apr 25, 2006 at 11:58:23PM +0200, Leonard paniq Ritter wrote:
Ok, some thoughts about the headerfile:
- i would find it helpful if the header also contained a definition of
a valid LADSPA URI, along with some examples.
Yes, we were discussing this on IRC an hour or so ago. Any URI is a valid
LADSPA URI, but there are some helpful recommendations.
NB, the header file is just a hacked about ladspa.h, it's far from
finished.
- passing the HostFeatures in instantiate is a bit too
late. i wouldnt
want to instantiate a plugin first to find out if they match i.e. when i
enumerate plugins to display them in a menu. furthermore i'm not sure if
it is an audio plugins duty to check the validity of a host. rather the
host should analyze a static string pointed member containing required
host features. this way the host programmer can choose the quickest
method to do a match check. at least i think so.
I think the easiest thing would be for the plugin to list its required
features in the data file, then the host can weed them out without even
getting that far.
The plugin may just choose to modify its behaviour, not refuse, so the
featuers list still should be passed to instantiate IMHO.
- why does the plugin require its own bundle path for
instantiation?
this can usually be deduced from the dl's own runtime image information,
no? otherwise, an explanation of this choice in the comment would be
nice.
Can it? I wasn't aware of that, in that case its redundant.
- comments still contain references to
set_run_adding_gain
Cheers, I'l fix that.
- LADSPA is an ugly name ;)
Yep.
after reading this i do not see why a new ladspa
header is required.
there are barely any changes in 2. i think this is going to become more
confusing than helpful, especially since it will not be possible to load
ladspa 1+2 plugins in the same host with ease (yes, people do not like
to fix orphaned code and recompile binaries, imagine!).
It should be perfectly possible to load both. Personally I prefer to
remove obsolete cruft, but its a matter of taste. I did consder just
ignoring the obsolete fields and resusing label as the uri, but its kinda
ugly.
furthermore, DSSI builds upon ladspa. a ladspa 2
enforces also a DSSI 2.
again, looking at the slight changes that ladspa underwent, i dont see
what the big fuzz is about.
Yes, but that's desirable anyway. With some of the (potential) new
capbilities there are less ugly ways to do some of the things DSSI does,
DSSI 2 should be much less complex that 1.
- Steve
8:25 p.m.
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
i assume the lib file resides in the bundle path or the bundle path has
been compiled into the lib. on win32, GetModulePath can be used to get
the path to the current module, i do not know the posix equivalent to do
that.
alternatively the host could be required to chdir to the bundle folder
before the plugin is being instantiated?
I think the easiest thing would be for the plugin to
list its required
features in the data file, then the host can weed them out without even
getting that far.
yup.
The plugin may just choose to modify its behaviour,
not refuse, so the
featuers list still should be passed to instantiate IMHO.
if it never refuses then its ok with me ;)
- why does the plugin require its own bundle path
for instantiation?
this can usually be deduced from the dl's own runtime image information,
no? otherwise, an explanation of this choice in the comment would be
nice.
Can it? I wasn't aware of that, in that case its redundant. It should be perfectly possible to load both.
Personally I prefer to
remove obsolete cruft, but its a matter of taste. I did consder just
ignoring the obsolete fields and resusing label as the uri, but its kinda
ugly.
i just had a discussion with dave robillard on irc regarding this topic.
my original (silly) wish of just changing the name has now a pragmatical
basis. from my point of view, ladspa 2 is something different than
ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated
plugin on the system. counting the mass of different plugins already
available, it might take up to a year until distros catch up. you could
avoid these migration issues if ladspa 2 had an entirely different name.
none of the previous binaries have to be rebuilt, and can happily bitrot
until no distro is supporting them anymore.
it is maybe neccessary to support future api changes from the start, to
allow soft migrations?
Yes, but that's desirable anyway. With some of the (potential) new
capbilities there are less ugly ways to do some of the things DSSI does,
DSSI 2 should be much less complex that 1.
how are parameter boundaries determined now? are all parameters clamped
to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the
comments?
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
8:46 p.m.
On Wed, 2006-04-26 at 00:33 +0200, Leonard "paniq" Ritter wrote:
Plugins must be able to refuse hosts and hosts must be able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide. This is a Good Thing.
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris
wrote:
++
Definitely shouldn't have to instantiate a plugin to see if you even
want it, especially since (as mentioned) this would make the user
experience awful.
I think the easiest thing would be for the plugin
to list its required
features in the data file, then the host can weed them out without even
getting that far.
yup. The plugin may
just choose to modify its behaviour, not refuse, so the
featuers list still should be passed to instantiate IMHO.
if it never refuses then its ok with me ;) i just had a discussion with dave robillard on irc
regarding this topic.
my original (silly) wish of just changing the name has now a pragmatical
basis. from my point of view, ladspa 2 is something different than
ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated
plugin on the system. counting the mass of different plugins already
available, it might take up to a year until distros catch up. you could
avoid these migration issues if ladspa 2 had an entirely different name.
none of the previous binaries have to be rebuilt, and can happily bitrot
until no distro is supporting them anymore.
While I am with you on the name thing, you don't understand. LADSPA2
will be completely installable in parallel with LADSPA1. Obviously it
will not "replace" LADSPA1 on a system and immediately break all the
installed plugins!
how are parameter boundaries determined now? are all
parameters clamped
to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the
comments?
This, like most everything else, is in the data file. You really need
to read more than the header before commenting further ;)
-DR-
9:15 p.m.
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote:
Plugins must be able to refuse hosts and hosts must be
able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide. This is a Good Thing.
maybe in a Perfect World. in practice, we are going to face irritations
when plugins demand weird non-unified URIs to be passed in order to run
at all. from what i see, no new URIs can be invented without requiring
immediate support in all available hosts, and plugins that initially
only work for one host are not that cool. ergo, the "feature" of
blocking instantiation for a host not passing a required URI will be
rarely used, for the simple reason that it might not work with all
hosts. thus, do not allow it by spec.
from my point of view, host features should be seen as "hints", which
are not required, but of a suggestive nature.
my argumentation is chaotic. decipher the obvious!
While I am with you on the name thing, you don't understand. LADSPA2
will be completely installable in parallel with LADSPA1. Obviously it
will not "replace" LADSPA1 on a system and immediately break all the
installed plugins!
i hope this is taken care of! the new header suggests replacement, not
complementation.
This, like most everything else, is in the data file. You really need
to read more than the header before commenting further ;)
the trusty header should be all documentation required... there was also
no reference to additional documents in it. how about adding it? :o)
-DR-
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
9:58 p.m.
On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote:
If you think the header should be all the documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
-DR-
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard
wrote:
Where did you get this crazy idea? The whole point is that different
hosts can provide different features.
Plugins must be able to refuse hosts and hosts
must be able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide. This is a Good Thing.
maybe in a Perfect World. in practice, we are going to face irritations
when plugins demand weird non-unified URIs to be passed in order to run
at all. from what i see, no new URIs can be invented without requiring
immediate support in all available hosts and plugins that initially
only work for one host are not that cool. ergo, the "feature" of
blocking instantiation for a host not passing a required URI will be
rarely used, for the simple reason that it might not work with all
hosts. thus, do not allow it by spec.
You want to impose plugins work on the lowest common denominator of
hosts. Basically this amounts to mandating that certain plugins simply
can not exist. Why would you want to do that?
from my point of view, host features should be seen as
"hints", which
are not required, but of a suggestive nature.
Plugins are free to interpret them as such and not /require/ the
feature. It's totally up to the plugin.
my argumentation is chaotic. decipher the obvious!
The fact that you even considered that someone would really do this is
frightening. Not an issue ;)
While I am with you on the name thing, you don't understand. LADSPA2
will be completely installable in parallel with LADSPA1. Obviously it
will not "replace" LADSPA1 on a system and immediately break all the
installed plugins!
i hope this is taken care of! the new header suggests replacement, not
complementation. This, like
most everything else, is in the data file. You really need
to read more than the header before commenting further ;)
the trusty header should be all documentation required... there was also
no reference to additional documents in it. how about adding it? :o)
11:02 p.m.
On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote:
no i do not want to do that. this is a misunderstanding. please explain
how you got this impression.
i have seen things you humans will never understand.
On Wed, 2006-04-26 at 01:23 +0200, Leonard
"paniq" Ritter wrote:
i agree. but i suppose this is a misunderstanding. why do you think it
is a crazy idea?
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard
wrote:
Where did you get this crazy idea? The whole point is that different
hosts can provide different features. Plugins must be able to refuse hosts and hosts
must be able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide. This is a Good Thing.
maybe in a Perfect World. in practice, we are going to face irritations
when plugins demand weird non-unified URIs to be passed in order to run
at all. from what i see, no new URIs can be invented without requiring
immediate support in all available hosts and plugins that initially
only work for one host are not that cool. ergo, the "feature" of
blocking instantiation for a host not passing a required URI will be
rarely used, for the simple reason that it might not work with all
hosts. thus, do not allow it by spec.
You want to impose plugins work on the lowest common denominator of
hosts. Basically this amounts to mandating that certain plugins simply
can not exist. Why would you want to do that? i hope this is taken care of! the new header
suggests replacement, not
complementation.
The fact that you even considered that someone would really do this is
frightening. Not an issue ;)
If you think the header should be all the documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
i was able to implement a working ladspa host implementation only from
the header, and that was a good experience. i would like it if it could
stay that way. a tiny reference to an additional document that should be
read in the header would also be cool. not mentioning required
literature is unfriendly ;)
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
26 Apr
26 Apr
12:05 a.m.
On Wed, Apr 26, 2006 at 03:11:10AM +0200, Leonard paniq Ritter wrote:
On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard
wrote:
You are not alone on this one. I think it's great to have as much data
as possible in a place that need not be dlopened to access. However, if
I have to learn to use some whizz-bang library to read yet another
markup language, spend an hour at w3c to learn about all these
web-inspired formats, and grok some ladspa-specific schema to manipulate
a plugin, I think this Simple Plugin API has missed the mark.
Now, obviously the current example is incomplete, but whenever this
stuff is done, I shouldn't have to write more than 5 lines of C to shove
some bits through a plugin, and it shouldn't take me more than 5 minutes
from the time I google "ladspa documentation" to learn to do it.
If browsing or using ladspa plugins would require more than 5 lines of C
or learning some new technology or library that does far more than I
care about, I suggest the ladspa sdk include a well documented, simple
convenience library to do the things that any ladspa host would want to
do. This includes things like finding available plugins, and querying
them for version, description, documentation references, and loading.
If everything I need to know to use ladspa won't reasonably fit in a
header, it isn't simple.
If you think the header should be all the
documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
i was able to implement a working ladspa host implementation only from
the header, and that was a good experience. i would like it if it could
stay that way. a tiny reference to an additional document that should be
read in the header would also be cool. not mentioning required
literature is unfriendly ;) 
12:52 a.m.
On Tue, 2006-04-25 at 22:05 -0400, Phil Frost wrote:
You are not alone on this one. I think it's great
to have as much data
as possible in a place that need not be dlopened to access. However, if
I have to learn to use some whizz-bang library to read yet another
markup language, spend an hour at w3c to learn about all these
web-inspired formats, and grok some ladspa-specific schema to manipulate
a plugin, I think this Simple Plugin API has missed the mark.
Now, obviously the current example is incomplete, but whenever this
stuff is done, I shouldn't have to write more than 5 lines of C to shove
some bits through a plugin, and it shouldn't take me more than 5 minutes
from the time I google "ladspa documentation" to learn to do it.
it takes *way* more lines of code than that to use a ladspa plugin in
this way, and thats for the existing header-only specification.
one the design goals of a good plugin API is to make life simple for
plugins, because there are lots of them and presumably quite a few
authors too, at a certain expense to hosts, because there are relatively
few of them and their authors are likely to be more skilled at what they
are doing.
there are lots of little gotchas even with the amazingly simple API that
LADSPA 1 represents, and quite a few of these will become simpler or
will vanish with the metadata scheme that steve has outlined.
--p
8:06 a.m.
On Tue, 25 Apr 2006 22:55:55 -0400
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
it takes *way* more lines of code than that to use a
ladspa plugin in
this way, and thats for the existing header-only specification.
one the design goals of a good plugin API is to make life simple for
plugins, because there are lots of them and presumably quite a few
authors too, at a certain expense to hosts, because there are relatively
few of them and their authors are likely to be more skilled at what they
are doing.
there are lots of little gotchas even with the amazingly simple API that
LADSPA 1 represents, and quite a few of these will become simpler or
will vanish with the metadata scheme that steve has outlined.
Erm, just to voice my opinion on this LADSPA 2 thing i kinda hijack your
post to
Vote++;
@Phil: Look at the example plugin. Life does get easier with this.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
1:16 a.m.
On Tue, 2006-04-25 at 22:05 -0400, Phil Frost wrote:
On Wed, Apr 26, 2006 at 03:11:10AM +0200, Leonard
paniq Ritter wrote:
You're in luck. I'm already in the process of writing said library. :)
Loading and using a LADSPA2 plugin (using the library) will be
significantly less code than loading a LADSPA1, and certainly be a _lot_
more readable.
-DR-
On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard
wrote:
You are not alone on this one. I think it's great to have as much data
as possible in a place that need not be dlopened to access. However, if
I have to learn to use some whizz-bang library to read yet another
markup language, spend an hour at w3c to learn about all these
web-inspired formats, and grok some ladspa-specific schema to manipulate
a plugin, I think this Simple Plugin API has missed the mark.
Now, obviously the current example is incomplete, but whenever this
stuff is done, I shouldn't have to write more than 5 lines of C to shove
some bits through a plugin, and it shouldn't take me more than 5 minutes
from the time I google "ladspa documentation" to learn to do it.
If browsing or using ladspa plugins would require more than 5 lines of C
or learning some new technology or library that does far more than I
care about, I suggest the ladspa sdk include a well documented, simple
convenience library to do the things that any ladspa host would want to
do. This includes things like finding available plugins, and querying
them for version, description, documentation references, and loading.
If everything I need to know to use ladspa won't reasonably fit in a
header, it isn't simple. If you think the header should be all the
documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
i was able to implement a working ladspa host implementation only from
the header, and that was a good experience. i would like it if it could
stay that way. a tiny reference to an additional document that should be
read in the header would also be cool. not mentioning required
literature is unfriendly ;)
3:48 a.m.
On Wed, Apr 26, 2006 at 12:33:50 +0200, Leonard paniq Ritter wrote:
i assume the lib file resides in the bundle path or the bundle path has
been compiled into the lib. on win32, GetModulePath can be used to get
the path to the current module, i do not know the posix equivalent to do
that.
thats platform specific though, seems like the plugins shouldn't be full
of #ifdef WIN32 ... code.
There is no LADSPA "system", its just a specification, so theres nothing
to be replaced. All LADSPA 1.x software will be unaffected.
Thier specified by range hints, allowing natural values, and the plugins
are required to accept any value, though not neccesarily do anything
sensibe with it.
We Like It That Way.
- Steve
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris
wrote:
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
I think the easiest thing would be for the plugin
to list its required
features in the data file, then the host can weed them out without even
getting that far.
yup.
The plugin may just choose to modify its
behaviour, not refuse, so the
featuers list still should be passed to instantiate IMHO.
if it never refuses then its ok with me ;) - why does the plugin require its own bundle path for
instantiation?
this can usually be deduced from the dl's own runtime image information,
no? otherwise, an explanation of this choice in the comment would be
nice.
Can it? I wasn't aware of that, in that case its redundant. alternatively the host could be required to chdir to
the bundle folder
before the plugin is being instantiated?
Thats likely to cause all manner of excitement.
It should be
perfectly possible to load both. Personally I prefer to
remove obsolete cruft, but its a matter of taste. I did consder just
ignoring the obsolete fields and resusing label as the uri, but its kinda
ugly.
i just had a discussion with dave robillard on irc regarding this topic.
my original (silly) wish of just changing the name has now a pragmatical
basis. from my point of view, ladspa 2 is something different than
ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated
plugin on the system. counting the mass of different plugins already
available, it might take up to a year until distros catch up. you could
avoid these migration issues if ladspa 2 had an entirely different name.
none of the previous binaries have to be rebuilt, and can happily bitrot
until no distro is supporting them anymore. it is maybe neccessary to support future api changes
from the start, to
allow soft migrations?
Perhaps, I think that can be done in the data though.
Yes, but
that's desirable anyway. With some of the (potential) new
capbilities there are less ugly ways to do some of the things DSSI does,
DSSI 2 should be much less complex that 1.
how are parameter boundaries determined now? are all parameters clamped
to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the
comments?
3:53 p.m.
On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote:
so required features have to be checked on both sides. isn't that
redundant?
furthermore, surely there are other reasons why instantiation could
fail. how can the host determine the reason for which a plugin refused
to instantiate?
the erotic kind of excitement? ;)
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org
if it never
refuses then its ok with me ;)
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
thats platform specific though, seems like the plugins shouldn't be full
of #ifdef WIN32 ... code.
yes, of course, that would be nonsense. but in case there is a posix
equivalent, it will be available on win32 as well. but i dont know
anything more about this.
alternatively the host could be required to chdir
to the bundle folder
before the plugin is being instantiated?
Thats likely to cause all manner of excitement.
4:05 p.m.
On Wed, 2006-04-26 at 20:04 +0200, Leonard "paniq" Ritter wrote:
On Wed, 2006-04-26 at 06:48 +0100, Steve Harris
wrote:
so required features have to be checked on both sides. isn't that
redundant?
The plugin (obviously) needs to check the features anyway, since it
needs to (or may want to) use them. Can't use something if you don't
even know if it's there.
-DR-
if it
never refuses then its ok with me ;)
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
4:08 p.m.
On Wed, Apr 26, 2006 at 08:04:35PM +0200, Leonard paniq Ritter wrote:
the erotic kind of excitement? ;)
More the running around screaming kind ;)
- Steve
On Wed, 2006-04-26 at 06:48 +0100, Steve Harris
wrote:
so required features have to be checked on both sides. isn't that
redundant?
SupportedFeatures is not just fo requirements. eg. Fon's plyphonic control
ports can work around the case where the host doesnt support it.
if it
never refuses then its ok with me ;)
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list. furthermore, surely there are other reasons why
instantiation could
fail. how can the host determine the reason for which a plugin refused
to instantiate?
It can't. Meh.
alternatively the host could be required to chdir to
the bundle folder
before the plugin is being instantiated?
Thats likely to cause all manner of excitement. 
24 Apr
24 Apr
9:54 p.m.
On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote:
On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard
wrote:
Well then let me weigh in. I have in the past cursed the insensibility
of referencing a port with its arbitrary (from the human's POV)
numerical ID. I want human-friendly port IDs.
For the sake of the record, it's been duked
out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
Actually I didn't mean to say that they /will/ be required, just that I
don't have a problem with it. I've not heard anyone else speak in favour
of this, and it is a feature. If theres a critical mass of support I'm OK
with adding it, as it should make the lives of some hosts much easier. At the risk of upsetting Dave, it can be added a a 3rd
party extension
without anything really bad happening. It just means that the Pd messages
/ OSC paths / whatever for some plugins will be ugly. "Market pressure"
will ensire that all plugins support it if its useful to enough users.
Ick. I'm all for market pressure, but this is not the place for it, IMHO.
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
10:26 p.m.
New subject: [linux-audio-dev] Re: LADSPA 2
On 4/25/06, Hans Fugal <hans(a)fugal.net> wrote:
On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris
wrote:
Me too.
On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave
Robillard wrote:
Well then let me weigh in. I have in the past cursed the insensibility
of referencing a port with its arbitrary (from the human's POV)
numerical ID. I want human-friendly port IDs. For the sake of the record, it's been duked
out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
Actually I didn't mean to say that they /will/ be required, just that I
don't have a problem with it. I've not heard anyone else speak in favour
of this, and it is a feature. If theres a critical mass of support I'm OK
with adding it, as it should make the lives of some hosts much easier.
25 Apr
25 Apr
7 a.m.
New subject: [linux-audio-dev] Re: LADSPA 2
On Tue, Apr 25, 2006 at 10:26:09AM +1000, Loki Davison wrote:
On 4/25/06, Hans Fugal <hans(a)fugal.net> wrote:
OK, given that no-one has spoken out against it, I'm happy to include
a required shortname for ports, that must be [_a-zA-Z][_a-zA-Z0-9]* or
similar.
It's a burdon on all plugin authors, but host authors can ignore it.
I've tentatively added ladspa:shortname to the stawman plugin's ports.
- Steve
On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris
wrote:
Me too. On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave
Robillard wrote:
Well then let me weigh in. I have in the past cursed the insensibility
of referencing a port with its arbitrary (from the human's POV)
numerical ID. I want human-friendly port IDs. For the sake of the record, it's been duked
out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
Actually I didn't mean to say that they /will/ be required, just that I
don't have a problem with it. I've not heard anyone else speak in favour
of this, and it is a feature. If theres a critical mass of support I'm OK
with adding it, as it should make the lives of some hosts much easier. 
2:38 a.m.
On Apr 24, 2006, at 7:53 PM, Hans Fugal wrote:
On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris
wrote:
Why not? I think it's a great way of organically growing the spec by
testing popularity and usage in the real world first.
Taybin
At the risk of upsetting Dave, it can be added a
a 3rd party
extension
without anything really bad happening. It just means that the Pd
messages
/ OSC paths / whatever for some plugins will be ugly. "Market
pressure"
will ensire that all plugins support it if its useful to enough
users.
Ick. I'm all for market pressure, but this is not the place for it,
IMHO.
22 Apr
22 Apr
1:41 p.m.
On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote:
Almost two years ago at the LA conference a bunch of
us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
[...]
In my experience developing modular synths, it would be a huge benefit
to performance if modules had the option of including source code in the
bundle. This is especially useful if the module can provide a function
that calculates the outputs one sample at a time. I reckon most modules
which do not do any frequency domain calculations can do this.
The reason it's so great is because it allows the host to inline those
functions and call on a C compiler to optimize them together. For some
simple functions, constant folding can make a huge difference. Perhaps
more importantly, the sample buffer between the modules can be
eliminated. When each module does something simple, say a low order IIR,
an oscilator, or a multiplier, the load and store is much slower than
the calculation that happens between them. If the result can be left in
a register for the next module to process, the system becomes much more
efficient. When the process functions are inlined, there is not even the
overhead of a call.
Also, included source is simply convienent if one wishes to tinker with
the module, or run it on a different platform. Perhaps the compiled
version should have a platform-unique name within the bundle, and be
marked with a hash of the source, so that it can be rebuilt when needed,
preferably with some shared ladspa build tool.
Lastly, I'm not saying bundles-as-directories is a bad idea, but an
alternative to an openstep bundle is an ar archive. It works like tar,
only it is designed for nonsequential access of members. ".a" static
libraries and ".deb" debian packages are really just ar archives.
2:44 p.m.
On Sat, 2006-04-22 at 11:41 -0400, Phil Frost wrote:
On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris
wrote:
It would definitely be a really, really cool thing if we could do this.
LADSPA plugins would be useful in so many more domains if "hosts" could
get at the code...
The downside is that we would have to mandate a standard build system
and FS layout of some variety. I'm generally not for such dictatorial
things, but in this case I think it's justified. Having some sort of
standard build system/directory layout/etc (ie a completely standardized
plugin package inc. source code) would allow a good LADSPA repository
site to be easily built as well - something else I think is sorely
needed. The current "system" of LADSPA distribution definitely sucks.
-DR-
Almost two years ago at the LA conference a bunch
of us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
[...]
In my experience developing modular synths, it would be a huge benefit
to performance if modules had the option of including source code in the
bundle. This is especially useful if the module can provide a function
that calculates the outputs one sample at a time. I reckon most modules
which do not do any frequency domain calculations can do this.
2:48 p.m.
On Sat, Apr 22, 2006 at 11:41:16AM -0400, Phil Frost wrote:
On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris
wrote:
That's too big a departure from LADSPA 1.x for me to consider right now.
Almost two years ago at the LA conference a bunch
of us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
[...]
In my experience developing modular synths, it would be a huge benefit
to performance if modules had the option of including source code in the
bundle. This is especially useful if the module can provide a function
that calculates the outputs one sample at a time. I reckon most modules
which do not do any frequency domain calculations can do this. Lastly, I'm not saying bundles-as-directories is a
bad idea, but an
alternative to an openstep bundle is an ar archive. It works like tar,
only it is designed for nonsequential access of members. ".a" static
libraries and ".deb" debian packages are really just ar archives.
Yes, also jar/xpi zip files are possible. I've nothing against them, but
they mean more work for plugin and host authors, and its slightly more
work for curious users to find out what's in a plugin. The advantage being
that its a single file to pass around.
I did give it some thought, and came to the comclusion that directories
were /slightly/ better overall. My mind is not set in concrete though.
- Steve
23 Apr
23 Apr
5:20 a.m.
New subject: [linux-audio-dev] LACPA
Since people seem to see the necessity for some more functionality
within plugins, i want
to present LACPA (Linux Audio Cluster Plugin Api), which was intended to
be the
plugin api of the linux audio cluster (which i never finished due to the
lack of time).
Its main features:
* usable for midi/audio plugins (one plugin could be a host for other
plugins as well)
* sampleaccurate timeinfo for sequencers, tempo-synched
effects/instruments, video
* fixed size audiobuffers (good for use with networks and frequency
domain effects)
* extensible while keeping binary downward compatability
* no dependencies between host's and plugin's gui (plugins guis are
supposed to run in their own process)
BTW, by adding a control type "message", the realtime message part of
LACPA could be easily
added to LADSPA without breaking existing hosts .
Ralf
#ifndef LACPA
#define LACPA
#ifdef __cplusplus
extern "C" {
#endif
/* return value for all functions */
#define LACPA_NOT_PROCESSED 0
#define LACPA_PROCESSED 1
typedef float LACPA_FRAME; /* audio type -1.0 .. +1.0 */
typedef float LACPA_CONTROL; /* control type 0.0 .. 1.0 */
/* opaque plugin type */
typedef void * LACPA_PLUGIN;
/* initialise is called by host immediately after loading the library:
PARAMETERS:
plug2host: callback for plug -> host non-realtime messages
*/
int (*initialise)(int (*plug2host)(LACPA_PLUGIN plug, int msg, void *arg, void *ret));
/* create a new plugin instance
Note:
a plugin is initially suspended and has its editor closed
*/
LACPA_PLUGIN (*create)(void);
/* delete a plugin instance
PARAMETERS:
plug : plugin instance returne by create()
*/
int (*delete)(LACPA_PLUGIN plug);
/* callback to be used by the plugin to send a
non-realtime message to the host.
Must be supplied by the host in initialise().
PARAMETERS:
plug: plugin instance returned by create()
msgtype: non-realtime plug -> host message type
arg: pointer to message specific arguments
ret: pointer for returning values
int (*plug2host)(LACPA_PLUGIN plug, int msgtype, void *arg, void *ret);
Following plug -> host messages are currently defined:
LACPA_EDIT_OFF: arg = NULL, ret = NULL: editor window has been closed
LACPA_IO_CHANGE: arg = NULL, ret = NULL: plugin changed its inputs or outputs
In response to this the host is supposed to suspend the plugin and
reread the i/o configuration
*/
#define LACPA_EDIT_OFF 1
#define LACPA_IO_CHANGE 2
/* non-realtime host to plugin messages
PARAMETERS:
plug: plugin instance returned by create()
msgtype: non-realtime host -> plugin message type
arg: message specific arguments
ret: returned values
*/
int (*host2plug)(LACPA_PLUGIN instance, int msgtype, void *arg, void *ret);
/* Following plug -> host messages are currently defined:
LACPA_VENDOR_SPECIFIC: used for vendor specific messages
LACPA_PROCESS_START: arg = NULL, ret = NULL: process will be called from now
LACPA_PROCESS_STOP: arg = NULL, ret = NULL: process will not be called from now
LACPA_PLUGIN_NAME: arg = NULL, ret = char * = name of plugin
LACPA_PLUGIN_CATEGORY: arg = NULL, ret = char * = name of plugin category
LACPA_PLUGIN_VENDOR: arg = NULL, ret = char * = name of plugin vendor
LACPA_SAMPLERATE: arr = int samplerate, ret = NULL: set the samplerate (called while
suspended)
LACPA_BUFFERSIZE: arg = int buffersize, ret = NULL: set the buffersize (called while
suspended)
LACPA_NUM_PARAMETERS: arg = NULL, ret = int = number of controls
LACPA_CONTROL_VALUE: arg = struct control, ret = char * = human readable of the value
(e.g. "-20")
LACPA_CONTROL_UNIT: arg = int index, ret = char * = human readable unit of value (e.g.
"dB")
LACPA_CONTROL_NAME: arg = int index, ret = char * = name of control (e.g.
"Gain")
LACPA_NUM_INPUTS: arg = NULL, ret = int = number of inputs
LACPA_NUM_OUTPUTS: arg = NULL, ret = int = number of outputs
LACPA_INPUT_NAME: arg = int index, ret = char * = name of audio channel (e.g.
"left input")
LACPA_OUTPUT_NAME: arg = int index, ret = char * = name of audio channel (e.g.
"left output")
LACPA_TICKS_PER_BEAT: arg int tpb: set the ticks per beat (sequencer resolution)
LACPA_SMPTE_TYPE: arg int smpte: set the SMPTE type (see below)
LACPA_LATENCY: arg = NULL, ret = int latency: get plugin latency in samples
LACPA_EDITOR_ON: arg = NULL, ret = NULL: instruct plugin to open its editor window
LACPA_EDITOR_OFF: arg = NULL, ret = NULL: instruct plugin to close its editor window
*/
#define LACPA_VENDOR_SPECIFIC 0
#define LACPA_PROCESS_START 1
#define LACPA_PROCESS_STOP 2
#define LACPA_PLUGIN_NAME 3
#define LACPA_PLUGIN_CATEGORY 4
#define LACPA_PLUGIN_VENDOR 5
#define LACPA_SAMPLERATE 6
#define LACPA_BUFFERSIZE 7
#define LACPA_NUM_CONTROLS 8
#define LACPA_CONTROL_NAME 9
#define LACPA_CONTROL_UNIT 10
#define LACPA_CONTROL_VALUE_STRING 11
#define LACPA_NUM_INPUTS 12
#define LACPA_NUM_OUTPUTS 13
#define LACPA_INPUT_NAME 14
#define LACPA_OUTPUT_NAME 15
#define LACPA_TICKS_PER_BEAT 16
#define LACPA_SMPTE_TYPE 17
#define LACPA_LATENCY 18
#define LACPA_EDITOR_ON 19
#define LACPA_EDITOR_OFF 20
/* SMPTE types */
#define LACPA_SMPTE_24 1
#define LACPA_SMPTE_25 2
#define LACPA_SMPTE_30 3
#define LACPA_SMPTE_29d 4
#define LACPA_SMPTE_30d 5
/* realtime processing routine
PARAMETERS:
plug: plugin instance returned by create()
inmsg: pointer to linked list of realtime messages for plugin
outmsg: pointer to pointer to linked list for realtime messages produced by plugin
in: pointer to array of pointers to input buffers
out: pointer to array of pointers to output buffers
*/
struct lacpa_rt_msg;
typedef struct lacpa_rt_msg *LACPA_MSG;
int (*process)(LACPA_PLUGIN plug,
LACPA_MSG *inmsg, LACPA_MSG **outmsg,
LACPA_FRAME **in, LACPA_FRAME **out);
/* realtime messages to be sent to/from plugin through process():
LACPA_MIDI: 1-3 byte midi messages
LACPA_SYSEX: Midi sysex message
LACPA_CTRL: control, range 0.0 - 1.0
LACPA_BBT: Timeinfo in Beats/Bar/Ticks
LACPA_SMPTE: Timeinfo in SMPTE FRAMES
-- more to be added as needed
*/
#define LACPA_MIDI 0
#define LACPA_SYSEX 1
#define LACPA_CTRL 2
#define LACPA_BBT 3
#define LACPA_SMPTE 4
struct lacpa_midi {
int port;
char data[4];
};
struct lacpa_sysex {
int port;
char *sysex;
};
struct lacpa_ctrl {
int index;
LACPA_CONTROL value;
};
struct lacpa_tempo {
float tempo;
};
struct lacpa_bbt {
int bar;
int beat;
int tick;
};
struct lacpa_smpte {
int hour;
int minute;
int second;
int frame;
};
struct lacpa_rt_msg {
LACPA_MSG next; /* next message in list */
int type; /* type of realtime message */
int frame; /* frame number within current process buffer */
union {
struct lacpa_midi m;
struct lacpa_sysex x;
struct lacpa_ctrl p;
struct lacpa_tempo t;
struct lacpa_bbt b;
struct lacpa_smpte s;
} lacpa_msg;
};
#ifdef __cplusplus
}
#endif
#endif /* LACPA */
9:11 a.m.
On Sat, 22 Apr 2006 10:53:58 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Almost two years ago at the LA conference a bunch of
us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
Hi,
thanks for taking the initiative on this! I would like to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
A hint which the plugin could set that it needs power of two periodsizes
for optimal operation would be nice, too. The host should be free to
ignore this and the plugin should still work (doing what it sees fit.
i.e. use non power of two fft window sizes or use double buffering
again), but at least the host could notify the user that this plugin
might work suboptimal.
The approach of chopping up the period into smaller chunks (i.e. to
update control data at non period boundaries) would still be available,
but the plugin should be able to rely on the chunks being i.e. in this
form:
---> time
|128 |128 |
| | | | | | | | |
Native buffer size being 128 frames [upper row] and the lower row is how
it is chopped up [as an example]. We see that all chopped up chunks add
up to the native period size. This enables an fft based plugin to
collect data over a whole period and do its stuff once for all these
samples, without the need for extra double buffering which is a problem
with current ladspa and dssi.
There would be an additional requirement put on the host: It has to use
a fixed underlying buffersize [optimally a power of two] even if it's
not bound to do this by the hardware/soundinterface it uses. I.e. a host
that does the processing freewheeling.
What do you think?
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
10:40 a.m.
On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote:
thanks for taking the initiative on this! I would like
to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
Thats a new feature. It'll have to wait til after 2.0 as far as I'm
concerned.
- Steve
1:04 p.m.
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian
Schmidt wrote:
I tend to disagree as it is kinda orthogonal to the other proposed
changes. What time other than a major version change is better to add
such a feature?
Aw hell, i'll try to get this into DSSI 2 then ;)
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
thanks for taking the initiative on this! I would
like to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
Thats a new feature. It'll have to wait til after 2.0 as far as I'm
concerned.
1:16 p.m.
On Sun, 2006-04-23 at 17:04 +0200, Florian Schmidt wrote:
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Couldn't it be done as an extension using the "features" parameter to
the instantiation function? If the host supports fixed buffer sizes it
can pass "FIXEDSIZE" or something in the features array, and the plugin
can add some sort of flag in the TTL file that says that it wants to be
called with a fixed buffer size. No need to add it explicitly in the
LADSPA2 specification.
Then, when the plugin sees that the host has the "FIXEDSIZE" feature, it
will know that the buffer size will always be the same. Hosts that don't
support this extension will ignore the flag in the TTL file and will not
pass the "FIXEDSIZE" feature to the instantiation function, and the
plugin can then either return NULL from that function, or switch
automatically to less efficient code that does not need a fixed buffer
size.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian
Schmidt wrote:
I tend to disagree as it is kinda orthogonal to the other proposed
changes. What time other than a major version change is better to add
such a feature?
Aw hell, i'll try to get this into DSSI 2 then ;) thanks for taking the initiative on this! I would
like to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
Thats a new feature. It'll have to wait til after 2.0 as far as I'm
concerned.
4:46 p.m.
On Sun, Apr 23, 2006 at 05:04:18PM +0200, Florian Schmidt wrote:
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Generally, I'd agree, but in this case I think it's a bad time. We need to
make sure we dont introduce anything that wierds the spec.
It changes both plugin and host code, so it will be easier to add things
once both have settled down, and the rought edges have been knocked off.
- Steve
On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian
Schmidt wrote:
I tend to disagree as it is kinda orthogonal to the other proposed
changes. What time other than a major version change is better to add
such a feature? thanks for taking the initiative on this! I would
like to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
Thats a new feature. It'll have to wait til after 2.0 as far as I'm
concerned.
6562
days inactive
6572
days old
linux-audio-dev@lists.linuxaudio.org
94 comments
20 participants
participants (20)
-
Alfons Adriaensen -
Dave Robillard -
Florian Paul Schmidt -
Florian Schmidt
-
fons adriaensen -
Hans Fugal -
Jack O'Quin -
Jesse Chappell -
Lars Luthman -
Leonard "paniq" Ritter -
Loki Davison -
Luis Garrido -
Paul Davis -
Phil Frost -
Ralf Beck -
Sampo Savolainen -
Steve Harris -
Taybin Rutkin -
Thorsten Wilms -
tom christie