On Wed, May 26, 2004 at 08:22:17 -0500, Jack O'Quin wrote:
> Steve Harris <[EMAIL PROTECTED]> writes:
>
> > On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze wrote:
> > > other than that, i'm eager to know how plugin ports are to be
> > > referenced in the metadata file. by ID or numerical index?
Steve Harris <[EMAIL PROTECTED]> writes:
> On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze wrote:
> > other than that, i'm eager to know how plugin ports are to be
> > referenced in the metadata file. by ID or numerical index? if by ID,
> > is it the full path to the port: "/SupaPlug/LFO 1/Freq
On tis, 2004-05-18 at 10:36, Alfons Adriaensen wrote:
> On Mon, May 17, 2004 at 10:04:22PM +0100, Steve Harris wrote:
> > On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard wrote:
>
> > > How about scheme?
> > >
> > > Hey, it's the official scripting language of the GNU system.. :)
>
> Indee
On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze wrote:
> other than that, i'm eager to know how plugin ports are to be
> referenced in the metadata file. by ID or numerical index? if by ID,
> is it the full path to the port: "/SupaPlug/LFO 1/Frequency", or
> something more concise? (i'm for a fu
[Steve Harris]
>On Tue, May 18, 2004 at 10:29:56 -0500, Jack O'Quin wrote:
>> I've been reading up on Steve's N-triples suggestion...
[...]
>> (1) It is a W3C standard.
>> (2) It is mathematically deep and well thought out.
>> (3) It is specifically intended for adding property lists to the w
>> >> This is not right. A scripting language (well, nay suitably expressive
>> >> syntax for that matter) can express metadata structures, but thats only a
>> >> partial solution.
>> >
>> >What's missing ?
>>
>> fons, do you know what steve actually gets paid for? :))
>
>No, and whatever it is do
On Wed, May 19, 2004 at 03:38:09 +0200, Alfons Adriaensen wrote:
> As far as I can see, everything that can be expressed by an RDF graph or
> a set of triplets or the eqeuivalent XML can be equally well expressed by
> nested property lists in LISP or even nested structs in C/C++.
Pretty much, yes
On Wed, May 19, 2004 at 03:12:32 +0200, Alfons Adriaensen wrote:
> > fons, do you know what steve actually gets paid for? :))
>
> No, and whatever it is does not IMHO imply that no questions
> can be asked.
I couldn't agree more.
- Steve
On Wed, May 19, 2004 at 12:18:25PM +0100, Steve Harris wrote:
> >What's missing ?
>
> Semantics. You can define a single layer metadata system with virtually no
> (machine) semnatics, eg.
>
> hasTitle: "my plugin"
> hasPortCount: "3"
> ...
> but you quickly run into problems when trying to encode
On Wed, May 19, 2004 at 06:57:27AM -0400, Paul Davis wrote:
> >On Wed, May 19, 2004 at 11:24:36AM +0100, Steve Harris wrote:
> >> On Tue, May 18, 2004 at 10:36:03 +0200, Alfons Adriaensen wrote:
> >> > > We don't have a scripting language problem, we have a metadata problem.
> >> > > Square peg, ro
>What's missing ?
Semantics. You can define a single layer metadata system with virtually no
(machine) semnatics, eg.
hasTitle: "my plugin"
hasPortCount: "3"
...
but you quickly run into problems when trying to encode anything
interesting, like port 3 is a "contol in port" with a lower range of
>On Wed, May 19, 2004 at 11:24:36AM +0100, Steve Harris wrote:
>> On Tue, May 18, 2004 at 10:36:03 +0200, Alfons Adriaensen wrote:
>> > > We don't have a scripting language problem, we have a metadata problem.
>> > > Square peg, round hole.
>> >
>> > Scripting will handle metadata without any prob
On Wed, May 19, 2004 at 11:24:36AM +0100, Steve Harris wrote:
> On Tue, May 18, 2004 at 10:36:03 +0200, Alfons Adriaensen wrote:
> > > We don't have a scripting language problem, we have a metadata problem.
> > > Square peg, round hole.
> >
> > Scripting will handle metadata without any problem.
On Tue, May 18, 2004 at 10:29:56 -0500, Jack O'Quin wrote:
> I've been reading up on Steve's N-triples suggestion...
>
> > NTriples is defined in
> > http://www.w3.org/TR/rdf-testcases/#ntriples
>
> > General RDF stuff is at
> > http://www.w3.org/RDF/
>
> This approach has considerable merit...
On Tue, May 18, 2004 at 10:36:03 +0200, Alfons Adriaensen wrote:
> > We don't have a scripting language problem, we have a metadata problem.
> > Square peg, round hole.
>
> Scripting will handle metadata without any problem.
> Universal peg, hole shape doesn't matter.
This is not right. A script
Dave Robillard <[EMAIL PROTECTED]> writes:
> So, ++xml, because reinventing the wheel is stupid. While I understand
> the kneejerk anti-xml reaction (damn buzzwords) it just seems like the
> right tool for the job...
I've been reading up on Steve's N-triples suggestion...
> NTriples is defined
On Mon, 2004-05-17 at 17:04, Steve Harris wrote:
> On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard wrote:
> > > ISTR someone at LADconf 2 also proposed to use LISP for configuration
> > > and I kind of liked the idea.
> >
> > How about scheme?
> >
> > Hey, it's the official scripting langu
On Mon, May 17, 2004 at 10:04:22PM +0100, Steve Harris wrote:
> On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard wrote:
> > How about scheme?
> >
> > Hey, it's the official scripting language of the GNU system.. :)
Indeed it is, and a good choice IMHO.
> We don't have a scripting languag
On Mon, May 17, 2004 at 08:18:46PM +0200, Uwe Koloska wrote:
> Jack O'Quin wrote:
> >Fons Adriaensen <[EMAIL PROTECTED]> writes:
> >
> >>LISP is quite nice actually, but you'd need a complete LISP engine to
> >>read it...
> >
> >That wasn't really a serious suggestion. The libguile.so.12.3.0 file
On Mon, May 17, 2004 at 02:55:16 -0400, Dave Robillard wrote:
> > ISTR someone at LADconf 2 also proposed to use LISP for configuration
> > and I kind of liked the idea.
>
> How about scheme?
>
> Hey, it's the official scripting language of the GNU system.. :)
We don't have a scripting language
On Mon, 2004-05-17 at 04:36, Alfons Adriaensen wrote:
> On Mon, May 17, 2004 at 09:26:31AM +0200, Joern Nettingsmeier wrote:
>
> > >//addport
> >
> >
> > see how the magic of angle brackets has begun to work on fons
> > already? there is hope ;-)
>
> Arrrggghh ! My re
On Sun, 2004-05-16 at 19:59, Taybin Rutkin wrote:
> On Sat, 2004-05-15 at 03:23, Joern Nettingsmeier wrote:
> > sure, libxml2 is huge, but almost everybody will have it in memory
> > anyway, since it's used by other programs.
> >
> > imho, xml *is* very human-readable if the DTD is sane and the o
Jack O'Quin wrote:
That [Lisp] wasn't really a serious suggestion.
Just found this nice and small lisp. It is used in festival speech
synthesis system and named SIOD (Scheme in one defun)
http://www.cs.indiana.edu/scheme-repository/imp/siod.html
Uwe
--
voiceINTERconnect www.voiceinterconnect.d
Jack O'Quin wrote:
Fons Adriaensen <[EMAIL PROTECTED]> writes:
>
LISP is quite nice actually, but you'd need a complete LISP engine to
read it...
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is over half a meg. Would all the LADSPA hosts be
willing to add tha
On Fri, 2004-05-14 at 20:50, jaromil wrote:
> what do you say guys, on the long term it's really bad to have this
> header-oriented spec? or you're doing the change just now that everybody
> joined the train, wouldn't have been a good choice since the beginning? ;>
The main thing that came out of
On Mon, May 17, 2004 at 10:36:27AM +0200, Alfons Adriaensen wrote:
> On Mon, May 17, 2004 at 09:26:31AM +0200, Joern Nettingsmeier wrote:
> > >//addport
> >
> > see how the magic of angle brackets has begun to work on fons
> > already? there is hope ;-)
> Arrrggghh ! My
On Mon, May 17, 2004 at 10:36:27 +0200, Alfons Adriaensen wrote:
> Seriously now, having to choose between LISP or XML, I'd be 100%
> on the LISP side. For those who really want XML, it should be
> possible to come up with a LISP function that will just generate
> it from the LISP description - th
On Mon, May 17, 2004 at 09:26:31AM +0200, Joern Nettingsmeier wrote:
> >//addport
>
>
> see how the magic of angle brackets has begun to work on fons
> already? there is hope ;-)
Arrrggghh ! My reputation is going down the drain !
Seriously now, having to choose betw
Fons Adriaensen wrote:
For this application, I'd very much like to see something based on OSC,
or a subset of it. After all, we're dealing with sound plugins here.
For example:
( stands for the unique name of a plugin)
//addport
see how the magic of angle brackets has begun t
On Sat, 2004-05-15 at 03:23, Joern Nettingsmeier wrote:
> sure, libxml2 is huge, but almost everybody will have it in memory
> anyway, since it's used by other programs.
>
> imho, xml *is* very human-readable if the DTD is sane and the output
> is pretty-printed. and it's already defined, all th
Jack O'Quin wrote:
Fons Adriaensen <[EMAIL PROTECTED]> writes:
On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
>>
LISP is quite nice actually, but you'd need a complete LISP engine to
read it...
That wasn't really a serious suggestion. The libguile.so.12.3.0 file
on my system is ov
On Sun, May 16, 2004 at 09:14:46AM +0200, Marcus Andersson wrote:
> > >This also means that it is illegal to include 0 in the parameter range.
> >
> >In that case you can use f(x) = x*a^x, with a = f(1).
> >
>
> How do I invert this function? I am stuck.
You need the inverse only to set the slid
On Sun, May 16, 2004 at 02:15:11AM +0100, Steve Harris wrote:
> On Sun, May 16, 2004 at 02:43:17 +0200, Fons Adriaensen wrote:
> > Just use a command that will add the necessary information to a database
> > maintained by the host. Searching for a plugin and actually hosting it
> > are two separat
Fons Adriaensen wrote:
On Sat, May 15, 2004 at 07:10:30AM +0200, Marcus Andersson wrote:
Interesting interpretation. This means that the mapping between the
slider and the parameter will be
f(x) = k*a^x
with k=f(0) and a = f(1) if the slider goes form 0 to 1.
You probably meant a = f(1)/f
On Sun, May 16, 2004 at 02:43:17 +0200, Fons Adriaensen wrote:
> > > A. a description of a plugin's interface,
> > > B. a set of commands that make a host accomodate the plugin ?
> >
> > It depends on the task the app is trying to achieve, if its trying to find
> > a plugin thats a "compressor"
On Sat, May 15, 2004 at 09:05:57AM +0100, Steve Harris wrote:
> On Sat, May 15, 2004 at 01:12:13 +0200, Fons Adriaensen wrote:
> > On Fri, May 14, 2004 at 10:50:31PM +0100, Steve Harris wrote:
> >
> > > I dont really see the avantage of this - control and description are
> > > seperate tasks, and
On Sat, May 15, 2004 at 07:10:30AM +0200, Marcus Andersson wrote:
> Interesting interpretation. This means that the mapping between the
> slider and the parameter will be
>
> f(x) = k*a^x
>
> with k=f(0) and a = f(1) if the slider goes form 0 to 1.
You probably meant a = f(1)/f(0).
> This als
On Sat, May 15, 2004 at 10:04:24 +0100, Mike Rawes wrote:
> > Actually I'd like to get rid if the UID (its useless for generated
> > plugins and has a significant adminstrative overhead) and just roll it
> > into the label with a URI scheme.
> >
> > that way everyone can administer thier own uniqu
On Sat, 15 May 2004 11:46:47 +0200
Marcus Andersson <[EMAIL PROTECTED]> wrote:
> Mike Rawes wrote:
>
> > You're right - there's an asymptote at x=0 - there's no correct way
> > of
> >
> >dealing with it. What I've done in the past is do linear conversion
> >near 0:
> >
> >to linear:
> >value > e
Mike Rawes wrote:
You're right - there's an asymptote at x=0 - there's no correct way of
dealing with it. What I've done in the past is do linear conversion near
0:
to linear:
value > e : log(value)
< -e : -log(-value)
: value / e
to logarithmic
value > 1 : exp(value)
< -1 :
On Fri, 14 May 2004 20:15:39 +0100
Steve Harris <[EMAIL PROTECTED]> wrote:
> On Fri, May 14, 2004 at 05:08:53 +0100, Mike Rawes wrote:
> > Minor nitpick regarding what is carried over as metadata from 1.x:
> > Can we get rid of the label? - I never did see the use for it. The
> > ID is sufficient
On Sat, 15 May 2004 07:10:30 +0200
Marcus Andersson <[EMAIL PROTECTED]> wrote:
> Fons Adriaensen wrote:
>
> >On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus Andersson wrote:
> >
> >
> >>Alfons Adriaensen wrote:
> >>
> >>
> >>
> >>>Another point. I've defended the adoption of simple integer
On Sat, May 15, 2004 at 12:40:58 +0200, Fons Adriaensen wrote:
> There's maybe a 'political' motivation behind my point of vieuw: forcing
> application writers to use a library to access an otherwise undocumented
> interface reminds me too much of some commercial practices that I dislike.
> I reall
On Sat, May 15, 2004 at 01:12:13 +0200, Fons Adriaensen wrote:
> On Fri, May 14, 2004 at 10:50:31PM +0100, Steve Harris wrote:
>
> > I dont really see the avantage of this - control and description are
> > seperate tasks, and not even closely related.
>
> Very closely related if you consider that
Fons Adriaensen wrote:
On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus Andersson wrote:
Alfons Adriaensen wrote:
Another point. I've defended the adoption of simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the
On Fri, May 14, 2004 at 10:50:31PM +0100, Steve Harris wrote:
> I dont really see the avantage of this - control and description are
> seperate tasks, and not even closely related.
Very closely related if you consider that the ultimate purpose of a
description is to control something. Why should
On Fri, May 14, 2004 at 02:21:46PM -0400, Paul Davis wrote:
> >> stable library interface. I don't know anyone now who *ever* writes X
> >> protocol code, and I've never met anyone (except a few people I once
> >> knew who worked on a commercial X server, and even that was more than
> >> 15 years a
On Fri, May 14, 2004 at 02:48:18 -0500, Jack O'Quin wrote:
> Steve Harris <[EMAIL PROTECTED]> writes:
>
> > *cough* its not my scheme, its a W3C standard.
>
> That's nice. How about a pointer to where it's defined?
NTriples is defined in
http://www.w3.org/TR/rdf-testcases/#ntriples
General RDF
On Fri, May 14, 2004 at 02:46:19 -0500, Jack O'Quin wrote:
> Libxml2 is even bigger, almost a meg. I wonder how many LADSPA hosts
> already use it for some other reason? I see that ardour, jamin and
> hydrogen do...
I do really like XML - it's probably saved me more programming time than
another
On Fri, May 14, 2004 at 11:28:42 +0200, Fons Adriaensen wrote:
> For example:
>
> ( stands for the unique name of a plugin)
>
> //addport
> //port//range 0 10
> //port//default 5
> //port//unit octaves
>
> This is a trivial example of course, for a real format we'll have to
> think ab
On Fri, May 14, 2004 at 04:03:55PM -0400, Dave Robillard wrote:
> On Fri, 2004-05-14 at 14:09, Fons Adriaensen wrote:
> > > I suppose the question is _why_ would you "fiercely resist" this good
> > > design practise?
> >
> > System interfaces are often defined by an API (and even that is
> > quest
On Fri, May 14, 2004 at 08:10:32PM +0100, Steve Harris wrote:
> On Fri, May 14, 2004 at 07:07:59 +0200, Fons Adriaensen wrote:
> > On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
> > > >I don't mind *IFF* the metadata file has a simple, human readable
> > > >syntax (no XML please) that
On Fri, 2004-05-14 at 14:09, Fons Adriaensen wrote:
> > I suppose the question is _why_ would you "fiercely resist" this good
> > design practise?
>
> System interfaces are often defined by an API (and even that is
> questionable since it imposes a language), but file formats and
> network protoc
jaromil <[EMAIL PROTECTED]> writes:
> would have been a good choice since the beginning, to have it as a lib?
Maybe so. But, it's important to keep this in perspective.
LADSPA has been a great success, and simplicity was one of the main
reasons. Now that the concept is proven, people are willi
Fons Adriaensen <[EMAIL PROTECTED]> writes:
> On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
>
> > I'm having trouble figuring out Fons' original point here, though I'm
> > sure he has one. Simple and human readable are worthwhile goals, but
> > hard to reconcile.
>
> Strange.. I'
Steve Harris <[EMAIL PROTECTED]> writes:
> *cough* its not my scheme, its a W3C standard.
That's nice. How about a pointer to where it's defined?
--
joq
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
re,
On Fri, May 14, 2004 at 08:17:30PM +0100, Steve Harris wrote:
> On Fri, May 14, 2004 at 05:45:58 +0100, Mike Rawes wrote:
> > > Will it be possible for the same plugin to implement both v1 and
> > > v2?
> > >
> > > (I would have thought that was
On Fri, May 14, 2004 at 05:45:58 +0100, Mike Rawes wrote:
> > Will it be possible for the same plugin to implement both v1 and v2?
> >
> > (I would have thought that was probably a necessity, but then I don't write
> > plugins.)
>
> Ooh. That's a good point...
>
> I've written a few plugins, an
On Fri, May 14, 2004 at 05:08:53 +0100, Mike Rawes wrote:
> Minor nitpick regarding what is carried over as metadata from 1.x: Can we get
> rid of the label? - I never did see the use for it. The ID is sufficient for
> identifying plugins, and the name (as metadata) for presenting in a UI.
Actuall
On Fri, May 14, 2004 at 12:45:34 -0400, Paul Davis wrote:
> >Why rule out XML? It's one of the few widely-used language groups
> >that actually sorta meets both those requirements (*fairly* simple and
> >*somewhat* human-readable). ;-)
>
> Reactions to XML can be as strong as your feelings about
On Fri, May 14, 2004 at 07:07:59 +0200, Fons Adriaensen wrote:
> On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
> > >I don't mind *IFF* the metadata file has a simple, human readable
> > >syntax (no XML please) that can be parsed line by line.
> >
> > no XML, and yes, parsable line by
>> stable library interface. I don't know anyone now who *ever* writes X
>> protocol code, and I've never met anyone (except a few people I once
>> knew who worked on a commercial X server, and even that was more than
>> 15 years ago).
>
>This is irrelevant. Xrm has nothing to do with the X protoca
On Fri, May 14, 2004 at 01:19:11PM -0400, Paul Davis wrote:
> >On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
> >> >I don't mind *IFF* the metadata file has a simple, human readable
> >> >syntax (no XML please) that can be parsed line by line.
> >>
> >> no XML, and yes, parsable line
On Fri, May 14, 2004 at 01:15:37PM -0400, Dave Robillard wrote:
> On Fri, 2004-05-14 at 13:07, Fons Adriaensen wrote:
> > > no XML, and yes, parsable line by line, and yes, human readable. *but*
> > > the plan should be to use the supplied library to get and set
> > > values. nobody should be doing
On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
> I'm having trouble figuring out Fons' original point here, though I'm
> sure he has one. Simple and human readable are worthwhile goals, but
> hard to reconcile.
Strange.. I'd think these two would go hand in hand...
Whit 'simple' a
>On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
>> >I don't mind *IFF* the metadata file has a simple, human readable
>> >syntax (no XML please) that can be parsed line by line.
>>
>> no XML, and yes, parsable line by line, and yes, human readable. *but*
>> the plan should be to use t
On Fri, 2004-05-14 at 13:07, Fons Adriaensen wrote:
> > no XML, and yes, parsable line by line, and yes, human readable. *but*
> > the plan should be to use the supplied library to get and set
> > values. nobody should be doing it themselves otherwise we end up with
> > an almighty mess.
>
> ??? N
--- Chris Cannam <[EMAIL PROTECTED]> wrote: > On Friday 14 May 2004
15:33, [EMAIL PROTECTED] wrote:
> > we should make sure that the v2plugin metadata contains a hint which
> > v1 plugin is made obsolete by this v2plugin
>
> Will it be possible for the same plugin to implement both v1 and v2?
>
On Fri, May 14, 2004 at 04:53:53PM +0100, Steve Harris wrote:
> Yes, but xrm misses most of the desirable feaures of metadata languages
> (agreed semantics, extensibility and so on). We could just use the syntax,
> but its pretty complex for non-X11 apps that want to parse it.
Actually, it's very
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul Davis wrote:
> >I don't mind *IFF* the metadata file has a simple, human readable
> >syntax (no XML please) that can be parsed line by line.
>
> no XML, and yes, parsable line by line, and yes, human readable. *but*
> the plan should be to use the sup
>Why rule out XML? It's one of the few widely-used language groups
>that actually sorta meets both those requirements (*fairly* simple and
>*somewhat* human-readable). ;-)
Reactions to XML can be as strong as your feelings about C++ :)
Personally, I am fan of both of them, but I don't think tha
On Fri, May 14, 2004 at 05:55:07PM +0200, Marcus Andersson wrote:
> Alfons Adriaensen wrote:
>
> >Another point. I've defended the adoption of simple integer enumerations
> >
> >(corresponding to a C switch) using the argument that it is the single
> >missing essential feature in the port informat
Steve Harris <[EMAIL PROTECTED]> writes:
> On Fri, May 14, 2004 at 04:50:31 +0200, Alfons Adriaensen wrote:
> > I don't mind *IFF* the metadata file has a simple, human readable
> > syntax (no XML please) that can be parsed line by line.
>
> Human readable and line by line parsable are pretty muc
--- Paul Davis <[EMAIL PROTECTED]> wrote:
> well, it appears that there is little to no response to the proposal
> from the LADSPA meeting at ZKM. just to be sure that the silence is an
> accurate reflection of what people think, i want to take a harsh
> stance on the proposal and see if it gener
>I don't mind *IFF* the metadata file has a simple, human readable
>syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themsel
Alfons Adriaensen wrote:
Another point. I've defended the adoption of simple integer enumerations
(corresponding to a C switch) using the argument that it is the single
missing essential feature in the port information. At the Karlsruhe BOF
it was said that this is not true, as the LOGARITHMIC hi
On Fri, May 14, 2004 at 04:50:31 +0200, Alfons Adriaensen wrote:
> I don't mind *IFF* the metadata file has a simple, human readable
> syntax (no XML please) that can be parsed line by line.
Human readable and line by line parsable are pretty much mutually
exclusive - try expressing any complex st
On Friday 14 May 2004 15:33, [EMAIL PROTECTED] wrote:
> we should make sure that the v2plugin metadata contains a hint which
> v1 plugin is made obsolete by this v2plugin
Will it be possible for the same plugin to implement both v1 and v2?
(I would have thought that was probably a necessity, but
On Fri, May 14, 2004 at 08:36:24AM -0400, Paul Davis wrote:
> well, it appears that there is little to no response to the proposal
> from the LADSPA meeting at ZKM. just to be sure that the silence is an
> accurate reflection of what people think, i want to take a harsh
> stance on the proposal and
On Fri, May 14, 2004 at 08:36:24AM -0400, Paul Davis wrote:
> well, it appears that there is little to no response to the proposal
> from the LADSPA meeting at ZKM. just to be sure that the silence is an
> accurate reflection of what people think, i want to take a harsh
> stance on the proposal an
Paul Davis <[EMAIL PROTECTED]> writes:
> personally, i think its worth going through this pain. we will end up
> with a system in which new LADSPA extensions do not require changes to
> the API, which is a great thing. but it will be painful to get there,
> and i want to check that people don't mi
well, it appears that there is little to no response to the proposal
from the LADSPA meeting at ZKM. just to be sure that the silence is an
accurate reflection of what people think, i want to take a harsh
stance on the proposal and see if it generates any response...
if we follow through with the
04/01/03 19:07, Steve Harris wrote:
> On Sat, Jan 04, 2003 at 02:51:13 +0100, Pascal Haakmat wrote:
> > My proposal loses us nothing: because plugin authors need to use the
> > PortName field to describe port values _anyway_ (to aid non
> > RDF-capable hosts) it makes sense to agree on a best way
On Sat, Jan 04, 2003 at 02:51:13 +0100, Pascal Haakmat wrote:
> But it is not solving the problems:
>
> 1. The PortName still needs to describe the possible values for non
> RDF-capable hosts.
Any host that cares to that extent would also benefit from the other
features of RDF.
> 2. The host st
On Sat, Jan 04, 2003 at 01:31:21 +, Bob Ham wrote:
> While we're on that, I'm adding lrdf support to jack rack and I'm
> wondering where the ladspa descriptions should be gotten from. The
> showtaxonomy uses "file:ladspa.rdfs" and "file:example.rdf" URIs. How
> should a proper host be contruc
04/01/03 12:23, Steve Harris wrote:
> On Sat, Jan 04, 2003 at 09:51:20 +0100, Pascal Haakmat wrote:
> > Hi all,
> >
> > It appears as though LADSPA at the moment lacks a means to provide
> > names for control values (this topic has probably crossed the list
> > before so I'll try to keep it short
On Sat, 2003-01-04 at 12:23, Steve Harris wrote:
> However no hosts can read RDF yet. http://plugin.org.uk/lrdf/ for code.
> It can also do a number of other metadata tasks incuding categorisation.
> I think its better to solve all these problems at once.
While we're on that, I'm adding lrdf supp
On Sat, Jan 04, 2003 at 09:51:20 +0100, Pascal Haakmat wrote:
> Hi all,
>
> It appears as though LADSPA at the moment lacks a means to provide
> names for control values (this topic has probably crossed the list
> before so I'll try to keep it short).
>
> The common solution for this problem (e.g
On Sat, 2003-01-04 at 08:51, Pascal Haakmat wrote:
> Therefore (if such a thing does not already exist) I propose to extend
> the LADSPA specification with a convention: if a PortName matches the
> following regular expression: .+ \((\d+=.+,)*(\d+=.+)+\) (in words:
> any sequence of characters foll
Hi all,
It appears as though LADSPA at the moment lacks a means to provide
names for control values (this topic has probably crossed the list
before so I'll try to keep it short).
The common solution for this problem (e.g. as used in Steve Harris'
plugin collection) is to use an integer control p
90 matches
Mail list logo
