23 Apr
2006
23 Apr
'06
6:30 a.m.
http://plugin.org.uk/ladspa2/
First of all, I realised I was being cheeky by adding a feature I wanted
(units), while refusing to consider anyone elses! So, I removed the units
property from the Amp plugin. I'm happy to consider it a testcase and I
will make a schema for it and start using it when/if LADSPA2 gets OKd by
the community.
I made 2 actual ABI changes:
The path of the directory/bundle is passed to instantiate(). This is
neccessary to make it actually useful. It could have been passed to other
methods, but that seemed most appropriate.
For some potential features, like Fons' polyphonic control ports, it's hard
for the plugin to detect wether the host is using the feature or not. I
added an array of URIs to instantiate() that lets the host tell the plugin
what hints etc. it supports. The plugin can then refuse to instantiate or
fall back if it doesn't like the featureset.
I also added some (silly) scale points to the Amp plugin, just to show how
it's done, and I added translations to some of the strings, to show how
that's done.
- Steve
23 Apr
23 Apr
1:31 p.m.
On Sun, 2006-04-23 at 09:29 +0100, Steve Harris wrote:
http://plugin.org.uk/ladspa2/
First of all, I realised I was being cheeky by adding a feature I wanted
(units), while refusing to consider anyone elses! So, I removed the units
property from the Amp plugin. I'm happy to consider it a testcase and I
will make a schema for it and start using it when/if LADSPA2 gets OKd by
the community.
I made 2 actual ABI changes:
The path of the directory/bundle is passed to instantiate(). This is
neccessary to make it actually useful. It could have been passed to other
methods, but that seemed most appropriate.
"The BundlePath parameter is a string of the path to the plugin's
.ladspa2 bundle directory, it SHOULD not include the trailing /."
Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it.
If it's just SHOULD there's not much point in wasting space mentioning
it.
Just an initial thought: how about adding a similar parameter for a
host-provided-things directory? This in combination with the
HostFeatures would allow a host to provide almost anything to plugins,
like a realtime memory allocator lib, some kind of shared memory scheme
for a GUI extension, etc. etc. Much more extensible without having to
break the ABI. Thoughts?
For some potential features, like Fons' polyphonic
control ports, it's hard
for the plugin to detect wether the host is using the feature or not. I
added an array of URIs to instantiate() that lets the host tell the plugin
what hints etc. it supports. The plugin can then refuse to instantiate or
fall back if it doesn't like the featureset.
I think this is an awesome idea, FWIW.
-DR-
4 p.m.
On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard wrote:
Perhaps, well it's not critical, appending /filename will always work
under Linux, its just a bit untidy. I used SHOULD incase the host has some
trouble removing it for some reason, but I can think why it would have.
So yes, MUST would be OK by me.
The path of
the directory/bundle is passed to instantiate(). This is
neccessary to make it actually useful. It could have been passed to other
methods, but that seemed most appropriate.
"The BundlePath parameter is a string of the path to the plugin's
.ladspa2 bundle directory, it SHOULD not include the trailing /."
Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it.
If it's just SHOULD there's not much point in wasting space mentioning
it. Just an initial thought: how about adding a similar
parameter for a
host-provided-things directory? This in combination with the
HostFeatures would allow a host to provide almost anything to plugins,
like a realtime memory allocator lib, some kind of shared memory scheme
for a GUI extension, etc. etc. Much more extensible without having to
break the ABI. Thoughts?
Hmmm... providing a lib that way is a bit late, setting LD_LIBRARY_PATH is
more convienient. Given that we dont have anything to put there currently
I don't feel really motivated.
- Steve
4:16 p.m.
On Sun, 2006-04-23 at 18:59 +0100, Steve Harris wrote:
So things like this could be provided just by setting a HostFeatures
flag that implies a certain library is linked and available for use?
That works.
(I'm not particularly attached to the idea either way, just a thought.
It allows the host to provide things to the plugin in general which
could be a good thing considering the change is so minimal).
-DR-
On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard
wrote:
Perhaps, well it's not critical, appending /filename will always work
under Linux, its just a bit untidy. I used SHOULD incase the host has some
trouble removing it for some reason, but I can think why it would have.
So yes, MUST would be OK by me.
Yeah, anything that lessens what plugins have to deal with is the Right
Thing.
The path
of the directory/bundle is passed to instantiate(). This is
neccessary to make it actually useful. It could have been passed to other
methods, but that seemed most appropriate.
"The BundlePath parameter is a string of the path to the plugin's
.ladspa2 bundle directory, it SHOULD not include the trailing /."
Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it.
If it's just SHOULD there's not much point in wasting space mentioning
it. Just an
initial thought: how about adding a similar parameter for a
host-provided-things directory? This in combination with the
HostFeatures would allow a host to provide almost anything to plugins,
like a realtime memory allocator lib, some kind of shared memory scheme
for a GUI extension, etc. etc. Much more extensible without having to
break the ABI. Thoughts?
Hmmm... providing a lib that way is a bit late, setting LD_LIBRARY_PATH is
more convienient. Given that we dont have anything to put there currently
I don't feel really motivated.
6818
days inactive
6818
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Dave Robillard -
Steve Harris