Hi Steve,
> On Thu, May 23, 2002 at 10:01:35 +0200, Stefan Kost wrote:
>
>>>But maybe it's too difficult for people who do not happen to be
>>>familiar with it anyway. Nevertheless I bought a book on XML and RDF today
>>>and I'll have a look at RDF parsing.
>>
>>check out libgnurdf : http://www.g
On Thu, May 23, 2002 at 10:01:35 +0200, Stefan Kost wrote:
> > But maybe it's too difficult for people who do not happen to be
> > familiar with it anyway. Nevertheless I bought a book on XML and RDF today
> > and I'll have a look at RDF parsing.
>
> check out libgnurdf : http://www.gnupdate.org/
Hi,
>
>>On Wed, May 15, 2002 at 11:21:55 +0200, Dr. Matthias Nagorni wrote:
>>
>>>These things could be included in an additional XML file (although 1)
>>>will be part of LADSPA 1.1 anyway). Steve already supplies XML files with his
>>>plugins. So one would only have to agree upon a standard for
Hi,
>
>
>
>>I don't want to force the issue too much. I use RDF a lot in my job, so
>>I'm comfortable with it, and know why its useful.
>
> But maybe it's too difficult for people who do not happen to be
> familiar with it anyway. Nevertheless I bought a book on XML and RDF today
> and I'
> If anyone is interested I'l write the actualy RDF equivalent of what I've
> written obove.
On Thu, May 16, 2002 at 03:09:20 +0200, Dr. Matthias Nagorni wrote:
> On Thu, 16 May 2002, Steve Harris wrote:
>
> > Fair enough, you could do this in XML too, but in RDF the description is
> > exstensible without requiring a new DTD and other RDF files can extend the
> > description without conf
On Thu, 16 May 2002, Steve Harris wrote:
> Fair enough, you could do this in XML too, but in RDF the description is
> exstensible without requiring a new DTD and other RDF files can extend the
> description without conflict. eg. you can can add dulin core metadata
Yes, but isn't a somewhat constr
On Thu, 16 May 2002, Steve Harris wrote:
> If anyone is interested I'l write the actualy RDF equivalent of what I've
> written obove.
I'm curious.
Taybin
On Thu, May 16, 2002 at 11:47:59 +0100, Steve Harris wrote:
> [more in this in a mo, somone needs my laptop]
For example you can easily say in RDF:
there is a plugin with UID 2
has control port 1
has control port 2
has control port 3
has audio port 1
has audio port 2
control in p
On Thu, May 16, 2002 at 11:20:06 +0200, Dr. Matthias Nagorni wrote:
> > > plugins. So one would only have to agree upon a standard for these XML
> > > files, right ?
> >
> > Right. I nominate RDF.
> What I can see from http://www.w3.org/TR/2002/WD-rdf-primer-20020319
> is that I would not mind hav
On Wed, 15 May 2002, Steve Harris wrote:
> On Wed, May 15, 2002 at 11:21:55 +0200, Dr. Matthias Nagorni wrote:
> > These things could be included in an additional XML file (although 1)
> > will be part of LADSPA 1.1 anyway). Steve already supplies XML files with his
> > plugins. So one would only
Steve Harris wrote:
> I guess it could stand for eXtended Linux Plugins, but it may as well be
> eXtra Large Pants ;)
This is how myths are born, you realise?
And surely that should be _eXtensible_.
R
--
http://www.all-day-breakfast.com/rosegarden
http://www.bownie.com
On Wed, May 15, 2002 at 11:21:55 +0200, Dr. Matthias Nagorni wrote:
> These things could be included in an additional XML file (although 1)
> will be part of LADSPA 1.1 anyway). Steve already supplies XML files with his
> plugins. So one would only have to agree upon a standard for these XML
> fil
On Tue, May 14, 2002 at 06:37:19 -0400, Likai Liu wrote:
> >How about XLP? ;)
> >
> well, what does it stand for?
I was being sarcastic. XL and XP seem to be the tags of the moment
athlon..., windows..., and shops who sell stuff to people who slide down
mountians while wearing baggy trousers seem
On Tue, 14 May 2002, Likai Liu wrote:
> also, I'm not going to decide for you what names you like. I mean, if I
> manage to come up with an API and actually publish it, it will come with
> a name (and hopefully a cool one). but at this moment I have not done
> so, so thinking of a name is a bit t
Steve Harris wrote:
>On Tue, May 14, 2002 at 03:21:19 -0400, Likai Liu wrote:
>
>>i promise to think about the name more seriously. btw, I have not looked
>>at the JACK API yet. is anybody aware that we absolutely cannot use or
>>take advantage of the whole or parts of it?
>>
>
>It solves a dif
On Tue, May 14, 2002 at 03:21:19 -0400, Likai Liu wrote:
> i promise to think about the name more seriously. btw, I have not looked
> at the JACK API yet. is anybody aware that we absolutely cannot use or
> take advantage of the whole or parts of it?
It solves a different problem.
How about XL
Dr. William Bland wrote:
>On Tue, 14 May 2002, Steve Harris wrote:
>
>>On Mon, May 13, 2002 at 04:19:39 -0400, Likai Liu wrote:
>>
>>>I think your point of keeping ladspa the way it is for beginning plugin
>>>writers, but to make extension as another pluging API that is back
>>>compatible with
Steve Harris wrote:
>On Mon, May 13, 2002 at 09:23:11 -0400, Paul Davis wrote:
>
>>I'd prefer "VST". There are dozens of useful plugins, hundreds of
>>developers with some knowledge of it, and demonstrated functionality
>>(albeit with some of the same problems as LADSPA, but signs of them
>>being
On Tue, 14 May 2002, Steve Harris wrote:
> On Mon, May 13, 2002 at 04:19:39 -0400, Likai Liu wrote:
> > I think your point of keeping ladspa the way it is for beginning plugin
> > writers, but to make extension as another pluging API that is back
> > compatible with LADSPA is well made. Let's s
On Mon, May 13, 2002 at 04:19:39 -0400, Likai Liu wrote:
> I think your point of keeping ladspa the way it is for beginning plugin
> writers, but to make extension as another pluging API that is back
> compatible with LADSPA is well made. Let's start LADNSSPA (linux audio
> developers not so si
On Mon, May 13, 2002 at 09:23:11 -0400, Paul Davis wrote:
> I'd prefer "VST". There are dozens of useful plugins, hundreds of
> developers with some knowledge of it, and demonstrated functionality
> (albeit with some of the same problems as LADSPA, but signs of them
> being fixed in the near-term
>> So, for the ALSA client/driver, turning on "monitor" on a port means
>> that it causes the data that other clients read from its port to also
>> be sent to its output ports, causing the data to be audible at the
>> same time.
>
>Does this include ports from other clients? I.e. will the engine m
On Mon, 13 May 2002, Paul Davis wrote:
> >I cant figure out what the monitor stuff is doing from the
> >documentation.
>
> I tried to write it in a very generic way that wasn't rooted in
> audio. I wrote:
>
> * Precisely what this means is dependent on the client. A typical
> * result
- Original Message -
From: Paul Davis <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 14, 2002 4:23 AM
Subject: Re: [linux-audio-dev] LADSPA Specs ?
> >I think your point of keeping ladspa the way it is for beginning plugin
> >writers, but to m
>First I have to say I dont follow Jack development very closely due to
>lack of time. But introducing API functions over time (may they be useful
>to some of us, or even necessary) makes the Jack API look like being in
>unstable state and prevent developers (thats me) from actually trying it
>out
>I think your point of keeping ladspa the way it is for beginning plugin
>writers, but to make extension as another pluging API that is back
>compatible with LADSPA is well made. Let's start LADNSSPA (linux audio
>developers not so simple plugin API). Maybe abbreviate it as L6A or
>something.
>> Why not?
>
>Because you cannot have source/sink plugins with LADSPA? Only the host
>can do those.
If I understand what you mean by "source/sink", this is not true. In
fact, someone has already written them. The link was posted here a few
months back. The guy has a complete suite of LADSPA plug
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kai
> Vehmanen
> Sent: 12 May 2002 16:21
> To: [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] LADSPA Specs ?
>
>
> On Sat, 11 May 2002, Likai Liu wrote:
>
&g
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
> Sent: 11 May 2002 22:54
> To: [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] LADSPA Specs ?
>
>
> >you mentioned that you have never seen any plugin that
On Sun, May 12, 2002 at 06:06:32PM -0400, Paul Davis wrote:
> >> I certainly agree that envelope control can be implemented by the host
> >> passing dynamically changing parameters to the plugin. I have already
> >> given a lot of thought on that. Consider the situation of a volume
> >> adjustm
On Sun, 12 May 2002, Paul Davis wrote:
> Richard writes:
>
> >architecture. I.e. you can do lots of things with LADSPA already - you
> >dont need the 10001th API function for special purposes (this seems to
> >be the way Jack is going ATM, unfortunately), just use what is there.
>
> So what's i
Steve Harris wrote:
>I nominate array port types, defaults, port units, proper metadata, a gui
>standard and timestamped events for inclusion. ;)
>
>- Steve
>
one thing at a time, one thing at a time. :-)
I think your point of keeping ladspa the way it is for beginning plugin
writers, but to ma
On Mon, May 13, 2002 at 10:59:29 -0400, Taybin Rutkin wrote:
> On Mon, 13 May 2002, Steve Harris wrote:
>
> > I nominate array port types, defaults, port units, proper metadata, a gui
> > standard and timestamped events for inclusion. ;)
>
> What are port units?
dB, Hz, octaves, meters, seconds
On Mon, 13 May 2002, Steve Harris wrote:
> I nominate array port types, defaults, port units, proper metadata, a gui
> standard and timestamped events for inclusion. ;)
What are port units?
Taybin
On Sun, May 12, 2002 at 11:55:44 -0400, Paul Davis wrote:
> LADSPA is the same. If the plugin declares a port to accept audio, it
> can use the input in any way it wants. How do you think a good
> externally modulated ring modulator would work, anyway? It *requires*
> an input audio signal, but th
On Mon, May 13, 2002 at 03:38:05 +0200, Stefan Kost wrote:
> There was one thing, of which we didn't came to a conclusion/solution.
> As we have succesufully show with some examples, it is not desired it
> the host pre-interpolates the control-data (e.g. for pitch). If the
> plugin does it on the
On Sun, May 12, 2002 at 02:41:07 -0400, Likai Liu wrote:
> negative gain each time. The problem is, for every 128 samples, there is
> a leap of the control parameter, resulting in audiable steps of the
> volume. Depending on the amount of parameter changes, this can be quite
> audiable as click
On Sun, May 12, 2002 at 06:21:08 +0300, Kai Vehmanen wrote:
> On Sat, 11 May 2002, Likai Liu wrote:
>
> > Please consider my proposal for array extension of the LADSPA:
>
> As the one who encouraged to "show the code", I feel obliged to give at
> least some feedback, but I'm afraid it's not very
Paul Davis wrote:
>>>I certainly agree that envelope control can be implemented by the host
>>>passing dynamically changing parameters to the plugin. I have already
>>>given a lot of thought on that. Consider the situation of a volume
>>>adjustment plugin with host-controlled parameter as the e
Paul Davis wrote:
>You've apparently never used an analog modular synthesizer :)
>
Nay, I have used analog modular synth and I know what you're talking about.
>LADSPA is the same. If the plugin declares a port to accept audio, it
>can use the input in any way it wants.
>
No it doesn't work this
Paul Davis wrote:
>but we've already established that LADSPA (like VST) cannot adequately
>describe every parameter to allow easy automated GUI building. the GUI
>control you're describing isn't adequate for controlling a dynamics
>processor - the plugin would need to use LCP and provide a GUI to
>No, audio port is meant solely for audio only. One of the things: you
>cannot supply a hint on the data you pass as audio stream. What about a
>host that doesn't know a plugin's audio stream is supposed to be
>parameter:sample control? This is one of the things I've thought over,
>but passing
Richard Guenther wrote:
>The easiest solution to this kind of problem (parameter change faster than
>nr. of run() calls) is to make the parameter (here: the envelope) another
>audio input stream - this way you get 1:1 parameter:sample mapping. The
>host can be used to feed generated waves to such
>> Well - LADSPA is as it is now, i.e. _S_imple. And I like it being that
>> way. Its use is limited to certain applications, but usually you can live
>> with that.
>
>I think it can be simple without being limited.
>
>Like the VST SDK, which is easy to use for a simple synth, but can also
>suppor
> Well - LADSPA is as it is now, i.e. _S_imple. And I like it being that
> way. Its use is limited to certain applications, but usually you can live
> with that.
I think it can be simple without being limited.
Like the VST SDK, which is easy to use for a simple synth, but can also
support stuff
On Sun, 12 May 2002, Richard Guenther wrote:
> architecture. I.e. you can do lots of things with LADSPA already - you
> dont need the 10001th API function for special purposes (this seems to
> be the way Jack is going ATM, unfortunately), just use what is there.
Hmm, are you referring to some sp
Richard writes:
>Its certainly possible - but the problem with LADSPA is the host-centric
>buffer management. Though you could add a callback asking for the output
>buffer size.
[ then in a later message ]
>architecture. I.e. you can do lots of things with LADSPA already - you
>dont need the 10
>I appreciate when Paul Davis points out that a compressor/limitor
>needing an n-point curve is clearly why I need the array extension. A
>multi-band equalizer with non-fixed bands is also a very good example.
>However, I don't intend to solve the GUI automation issue. For a generic
>represent
>> I certainly agree that envelope control can be implemented by the host
>> passing dynamically changing parameters to the plugin. I have already
>> given a lot of thought on that. Consider the situation of a volume
>> adjustment plugin with host-controlled parameter as the envelope.
>> Suppo
On Sun, 12 May 2002, Likai Liu wrote:
> I certainly agree that envelope control can be implemented by the host
> passing dynamically changing parameters to the plugin. I have already
> given a lot of thought on that. Consider the situation of a volume
> adjustment plugin with host-controlled p
On Sun, 12 May 2002, Likai Liu wrote:
> Richard Guenther wrote:
>
> >Its certainly possible - but the problem with LADSPA is the host-centric
> >buffer management. Though you could add a callback asking for the output
> >buffer size.
> >
> >Richard.
> >
> This should be easy to do as well, but s
Richard Guenther wrote:
>Its certainly possible - but the problem with LADSPA is the host-centric
>buffer management. Though you could add a callback asking for the output
>buffer size.
>
>Richard.
>
This should be easy to do as well, but someone needs to "show the code"
... ;-)
And someone wou
I certainly agree that envelope control can be implemented by the host
passing dynamically changing parameters to the plugin. I have already
given a lot of thought on that. Consider the situation of a volume
adjustment plugin with host-controlled parameter as the envelope.
Suppose each buffer
On Sun, 12 May 2002, Paul Davis wrote:
> >>I'm afraid it would. You need to think about this some more. In any
> >>given unit of time, a certain number of samples are transformed into a
> >>varying air pressure wave. What matters is the relation between those
> >>samples and the original source m
>>I'm afraid it would. You need to think about this some more. In any
>>given unit of time, a certain number of samples are transformed into a
>>varying air pressure wave. What matters is the relation between those
>>samples and the original source material. The number of them remains
>>the same p
>On Sun, 12 May 2002, Kai Vehmanen wrote:
>
>> On Sat, 11 May 2002, Likai Liu wrote:
>>
>> > Please consider my proposal for array extension of the LADSPA:
>>
>> As the one who encouraged to "show the code", I feel obliged to give at
>> least some feedback, but I'm afraid it's not very positive
On Sun, 12 May 2002, Kai Vehmanen wrote:
> On Sat, 11 May 2002, Likai Liu wrote:
>
> > Please consider my proposal for array extension of the LADSPA:
>
> As the one who encouraged to "show the code", I feel obliged to give at
> least some feedback, but I'm afraid it's not very positive this tim
On Sat, 11 May 2002, Likai Liu wrote:
> Please consider my proposal for array extension of the LADSPA:
As the one who encouraged to "show the code", I feel obliged to give at
least some feedback, but I'm afraid it's not very positive this time. The
proposal itself looks fine, but I'm not sure ho
Paul Davis wrote:
>I'm afraid it would. You need to think about this some more. In any
>given unit of time, a certain number of samples are transformed into a
>varying air pressure wave. What matters is the relation between those
>samples and the original source material. The number of them remai
>you mentioned that you have never seen any plugin that outputs a
>different number of samples than inputs. I think the time-stretching
>plugin is a very legitimate example, and I certainly don't understand
>your rationale that a time-stretching plugin should output the same
>number of samples
Please consider my proposal for array extension of the LADSPA:
cut
/* This flag indicates that a port is an array of LADSPA_Data. The size
of the array, which is the number of LADSPA_Data elements in the array,
is stored in the index [-1] of the passing pointer. Further implication
Kai Vehmanen wrote:
>
> The general consensus
> has been (as I've interpreted it) that either convince Richard to adopt
> your change, or create a new plugin standard.
yeah. i want more standards. i think each project should have their own
optimized standard based on LADSPA. embrace and extend.
On Fri, 10 May 2002, Likai Liu wrote:
>> not possible.
>> this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
> sigh, I knew these question would not yield any constructive answer.
> simple is a rather subjective term and that very much depends on
> personal preference. I did r
> you mentioned that you have never seen any plugin that outputs a
> different number of samples than inputs. I think the time-stretching
> plugin is a very legitimate example, and I certainly don't understand
> your rationale that a time-stretching plugin should output the same
> number of sample
Paul Davis wrote:
>>as a completely different issue, is there a way to indicate if a
>>non-audio port is an array (instead of a single value),
>>
>not possible.
>
>this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
>
sigh, I knew these question would not yield any constructi
>as a completely different issue, is there a way to indicate if a
>non-audio port is an array (instead of a single value),
not possible.
this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
and is there a
>clean way to
On Fri, 10 May 2002, Likai Liu wrote:
> I suggest$HOME/.ladspa/presets/[plugin-name]/*for user-defined
> presets.
> and all other default presets in
> $PREFIX/share/ladspa/presets/[plugin-name]/*are installed
> read-only, but can be overridden by user-defined presets.
I just wa
I suggest$HOME/.ladspa/presets/[plugin-name]/*for user-defined
presets.
and all other default presets in
$PREFIX/share/ladspa/presets/[plugin-name]/*are installed
read-only, but can be overridden by user-defined presets.
I think classifying the ladspa plugin types in the $PREFIX
>this is even better (and what I was probably hinting at). Presets should be th
>en even deeper under
>$LADSPA_PATH/share/ladspa/presets/[plugin]/
>and $LADSPA_PATH is our $PREFIX
this conflicts with the definition of LADSPA_PATH in ladspa.h
>For the plugins it could be considered to further div
Hi Conrad,
this is even better (and what I was probably hinting at). Presets should be then even
deeper under
$LADSPA_PATH/share/ladspa/presets/[plugin]/
and $LADSPA_PATH is our $PREFIX
For the plugins it could be considered to further divide it into
$LADSPA_PATH/lib/ladspa/
producers/ (no i
On Tue, 7 May 2002, Taybin Rutkin wrote:
> On Tue, 7 May 2002 [EMAIL PROTECTED] wrote:
>
> gchar buf[16];
>
> for (guint i = 0; i < port_count(); i++){
> if (LADSPA_IS_PORT_CONTROL(port_descriptors()[i])){
> child = new XMLNo
On Tue, 7 May 2002 [EMAIL PROTECTED] wrote:
> Idem for presets : this subject has been discussed a lot, but how do we store
> them and where, finally ?
Where? That was never really decided. I think the idea was to have one
under $LADSPA_PATH/presets and that others could be added as well. I
On Tue, May 07, 2002 at 10:38:09 +0200, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I visited recently www.ladspa.org, and I would like to know where the official
> ldp (lasdpa protocol to change values) resides.
If you mean LCP, it was never made "official" but there is some reference
code at htt
74 matches
Mail list logo
