> 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 outpu
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 fil
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 shoul
On Wed, 2006-04-26 at 07:23 +0100, Steve Harris wrote:
> Several people have suggested that LADSPA is not a great name for what we
> are calling LADSPA 2. Reasons for this include:
>
> The L, it's not really linux specific, and though /we/ know that its the L
> of LAD, its not obvious to peopl
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 st
On Tue, 25 Apr 2006 22:55:55 -0400
Paul Davis <[EMAIL PROTECTED]> 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, b
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
> 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 ma
On Wed, Apr 26, 2006 at 11:10:02 +0300, Sampo Savolainen wrote:
> Quoting Steve Harris <[EMAIL PROTECTED]>:
>
> > My suggestion is that we ressurect the XAP name
> > (http://www.google.com/search?q=lad+xap)
> > It stood for Xap Audio Plugin IIRC.
> >
> > Pros: it's short*, relatively unused** and
Quoting Steve Harris <[EMAIL PROTECTED]>:
> My suggestion is that we ressurect the XAP name
> (http://www.google.com/search?q=lad+xap)
> It stood for Xap Audio Plugin IIRC.
>
> Pros: it's short*, relatively unused** and pronouncable***
More pros: we would have a VST -alike logo already! (looking
Several people have suggested that LADSPA is not a great name for what we
are calling LADSPA 2. Reasons for this include:
The L, it's not really linux specific, and though /we/ know that its the L
of LAD, its not obvious to people outside.
The S, it ain't really going to be simple. For some
On Wed, Apr 26, 2006 at 12:33:50 +0200, Leonard paniq Ritter wrote:
> On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
> > 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.
>
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:
> > On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote:
> > > If you think the header should be all the documentation required, then
> > > you completely Don't Get It on
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 ho
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:
> > 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 i
On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote:
> On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote:
> > 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 a
On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote:
> 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
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
On Wed, 2006-04-26 at 00:33 +0200, Leonard "paniq" Ritter wrote:
> On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
> > 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.
>
>
> 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
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
> 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 t
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:
> > 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 t
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
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 sin
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. whe
On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote:
> > 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 betwee
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 o
> 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
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-in
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 a
On Mon, Apr 24, 2006 at 04:12:11 -0400, Jesse Chappell wrote:
> On 4/24/06, tom christie <[EMAIL PROTECTED]> 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
>
On Apr 24, 2006, at 7:53 PM, Hans Fugal wrote:
On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote:
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
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:
> > 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 da
On 4/24/06, tom christie <[EMAIL PROTECTED]> 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 l
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
On Mon, Apr 24, 2006 at 08:58:07 -0400, Dave Robillard wrote:
> > 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
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:
> > 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 dat
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:
> > 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 j
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:
> > 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
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
On Sun, 2006-04-23 at 16:26 -0400, Dave Robillard wrote:
> On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote:
> > 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:
> > > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave R
On Sun, Apr 23, 2006 at 04:26:03 -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.
> >
> > I don't see how it affects the usecase. You /always/ need to read at least
On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote:
> 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:
> > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote:
> > > > But anyway, why can't it go in the code?
On Sun, Apr 23, 2006 at 05:04:18PM +0200, Florian Schmidt wrote:
> On Sun, 23 Apr 2006 13:39:52 +0100
> Steve Harris <[EMAIL PROTECTED]> wrote:
>
> > 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
> > > t
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:
> > 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
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:
> > 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
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. W
On Sun, 2006-04-23 at 18:59 +0100, Steve Harris wrote:
> On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard wrote:
> > > 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 s
On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard wrote:
> > 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 str
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
On Sun, 2006-04-23 at 07:53 +0100, Steve Harris wrote:
> On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote:
> > > > 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.
On Sun, 2006-04-23 at 17:04 +0200, Florian Schmidt wrote:
> On Sun, 23 Apr 2006 13:39:52 +0100
> Steve Harris <[EMAIL PROTECTED]> wrote:
>
> > 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
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <[EMAIL PROTECTED]> wrote:
> 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
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 () fun
On Sat, 22 Apr 2006 10:53:58 +0100
Steve Harris <[EMAIL PROTECTED]> 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 plu
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
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:
> > 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
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 somet
On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote:
> > > 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
> > > identifi
On Sun, 2006-04-23 at 01:10 +0200, Luis Garrido wrote:
> > 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 inter
> 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 modu
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
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 th
On Sun, 2006-04-23 at 03:56 +0700, Patrick Shirkey wrote:
> Hi,
>
> Thanks for the feedback so far.
>
> Here are the main concerns for me at this point:
>
> - Can we force a central repository on developers. Would developers
> support a Firefox style plugin portal? The site will fail if it requ
Hi,
Thanks for the feedback so far.
Here are the main concerns for me at this point:
- Can we force a central repository on developers. Would developers
support a Firefox style plugin portal? The site will fail if it requires
manual updating by the site maintainer. The onus would have to be o
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:
> > 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
On Sat, 2006-04-22 at 21:10 +0100, Steve Harris wrote:
> On Sat, Apr 22, 2006 at 02:47:33PM -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 t
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 mea
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
> > 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 whate
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:
> > 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 dir
On Sat, Apr 22, 2006 at 12:34:04PM -0700, [EMAIL PROTECTED] 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 bec
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:
> > 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
On Sat, Apr 22, 2006 at 02:47:33PM -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 think the regexp you mentioned there is fine, though I think we sh
On Sat, 2006-04-22 at 12:34 -0700, [EMAIL PROTECTED] wrote:
> On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote:
> > On Sat, 2006-04-22 at 11:56 -0700, [EMAIL PROTECTED] wrote:
> > > On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
> > > > > B) RDF syntax: RDF/Turtle see
On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote:
> On Sat, 2006-04-22 at 11:56 -0700, [EMAIL PROTECTED] wrote:
> > On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
> > > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than
> > > > RDF/XML. We could
On Sat, 2006-04-22 at 11:56 -0700, [EMAIL PROTECTED] wrote:
> On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
> > > 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
On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote:
> > 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 whate
On Sat, 2006-04-22 at 19:20 +0100, Steve Harris wrote:
> On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave Robillard wrote:
> > > 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
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 ma
On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave Robillard wrote:
> > 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
> > w
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 it
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
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:
> > 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:
> > > > Referencing:
> > > > There needs to be a
Only really a toy, but:
Aparently, ages ago I made an online LADSPA 2 RDF metadata editor:
http://plugin.org.uk/md-creator/
(http://www.music.columbia.edu/pipermail/linux-audio-dev/2004-October/010011.html)
It's very similar to the stuff I knocked up last night, though its not
exactly the same (t
On Sat, Apr 22, 2006 at 12:19:42PM +0200, Lars Luthman wrote:
> > 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 y
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:
> > On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote:
> > > Referencing:
> > > There needs to be a safe way to reference plugins and their ports.
> > > Portnames m
On Sat, Apr 22, 2006 at 03:14:28PM +0200, Thorsten Wilms wrote:
> > 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.
I dont see enough value to justify making p
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:
> > 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,
On Sat, Apr 22, 2006 at 11:46:28AM -0500, Jack O'Quin wrote:
> > 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.
The XML+C thing
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:
> > 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.
>
On 4/22/06, Lars Luthman <[EMAIL PROTECTED]> wrote:
> 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,
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:
> > 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.
> >
> >
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
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 t
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,
On Sat, Apr 22, 2006 at 02:44:22PM +0300, Sampo Savolainen wrote:
> > 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.
Yes, it's nice to write, unlike RDF/XML, which is a PITA. There aren't
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
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
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 instanc
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 sin
101 - 200 of 884 matches
Mail list logo
