On Mon, Jul 15, 2002 at 12:12:18 +0100, Mike Rawes wrote:
> > 2. Is there any range constraint applied to the audio content
> >communicated by the audio input/audio output ports?
> >VST e.g. does restrict the range from -1.0 to +1.0.
>
> I'd say that if the audio ports are carrying audio
> a) if you're an app (a ladspa host)
>
> they must all be at least long enough to handle the SampleCount argument
> you pass to the plugin's run() method.
Agreed. So: Please, can someone state this explicitly in the LADSPA
specification for
clarity purpose???
> noone will spank you if your buf
On Mon, 15 Jul 2002 12:00:37 +0200
Jürgen Zimmermann <[EMAIL PROTECTED]> wrote:
> Hello,
Hi
> I just joined the "linux-audio-dev" list a few days ago,
> and after some time studying the ladspa.h file, I have
> still some questions left:
>
> 1. Must the buffers assigned to audio input and audio
On Mon, Jul 15, 2002 at 12:00:37PM +0200, J?rgen Zimmermann wrote:
> Hello,
> I just joined the "linux-audio-dev" list a few days ago,
> and after some time studying the ladspa.h file, I have
> still some questions left:
>
> 1. Must the buffers assigned to audio input and audio output ports
>
Hello,
I just joined the "linux-audio-dev" list a few days ago,
and after some time studying the ladspa.h file, I have
still some questions left:
1. Must the buffers assigned to audio input and audio output ports
have the same length? Where is this stated???
The sample implementations sugg
Hi,
Junichi Uekawa hat gesagt: // Junichi Uekawa wrote:
> ladspa-sdk is distributed as a tarball, and
> ladspa.h is part of it.
>
> I see no problem in a SDK package containing some
> example code.
I even think, that this is the right thing (tm) to do from a
packager's point of view. Of course
> >I set out to package ladspa_sdk into an rpm for the upcoming GStreamer
> >Red-Carpet channel.
>
> its *extremely* important not to confuse the source code available
> from ladspa.org with the API defined by the single header file called
> ladpsa.h.
>
> the cmt plugin set is just one set of samp
>ladspa-sdk is distributed as a tarball, and
>ladspa.h is part of it.
from Ardour's README
Getting LADSPA
Note: the LADSPA SDK really only consists of a header file, and you
can get that like this (all one line):
lynx -dump http://www.ladspa.
* Thomas Vander Stichele <[EMAIL PROTECTED]>:
> So here are a few questions :
>
> a) any special reason why it doesn't use autotools ? Would my converting
> ladspa to it be appreciated ?
It is simple a headerfile. What for do you need autobloat?
> b) ladspa_sdk is probably the first package I
Paul Davis <[EMAIL PROTECTED]> immo vero scripsit:
> I don't believe that the sample plugins or sample tools should be part
> of a package called "LADSPA". With JACK, we make the sample clients
> available in a separate package. LADSPA itself is just a header file,
> and I don't believe that the
>> its *extremely* important not to confuse the source code available
>> from ladspa.org with the API defined by the single header file called
>> ladpsa.h.
>
>> the cmt plugin set is just one set of sample plugins. they are useful,
>> but they are not "LADSPA".
>
>Hi,
>
>thanks for the reply. I'm
> its *extremely* important not to confuse the source code available
> from ladspa.org with the API defined by the single header file called
> ladpsa.h.
> the cmt plugin set is just one set of sample plugins. they are useful,
> but they are not "LADSPA".
Hi,
thanks for the reply. I'm not even
>Hey,
>
>I set out to package ladspa_sdk into an rpm for the upcoming GStreamer
>Red-Carpet channel.
>
>So here are a few questions :
>
>a) any special reason why it doesn't use autotools ? Would my converting
>ladspa to it be appreciated ?
>
>b) ladspa_sdk is probably the first package I ever d
Hey,
I set out to package ladspa_sdk into an rpm for the upcoming GStreamer
Red-Carpet channel.
So here are a few questions :
a) any special reason why it doesn't use autotools ? Would my converting
ladspa to it be appreciated ?
b) ladspa_sdk is probably the first package I ever downloaded t
> I would use the defaults to give states where the plugin is active, but
> having as little effect on the audio as possbile. This gives the user a
> place to start experimenting, so they can tell the effect of the various
> ports.
A "passthrough" mode, where the filter has as little
effect a
On Fri, May 31, 2002 at 09:16:16 +0200, Stefan Kost wrote:
> I am +1 for RDF (as XML-files).
> I would say, we just need a naming convention for the default-preset (e.g.
>mysynth/.default.prs).
> This would have the advantage, that the user could e.g. say use current-settings
> as default and the
> * handle author presets (at least a single set of defaults) through
> the LADSPA API.
>
> * handle user presets through a separate means such as RDF/XML
You could handle author presents through an XML file that is distributed with
the plugin and therefore allow the user t
On Thu, May 30, 2002 at 06:30:35PM +0100, Steve Harris wrote:
> On Thu, May 30, 2002 at 09:41:25 -0400, Paul Davis wrote:
> > >I would say that persets are metadata, and so they should be seperate
> > >from the API.
> >
> > do you agree that defaults are really a preset?
>
> Yes, but I was being
> Yes, but I was being pragmatic. I think that defaults are more important
> than a standardised preset format. I also thought that it would be easier
> to get people to agree on a defaults system than a presets system.
But isn't the option of multiple presets, one of which is flagged or somehow
I am +1 for RDF (as XML-files).
I would say, we just need a naming convention for the default-preset (e.g.
mysynth/.default.prs).
This would have the advantage, that the user could e.g. say use current-settings
as default and they get written to this file.
Useing such an approach mean no change t
> do you agree that defaults are really a preset?
Only if there are more than one. A system that includes only one
predefined set of parameter values, sets the parameters to these values
during initialization, and always performs an initialization on startup,
is a system that uses defaults that
On Thu, May 30, 2002 at 09:41:25 -0400, Paul Davis wrote:
> >I would say that persets are metadata, and so they should be seperate
> >from the API.
>
> do you agree that defaults are really a preset?
Yes, but I was being pragmatic. I think that defaults are more important
than a standardised pre
>On Thu, May 30, 2002 at 02:08:56 +0200, Richard Guenther wrote:
>> Of course defaults are a part of presets - so we maybe better come up
>> with a standard on plugin presets. The plugin then could come with a
>> "standard" preset. The question is wether to separate presets from the
>> LADSPA API
On Thu, May 30, 2002 at 02:08:56 +0200, Richard Guenther wrote:
> Of course defaults are a part of presets - so we maybe better come up
> with a standard on plugin presets. The plugin then could come with a
> "standard" preset. The question is wether to separate presets from the
> LADSPA API or no
On Thu, May 30, 2002 at 07:18:20AM -0400, Paul Davis wrote:
> >i guess it is safe to say that '*DataLocation = default' is simple:
> >it is simple to implement in a plugin for sure. it is reasonable for
> >hosts not to care about the default value at all. it gets the
> >efficiency bonus for bein
>i guess it is safe to say that '*DataLocation = default' is simple:
>it is simple to implement in a plugin for sure. it is reasonable for
>hosts not to care about the default value at all. it gets the
>efficiency bonus for being capable of expressing any value from the
>valid range while saving
i wrote this before fetching mail, so it happens to be mostly a
reiteration of conrad's points. skip to the last paragraph if you
find this mail lengthy, boring, or both.
Richard W.E. Furse wrote:
>To flesh this out, some problems I can think of with this approach are as
>below (mostly following
On Wed, May 29, 2002 at 11:51:56 +0100, Richard W.E. Furse wrote:
> My preference is the extra 4bits of hint. I'm happy to get rid of the high
> and low options if they're too confusing or just leave defaults as the job
> of whatever GUI wrapper layer is used - I'd prefer to keep LADSPA simple.
A
On Thu, May 30, 2002 at 01:46:03PM +1000, Conrad Parker wrote:
> I'll deal with each in turn, but preface this by clarifying that we are
> only talking about control ports, not audio ports, because:
>
> * conceptually, we're only talking about default parameters;
> default audio input
On Wed, May 29, 2002 at 11:51:56PM +0100, Richard W.E. Furse wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Goetze
> > Sent: 29 May 2002 22:32
> [...]
> > >totally agree -- Tim's solution doesn't break binary compatability,
> >
> >
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Goetze
> Sent: 29 May 2002 22:32
[...]
> >totally agree -- Tim's solution doesn't break binary compatability,
>
> richard pointed out that it'd actually break binary compatibility with
> hosts that
Conrad Parker wrote:
>by making the defaults an outcome of connect_port() instead, we get a
>dynamic mechanism for free. Default frequencies can be related to the
>sample rate, etc.
now you mention it, yes, that's a very welcome side effect i think.
>totally agree -- Tim's solution doesn't brea
On Wed, 29 May 2002, Conrad Parker wrote:
> regarding the provision of default values in LADSPA, I totally support
> Tim's suggestion -- in fact, I reckon it is brilliant for reasons I'll
> outline below :)
[...]
> All this requires is that a plugin suggest default values in the way
> Tim propose
regarding the provision of default values in LADSPA, I totally support
Tim's suggestion -- in fact, I reckon it is brilliant for reasons I'll
outline below :)
On Tue, May 28, 2002 at 04:25:21PM +0200, Tim Goetze wrote:
> Steve Harris wrote:
>
> >On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze
Steve Harris wrote:
>On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote:
>> so what do you think about the actual proposal? (*DataLocation =
>> default in connect_port)
>
>I don't think it gains anything over Richards original suggestion, does
>it? The problem is that it moves the definitio
On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote:
> so what do you think about the actual proposal? (*DataLocation =
> default in connect_port)
I don't think it gains anything over Richards original suggestion, does
it? The problem is that it moves the definition of the defualt values awa
On Sun, May 26, 2002 at 01:52:40PM +0100, Richard W.E. Furse wrote:
> After some more worry about the least untidy way to do defaults, I've come
> up with the following, based on Paul's/Steve's scheme. I'm edging towards
> this as preferable to my previous posting for LADSPA v1.1.
>
> Please let
Steve Harris wrote:
>On Mon, May 27, 2002 at 01:45:04 +0200, Tim Goetze wrote:
>> ps: i'd also like to see LADSPA_PORT_CONTROL | LADSPA_PORT_AUDIO being
>> given official merit in .
>
>That changes the semantics of CONTROL and AUDIO it would be better to add
>a new hint which indicated that an au
On Mon, May 27, 2002 at 01:45:04 +0200, Tim Goetze wrote:
> ps: i'd also like to see LADSPA_PORT_CONTROL | LADSPA_PORT_AUDIO being
> given official merit in .
That changes the semantics of CONTROL and AUDIO it would be better to add
a new hint which indicated that an audio rate control was intend
Richard W.E. Furse wrote:
>After some more worry about the least untidy way to do defaults, I've come
>up with the following, based on Paul's/Steve's scheme. I'm edging towards
>this as preferable to my previous posting for LADSPA v1.1.
>
>Please let me know how you think this compares with the p
After some more worry about the least untidy way to do defaults, I've come
up with the following, based on Paul's/Steve's scheme. I'm edging towards
this as preferable to my previous posting for LADSPA v1.1.
Please let me know how you think this compares with the previous
incarnation.
Some comme
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'
> Downplaying the meaning of previously done
> work of this group (search for "LADSPA" at
> www.eca.cx/lad and you'll get thousands of
> matches) is not a good way to start your campaign.;)
I owe an apology - I did not mean to criticize LADSPA - it is good. In
fact, it vastly changed the way I
On Tue, 21 May 2002, Richard Bown wrote:
> Tim Hockin wrote:
>> No need to get on the defensive, really. I don't deny the usefulness or
>> importance of LADSPA _AT_ALL_. It is, by and large, a very good system.
> Well why don't you stop being such a dick and just get on with it rather
> than po
Tim Hockin wrote:
> > simple, yes. useless, not even close.
>
> No need to get on the defensive, really. I don't deny the usefulness or
> importance of LADSPA _AT_ALL_. It is, by and large, a very good system.
>
> Ysh - I have some different ideas that I want to play out, that is all.
W
> useless? steve's set plus ardour as the host (or possibly other apps)
> provides me with a very rich working environment. there are very few
> issues i have with LADSPA right now that are not shared by VST (for
> example). the main ones would be the lack of string parameters and the
> inability
>> second, as has been said many times here, the "S" in LADSPA stands for
>> "Simple". LADSPA was never intended to be a complete plugin API. it
>
>right, but sufficiently simple borders on useless.
useless? steve's set plus ardour as the host (or possibly other apps)
provides me with a very rich
> second, as has been said many times here, the "S" in LADSPA stands for
> "Simple". LADSPA was never intended to be a complete plugin API. it
right, but sufficiently simple borders on useless.
> third, calling LADSPA "over-engineered" strikes me as similar to
I wasn't referring to LADSPA, but
>> So no complaints then? When does this become offical? (When can people
>> download a 1.1 ladspa.h file?)
>
>I'm a relative newcomer here, but my initial reaction was "that's all?".
>I'm all for incremental, backwards-compatible changes, but sometimes things
>get over-engineered for the sake o
> > On the second point, here's a set of diffs for the new version of ladspa.h.
> > Do these look alright? I'd have preferred to put the default values in the
> > hint structure, but that would have changed its size and broken
> > backwards-compatibility.
>
> So no complaints then? When does thi
On Sat, 18 May 2002, Richard W.E. Furse wrote:
> On the second point, here's a set of diffs for the new version of ladspa.h.
> Do these look alright? I'd have preferred to put the default values in the
> hint structure, but that would have changed its size and broken
> backwards-compatibility.
S
>Well, it had to get to the top of my to-do list eventually. I've been trying
>to sort [1] the LADSPA website [2] LADSPA v1.1.
>
>On the first point, I'm missing links to LCP and the XML GUI thing. Also, if
>there are any plugins or hosts that should be on the list please shout (I
>have added a fe
Well, it had to get to the top of my to-do list eventually. I've been trying
to sort [1] the LADSPA website [2] LADSPA v1.1.
On the first point, I'm missing links to LCP and the XML GUI thing. Also, if
there are any plugins or hosts that should be on the list please shout (I
have added a few that
> 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
601 - 700 of 884 matches
Mail list logo
