22 Apr
2006
22 Apr
'06
4:12 p.m.
We haven't heard from a number of key people yet, but I think the overall
impression is positive so far. There are a number of decisions that need
to be made if it's going to go ahead. Either things that I didn't
consider, or where I made arbitrary choices:
A) Dropping runAdding: personally I dont think runAdding is worthwhile. How
many hosts take advantage of it? Its something LADSPA 1.1 can do and 2.0
wouldn't be able to though.
B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
C) Port scales: these weren't really in LADSPA 1.x, but they were in lrdf, so
adding them is a bit arguable. I think they're clearly beneficial though,
and they are getting close to critcal mass recently.
D) Port shortnames: for OSC, Pd etc. access. I dont have a strong feeling on
that. It /is/ an extension, but retrofitting it will mean OSC servers etc.
will have to support both accessor methods.
E) Bundles: no-one screamed when I suggested it, but its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier. Oh,
and the plugins needs to have the path of its bundle passed to it when its
instantiated, which isn't in the API right now.
F) Host OS specific macros in ladspa-2.h that Jack O'Q suggested. It seems
like a reasonable idea to me. No need to punish users of inferiour OSs
more than they are allready ;)
- Steve
22 Apr
22 Apr
4:19 p.m.
On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote:
E) Bundles: no-one screamed when I suggested it, but
its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier.
I don't really see the point in storing shared libraries in the bundle.
If you are using your own copy of a library already, why not just link
it statically?
I'm not saying that bundles are bad though.
--
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
6:12 p.m.
On Sat, Apr 22, 2006 at 08:19:44PM +0200, Lars Luthman wrote:
On Sat, 2006-04-22 at 19:12 +0100, Steve Harris
wrote:
Its for when theres a system installed version of the library, but you
want to provide one incase there isn't.
- Steve
E) Bundles: no-one screamed when I suggested it,
but its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier.
I don't really see the point in storing shared libraries in the bundle.
If you are using your own copy of a library already, why not just link
it statically?
6:25 p.m.
On Sat, Apr 22, 2006 at 09:11:17PM +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 08:19:44PM +0200, Lars Luthman
wrote:
Err... and this is so that you can provide plugins individually for
download, eg. for the case where someone downloads a patch that requires
one plugin you dont have, and otherwise it would have onerous requirements.
- Steve
On Sat, 2006-04-22 at 19:12 +0100, Steve Harris
wrote:
Its for when theres a system installed version of the library, but you
want to provide one incase there isn't. E) Bundles: no-one screamed when I suggested it,
but its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier.
I don't really see the point in storing shared libraries in the bundle.
If you are using your own copy of a library already, why not just link
it statically? 
4:22 p.m.
On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote:
We haven't heard from a number of key people yet,
but I think the overall
impression is positive so far. There are a number of decisions that need
to be made if it's going to go ahead. Either things that I didn't
consider, or where I made arbitrary choices:
A) Dropping runAdding: personally I dont think runAdding is worthwhile. How
many hosts take advantage of it? Its something LADSPA 1.1 can do and 2.0
wouldn't be able to though.
B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :)
E) Bundles: no-one screamed when I suggested it, but
its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier. Oh,
and the plugins needs to have the path of its bundle passed to it when its
instantiated, which isn't in the API right now.
I like the bundle idea, but I thik we need to have a long hard think
about this WRT distro package management systems and FHS compliance. We
do need some way of allowing plugins to load libraries though, but is it
really necessary to do the DLL Hell thing to allow it?
-DR-
4:56 p.m.
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
I've not made time for audio software much this past year, so discount me
if you will, but I agree. I just don't see the point of metadata outside
the plugin. I just don't get it.
B) RDF syntax:
RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :)
5:05 p.m.
On Sat, 2006-04-22 at 11:56 -0700, thockin(a)hockin.org wrote:
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave
Robillard wrote:
I've not made time for audio software much this past year, so discount me
if you will, but I agree. I just don't see the point of metadata outside
the plugin. I just don't get it.
nonono :) I think metadata outside the plugin is without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
-DR-
B) RDF
syntax: RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :)
5:34 p.m.
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote:
On Sat, 2006-04-22 at 11:56 -0700, thockin(a)hockin.org
wrote:
That's fine. I still don't get the point of seperating the two.
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave
Robillard wrote:
I've not made time for audio software much this past year, so discount me
if you will, but I agree. I just don't see the point of metadata outside
the plugin. I just don't get it.
nonono :) I think metadata outside the plugin is without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it. B) RDF
syntax: RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :)
5:36 p.m.
On Sat, 2006-04-22 at 12:34 -0700, thockin(a)hockin.org wrote:
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave
Robillard wrote:
Search the archives for any and all threads about adding this or that
trivial thing to LADSPA. Note how all ended with nothing done, and the
LADSPA situation hasn't gotten any better in the past 5 years. Guess
why?
We can't break the ABI every time someone might find a new piece of
metadata handy.
-DR-
On Sat, 2006-04-22 at 11:56 -0700,
thockin(a)hockin.org wrote:
That's fine. I still don't get the point of seperating the two. On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave
Robillard wrote:
nonono :) I think metadata outside the plugin is without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it. > B) RDF syntax: RDF/Turtle seems a lot more
popular in these parts than
> RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :)
I've not made time for audio software much this past year, so discount me
if you will, but I agree. I just don't see the point of metadata outside
the plugin. I just don't get it.
6:21 p.m.
On Sat, Apr 22, 2006 at 12:34:04PM -0700, thockin(a)hockin.org wrote:
We've done this disccusion to death, but anyway... if you have the
constant data inside the plugin binary then:
1) you have to load and link the binary to find anything about it
2) you have to have lots of tedious, but quite complex code everytime you
provide data (look how much pointless boilerplate code there is in a
ladspa .c just to make the port structures)
3) you risk binary incompatibility everytime you add to the static data
(think of the defaults problem in LADSPA 1)
4) you have a wierd licence situation around reusing the data
5) I18N is a pain
6) extensions have to change the binary, or be external anyway
and so on.
- Steve
nonono :) I
think metadata outside the plugin is without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
That's fine. I still don't get the point of seperating the two.
6:32 p.m.
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote:
nonono :) I think metadata outside the plugin is
without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
you cant usefully read RDF/XML with just an XML parser anyway. It's quite
a lot of work to transform from the XML tree to the RDF graph.
But yes, Turtle support is less widespeard than RDF/XML, but there are
still Free/Open parsers for every language I can think of (C(++), perl,
java, python, ruby, javascript, etc.)
- Steve
6:54 p.m.
On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave
Robillard wrote:
As long as it's part of the SDK (and the SDK doesn't have ridiculous
requirements), I say it's fine.
Speaking of SDK, the LADSPA2 SDK should include the above, and a (strict
as possible) demolition equivalent - not to mention example plugins that
are actually correct :)
-DR-
nonono :) I think metadata outside the plugin is
without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
you cant usefully read RDF/XML with just an XML parser anyway. It's quite
a lot of work to transform from the XML tree to the RDF graph.
But yes, Turtle support is less widespeard than RDF/XML, but there are
still Free/Open parsers for every language I can think of (C(++), perl,
java, python, ruby, javascript, etc.)
23 Apr
23 Apr
5:08 a.m.
On Sat, Apr 22, 2006 at 04:54:02 -0400, Dave Robillard wrote:
On Sat, 2006-04-22 at 21:32 +0100, Steve Harris
wrote:
I think a C header, RDF Schema, and bit a of example code is sufficient.
That's all the LADSPA 1.1 SDK is. If I was writing the example code, I'd
link to rasqal (http://librdf.org/rasqal/) which can query RDF/Turtle
files from disk efficiently.
Of course if people want to bundle up some tools and helper functions for
convienince then that's great, I dont think we want an SDK library though.
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave
Robillard wrote:
As long as it's part of the SDK (and the SDK doesn't have ridiculous
requirements), I say it's fine. nonono :) I think metadata outside the plugin is
without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
you cant usefully read RDF/XML with just an XML parser anyway. It's quite
a lot of work to transform from the XML tree to the RDF graph.
But yes, Turtle support is less widespeard than RDF/XML, but there are
still Free/Open parsers for every language I can think of (C(++), perl,
java, python, ruby, javascript, etc.) Speaking of SDK, the LADSPA2 SDK should include the
above, and a (strict
as possible) demolition equivalent - not to mention example plugins that
are actually correct :)
Yeah, that would help :-/
- Steve
24 Apr
24 Apr
9:12 a.m.
On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave
Robillard wrote:
Speaking as a general developer, I'd much rather you just used plain
XML. (Pretty much as you have now, in fact.)
Everyone knows XML, and we all have XML parsers installed for pretty
much every language.
Turtle isn't a standard, is aimed at much more general problem areas,
and will just force people to read more docs and install more packages.
It might be a bit nicer for the person writing the plugin file, but that
isn't that much work. (Or does turtle include some essential feature?)
Damon
PS. It sounds a bit strange to break backwards compatibility without
adding new features at the same time. When you do add new features will
you have to break backwards compatibility again?
nonono :) I think metadata outside the plugin is
without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
you cant usefully read RDF/XML with just an XML parser anyway. It's quite
a lot of work to transform from the XML tree to the RDF graph.
But yes, Turtle support is less widespeard than RDF/XML, but there are
still Free/Open parsers for every language I can think of (C(++), perl,
java, python, ruby, javascript, etc.)
9:22 a.m.
On Mon, Apr 24, 2006 at 11:11:39 +0100, Damon Chaplin wrote:
On Sat, 2006-04-22 at 21:32 +0100, Steve Harris
wrote:
The current system is RDF/XML, not vanlla XML, you cant parse it usefully
with stock XML parsers.
XML is not very easy to extend without breaking other peoples tools.
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave
Robillard wrote:
Speaking as a general developer, I'd much rather you just used plain
XML. (Pretty much as you have now, in fact.) nonono :) I think metadata outside the plugin is
without a doubt the
right way to go. I meant I'm just not a huge fan of the particular
syntax of this Turtle stuff (as opposed to normal well-formed XML).
Mostly because it means we need special tools and who knows what
libraries to deal with it.
you cant usefully read RDF/XML with just an XML parser anyway. It's quite
a lot of work to transform from the XML tree to the RDF graph.
But yes, Turtle support is less widespeard than RDF/XML, but there are
still Free/Open parsers for every language I can think of (C(++), perl,
java, python, ruby, javascript, etc.) Turtle isn't a standard, is aimed at much more
general problem areas,
and will just force people to read more docs and install more packages.
It might be a bit nicer for the person writing the plugin file, but that
isn't that much work. (Or does turtle include some essential feature?)
Turtle only missed being a standard months ago becasue of a wierd patent
problem with a well-known company that shall be nameless. It will be a
standard very soon.
Future changes should not have to break back-compatibility. We only need
to do it now to remove some old stuff that doesn't work very well.
- Steve
22 Apr
22 Apr
6:26 p.m.
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
*shrug* less of the evils. I'm kinda fond of Turtle, its not XML, but its
easy for humans to read and write.
It's not really DLL Hell, but yes, it needs thought.
- Steve
B) RDF syntax:
RDF/Turtle seems a lot more popular in these parts than
RDF/XML. We could mandate Turtle for all LADSPA metadata.
Personally I think it's ugly and strange and arbitrary and just weird
all around, but whatever. I don't really care. :) E) Bundles:
no-one screamed when I suggested it, but its a bit different to
LADSPA 1's /lib directory. Hosts would be required to allow the plugin
link to libraries in the bundle if they need to (this is why OPENSTEP did
it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which
is a bit more work, but makes moving plugins between machines easier. Oh,
and the plugins needs to have the path of its bundle passed to it when its
instantiated, which isn't in the API right now.
I like the bundle idea, but I thik we need to have a long hard think
about this WRT distro package management systems and FHS compliance. We
do need some way of allowing plugins to load libraries though, but is it
really necessary to do the DLL Hell thing to allow it?
6583
days inactive
6585
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
5 participants
participants (
participants (5)
)
-
Damon Chaplin -
Dave Robillard -
Lars Luthman -
Steve Harris -
thockin＠hockin.org
-
Damon Chaplin
-
Dave Robillard
-
Lars Luthman
-
Steve Harris
-
thockin＠hockin.org