On Thu, 2003-08-28 at 16:32, Steve Harris wrote:
> I think it was supposed to be a hint, maybe that got scambled along the
> way, but ++votes for it being a hint.
Has anyone heard from Richard Furse lately? He hasn't given any input
on these requested updates to LADSPA. It'd be nice to hear fro
On Thu, Aug 28, 2003 at 09:04:44 +0100, Mike Rawes wrote:
> > /* Property LADSPA_PORT_CONTINUOUS_CONTROL indicates that the port is
> >a control port with data supplied at audio rate. */
> > #define LADSPA_PORT_CONTINUOUS_CONTROL0x10
> >
>
> In a modular synth context there isn't a
> /* Property LADSPA_PORT_CONTINUOUS_CONTROL indicates that the port is
>a control port with data supplied at audio rate. */
> #define LADSPA_PORT_CONTINUOUS_CONTROL0x10
>
In a modular synth context there isn't a real difference between this
and an audio port - there is no reason
On Sat, Aug 23, 2003 at 04:40:45 +0100, Mike Rawes wrote:
> Hi,
>
> Back in March it was suggested that some additional hints should be
> added to LADSPA - there was some discussion, but nothing since. Here's
> what I gathered from the archives:
Thanks for doing that.
> /* Hint OUTPUT_METER ind
On Sat, 2003-08-23 at 11:40, Mike Rawes wrote:
> Hi,
>
> Back in March it was suggested that some additional hints should be
> added to LADSPA - there was some discussion, but nothing since. Here's
> what I gathered from the archives:
Thanks for bringing these back up. I still would like to see
Hi,
Back in March it was suggested that some additional hints should be
added to LADSPA - there was some discussion, but nothing since. Here's
what I gathered from the archives:
/* Hint MOMENTARY indicates that that a control should behave like a
momentary switch, such as a reset or sync contr
'Steve Harris' wrote about 'Re: [linux-audio-dev] ladspa/input control/control
feedback' - Mon, Jul 07, 2003 at 01:17:15PM CEST
> On Mon, Jul 07, 2003 at 12:49:31PM +0200, Joost Yervante Damad wrote:
> > I was thinking about having 32 input control ports that defin
On Mon, Jul 07, 2003 at 12:49:31PM +0200, Joost Yervante Damad wrote:
> I was thinking about having 32 input control ports that define the
> waveshape, but also about a 33th input control port that allows someone
> to select a "preset" wave-form. (e.g. 1=sound1, 2=sound2, ...)
> It would be ideal
Hi,
I have written a ladspa plugin that works with 32 byte 8 bit samples
that are played looped. At the moment I have a simple "sine" hardcoded
in the plugin, but I want to make the wave-shape controllable.
I was thinking about having 32 input control ports that define the
waveshape, but also abo
On Sat, Apr 05, 2003 at 10:44:01AM -0500, Dave Phillips wrote:
> Steve, what about time compression/expansion, the harmonics generator,
> and the all-important karaoke plugin ?
Hmm... I hadn't though about time compression etc. as its not allowed in
LADSPA.
I suggest that a system that categorise
Steve Harris wrote:
> I recon that something like this is a good start, but feedback would really help:
>
> Utilities
>
> Generators
> Oscillators
>
> Delays
> Phasers + Allpass
> Flangers
> Chorus
>
> Reverbs
>
> Filters
> Lowpass
> Highpass
> Bandpass
> Combs
Hi all,
After the LAD Conference and using apps which used the lrdf taxoomy
(putting plugins into categories) code it became obvious the the current
taxonomy wasn't really useful.
the current taxnomy looks like:
Utilities
Generators
Oscillators
Simulators
Reverbs
Time
Delays
Phas
On Tue, Mar 04, 2003 at 09:56:36AM -0500, Paul Davis wrote:
> >On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
> >> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
> >>control port is likely to be most meaningful to the user if
> >>displayed as a meter. Can be
>On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
>> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
>>control port is likely to be most meaningful to the user if
>>displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
>>if the meter should use
>On Mon, Mar 03, 2003 at 09:36:09 -0500, Taybin wrote:
>> Why have both? Couldn't the absence of one imply the presence of the
>> other? And if there are both, it also implies that there are third and
>> forth states of both and neither.
>
>I think there is meter and/or text (ie. both if ou suppo
On Mon, Mar 03, 2003 at 09:36:09 -0500, Taybin wrote:
> Why have both? Couldn't the absence of one imply the presence of the
> other? And if there are both, it also implies that there are third and
> forth states of both and neither.
I think there is meter and/or text (ie. both if ou support bot
On Mon, 2003-03-03 at 10:12, Paul Davis wrote:
> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
>control port is likely to be most meaningful to the user if
>displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
>if the meter should use a log scale (e
On Mon, 3 Mar 2003 10:12:14 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> i like the recently suggested new hints. i'd like to add the
> following, which would allow hosts to do the right thing with
> both SooperLooper and SC4, which are the first (only?) LADSPA plugins
> to have control output p
On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
>control port is likely to be most meaningful to the user if
>displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
>if the meter should use a lo
i like the recently suggested new hints. i'd like to add the
following, which would allow hosts to do the right thing with
both SooperLooper and SC4, which are the first (only?) LADSPA plugins
to have control output ports, but use them in very different ways. its
almost impossible as it stands to
I hacked up a shell script [attached] to valgrind LADSPA .so files. It
will report leaks, bufferoverruns, reads from unitialised variables and
so on, but it doesn't totally exercise the plugin so it may miss some
things.
Obviously it helps if you rebuild with -g on and it works best with gcc3
(bet
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
Great link for non native English speakers! Thanks!!
Sebastien
- Original Message -
From: "Antti Boman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, 12 December, 2002 11:21
Subject: Re: [linux-audio-dev] LADSPA and Softsynths
>
> I k
Frank Barknecht wrote:
Antti Boman schrieb:
Uh, funny, doubled the mistake of wetting and not whetting.
Ooops, my fault. I didn't know that those were different "w[h]et"s...
I knew but you took me with you ;) There's a great site at
http://www.wsu.edu:8080/~brians/errors/errors.html#errors e
Antti Boman schrieb:
> Antti Boman wrote:
> > Frank Barknecht wrote:
> >
> >> To wet your appetite: I really should finish my PD quicktoot, which
> >> even in its current unfinished form is longer then three standard
> >> quicktoots :(
> >
> > You wet my appetite so that I have to ask if there's
On Wed, 11 Dec 2002 12:09:58 +, Steve Harris wrote
> On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
> > It also means getting midi signal routing working, as currently ssm has no
> > polyphonic means of note signalling, but it's fairly trivial. The only thing
> > is that it will
Antti Boman wrote:
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A qu
On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
> It also means getting midi signal routing working, as currently ssm has no
> polyphonic means of note signalling, but it's fairly trivial. The only thing
> is that it will break the everything plugs into anything rule :(
It shouldn't
On Tue, 10 Dec 2002 15:58:32 -0800, Paul Winkler wrote
> On Tue, Dec 10, 2002 at 11:18:53PM +, Steve Harris wrote:
> > I'm not quite sure how either of them handle that newfangled poly-phoney
> > that seems so popular these days ;)
>
> AFAICT, they both punt and do everything monophonic.
Ther
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A question mark.
-a
Hi,
Paul Winkler hat gesagt: // Paul Winkler wrote:
> PD can handle polyphony, and is about as modular as they come;
> but I don't really understand PD yet. :)
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
qui
chard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Frank
Barknecht
Sent: 10 December 2002 22:51
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] LADSPA and Softsynths
Hi,
Richard Furse hat gesagt: // Richard Furse wrote:
> Just an observation ab
On Tue, Dec 10, 2002 at 11:18:53PM +, Steve Harris wrote:
> I'm not quite sure how either of them handle that newfangled poly-phoney
> that seems so popular these days ;)
AFAICT, they both punt and do everything monophonic.
PD can handle polyphony, and is about as modular as they come;
but I
On Tue, Dec 10, 2002 at 07:11:51PM -, Richard Furse wrote:
> pure-LADSPA networks. BTW, is anyone doing this already? If so, 50% of the
> code is already done. ;-) I'm thinking in terms of defining a synth using
> two patches - one to define the per-note network required (e.g.
> CV->osc->filter
Hi,
Richard Furse hat gesagt: // Richard Furse wrote:
> Just an observation about an alternative path on softsynths: a LADSPA plugin
> or network can be used easily enough as a softsynth using control-voltage
> (CV) approaches (a few already exist). It's just a matter of agreeing the
> conventions
Just an observation about an alternative path on softsynths: a LADSPA plugin
or network can be used easily enough as a softsynth using control-voltage
(CV) approaches (a few already exist). It's just a matter of agreeing the
conventions - implementation is trivial.
I've been meaning to finish writ
On Tue, 12 Nov 2002, Mario Lang wrote:
> So I'd need to connect a audio/controller output
> to a controller input of another LADSPA plugin. Do
> ladspa hosts like ecasound support this? Or am I
> taking a completely wrong route here and it should
> be done differently?
A bit complicated, but po
On Wed, Nov 13, 2002 at 12:42:31 +, Dave Griffiths wrote:
> A LADSPA tracker may be stretching the "simple" factor slightly, but it
> would be a fun project (and ahem, SSM needs a tracker badly!)
Steve starts singing the jack song.
- Steve
On Tue, Nov 12, 2002 at 06:09:20 -0800, Paul Winkler wrote:
> On Wed, Nov 13, 2002 at 12:42:31AM +, Dave Griffiths wrote:
> > Can you open files in a LADSPA plugin?
>
> don't know, but you can't pass strings to a LADSPA plugin's ports,
> so getting the filename in would be ... interesting.
Ye
On Wed, Nov 13, 2002 at 12:42:31AM +, Dave Griffiths wrote:
> Can you open files in a LADSPA plugin?
don't know, but you can't pass strings to a LADSPA plugin's ports,
so getting the filename in would be ... interesting.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where t
Just got me thinking of LADSPA sequencers...
Can you open files in a LADSPA plugin?
I don't know if this is even remotely feasable, but I remember a tracker
from ages ago (I can't remember if it was in linux, could have been dos) that
was entirely command line driven and just read plain text file
On Tue, Nov 12, 2002 at 10:27:09 +0100, Mario Lang wrote:
> So I'd need to connect a audio/controller output
> to a controller input of another LADSPA plugin. Do
> ladspa hosts like ecasound support this? Or am I
> taking a completely wrong route here and it should
> be done differently?
Spiral
Hi.
I've been thinking about what could make
LADSPA more fun, and I think its time for a little
analog step sequencer.
If I make it behave like a real analog step sequencer,
Ill need a frequency output and a trigger output.
Problem is, vcf303 for instance takes a controller
as trigger.
So I'd ne
On Thu, 2002-09-19 at 21:32, Josh Green wrote:
> IIRC the softsynth in MuSE is iiwusynth. This seems silly to me
> actually, since it can also be connected via the ALSA sequencer. I
> suppose it doesn't really matter though, except that I have heard that
> it hasn't been kept up to date with the
On Thursday 19 September 2002 20.07, Peter L Jones wrote:
[...]
> > An alternative is to make
> > TiMidity++ a jack client, and then you can pipe jack output to an
> > LADSPA network if you wish, via maybe ardour.
>
> That's fine if you're controlling TiMidity++ etc from a PC - but
> how do I fix
On Thursday 19 September 2002 05.10, Likai Liu wrote:
> My response to all above discussion about LADSPA and TiMidity++,
>
> I've been playing with TiMidity++ for a while, and hacked it a bit
> as well. For what I think, given the complexity of internals, it is
> not worth making TiMidity++ an LAD
> I didn't see a way to contact them via email, otherwise I would inquire
> as to how to proceed in getting an ID.
http://www.midi.org/about-mma/mfr_id_app.pdf
-
John Lazzaro -- Research Specialist -- CS Division -- EECS --
On Wed, 2002-09-18 at 12:55, Richard Bown wrote:
> On Wednesday 18 September 2002 19:41, Josh Green wrote:
>
> > I wonder how one would go about creating such a standard? Would we
> > need to obtain a Manufacturer's ID for our SysEx standard? If we can
> > find an existing standard we could just
On Thursday 19 Sep 2002 04:10, Likai Liu wrote:
> I've been playing with TiMidity++ for a while, and hacked it a bit as
> well. For what I think, given the complexity of internals, it is not
> worth making TiMidity++ an LADSPA host and having to add some TiMidity++
> specific MIDI controller event
My response to all above discussion about LADSPA and TiMidity++,
I've been playing with TiMidity++ for a while, and hacked it a bit as
well. For what I think, given the complexity of internals, it is not
worth making TiMidity++ an LADSPA host and having to add some TiMidity++
specific MIDI con
On Wednesday 18 September 2002 21.55, Richard Bown wrote:
[...]
> If we were going to the trouble of providing this kind of interface
> for the benefit of sequencers and softsynths it'd be nice to define
> (and perhaps extend) existing softsynth APIs such as the one that
> MuSE already employs per
> Richard Bown <[EMAIL PROTECTED]>
>
> Perhaps we could either approach a small company that has an ID already or
> reuse one that's pretty old and likely close to defunct (again with the
> owner's consent). I wonder who controls their use or if it's a case of
> suck-it-and-see?
http://www.midi.
On Wednesday 18 September 2002 19.18, Peter L Jones wrote:
[...]
> Well, when I had "-B 8,11" (8 x 2^11 byte buffers), the latency
> was, um, rather amusing :-). Dropping this to "-B 4,4" means I
> can't feel any latency between key press and sound.
That's really rather good for an off-line synt
On Wednesday 18 September 2002 19:41, Josh Green wrote:
> I wonder how one would go about creating such a standard? Would we
> need to obtain a Manufacturer's ID for our SysEx standard? If we can
> find an existing standard we could just use it (we would then be
> using a companies ID). I see tha
On Wed, 2002-09-18 at 10:42, Peter L Jones wrote:
> On Wednesday 18 Sep 2002 07:26, Richard Bown wrote:
> > On Wednesday 18 September 2002 01:50, David Olofson wrote:
> > > I was thinking about CCs, Program Change and stuff. Is there a
> > > standard way of asking a synth for the names of it's pat
On Wednesday 18 September 2002 03.41, John Lazzaro wrote:
[...]
> In other words, distribute the legwork of finding out all
> SysEx command variants for every type of synth, to the
> vast userbase :-). Sort of like CDDB, but on a smaller
> scale ...
That's an interesting idea. However, is there e
On Tue, 2002-09-17 at 23:26, Richard Bown wrote:
> On Wednesday 18 September 2002 01:50, David Olofson wrote:
>
> > I was thinking about CCs, Program Change and stuff. Is there a
> > standard way of asking a synth for the names of it's patches, or
> > which CCs are assigned to what, for example?
On Wednesday 18 Sep 2002 02:41, John Lazzaro wrote:
[snip]
> Identity Request/Identity Reply returns enough information
> for a patch editor to know what Manufacturer SysEx commands
> the device understands. Although a major undertaking, it is
> probably is in the realm of the doable to:
[...]
> I
On Wednesday 18 Sep 2002 07:26, Richard Bown wrote:
> On Wednesday 18 September 2002 01:50, David Olofson wrote:
> > I was thinking about CCs, Program Change and stuff. Is there a
> > standard way of asking a synth for the names of it's patches, or
> > which CCs are assigned to what, for example?
On Tuesday 17 Sep 2002 23:23, David Olofson wrote:
> On Tuesday 17 September 2002 20.33, Peter L Jones wrote:
[snip]
>
> > I was thinking it might be fun to have a midi sequencer with a
> > rather large library of MIDI controllers. I was thinking of using
> > Non-Registered Parameters - one to se
On Tuesday 17 Sep 2002 23:23, David Olofson wrote:
> On Tuesday 17 September 2002 20.33, Peter L Jones wrote:
> > Hi there,
> >
> > Do you (or the list) happen to know if anyone has considered making
> > TiMidity++ a LADSPA host?
>
> Can't remember hearing anything like that...
Well, that's a sta
On Wednesday 18 September 2002 01:50, David Olofson wrote:
> I was thinking about CCs, Program Change and stuff. Is there a
> standard way of asking a synth for the names of it's patches, or
> which CCs are assigned to what, for example?
I was wondering aloud to Peter (iiwusynth) about this a wh
> [EMAIL PROTECTED] writes:
> I was thinking about CCs, Program Change and stuff. Is there a
> standard way of asking a synth for the names of it's patches, or
> which CCs are assigned to what, for example?
This does seem like the sort of device-independent info that
could be a part of the Gene
On Wednesday 18 September 2002 00.53, John Lazzaro wrote:
> > [EMAIL PROTECTED] writes:
> > you can't ask units about things,
> > unless you have two cables - and that's not really part of the
> > standard
>
> Actually, it is. The System-Exclusive Universal ID command
> space is general-purpose fu
> [EMAIL PROTECTED] writes:
> you can't ask units about things,
> unless you have two cables - and that's not really part of the
> standard
Actually, it is. The System-Exclusive Universal ID command
space is general-purpose functionality that, in many cases,
assumes units talking to each other v
On Tuesday 17 September 2002 20.33, Peter L Jones wrote:
> Hi there,
>
> Do you (or the list) happen to know if anyone has considered making
> TiMidity++ a LADSPA host?
Can't remember hearing anything like that...
BTW, considering that timidity (AFAIK) was originally designed as an
off-line ren
Hi there,
Do you (or the list) happen to know if anyone has considered making TiMidity++
a LADSPA host?
I was thinking it might be fun to have a midi sequencer with a rather large
library of MIDI controllers. I was thinking of using Non-Registered
Parameters - one to select the LADSPA plug i
On Thu, Aug 15, 2002 at 08:52:46 -0400, Nathan Stewart wrote:
> Perhaps I wasn't clear enough. I'm trying to make a gate that I can feed
> a source which has about 3 hours of silence with 2 seconds of
> interesting signal every couple minutes. I removed the attack/release
LADSPA is not right for
On Thu, 2002-08-15 at 05:10, Steve Harris wrote:
> You can't alter the length of the output buffer, you have to produce as
> many samples as you consume.
>
> For a simple gate, you should be copying samples from input to output when
> its open and writing 0.0f's to the output when its closed.
Pe
On Wed, Aug 14, 2002 at 10:13:54 -0400, Nathan Stewart wrote:
> How can I truncate the length of the current output buffer without
> closing the whole data stream? Is this what I want to do?
You can't alter the length of the output buffer, you have to produce as
many samples as you consume.
For
I wrote a little truncating gate as a Ladspa plugin for my own use that
is designed to function somewhat like ecasound's -gc: gate, but with the
ability to reopen. It's quite simple, as I designed it to be fed from an
effects type noise gate plugin, so it only looks for a string of zero's
in a row
I now have my plugins organised into a tree of classes (a taxonomy), and
an example program to display it.
The example source is at http://plugin.org.uk/lrdf/showtaxonomy.c
Its output is at http://plugin.org.uk/lrdf/tax.txt
ladspa.rdfs describes the taxonomy.
The usage algorithm is pretty simpl
On Fri, Jul 19, 2002 at 11:31:32 +0200, Torben Hohn wrote:
> Well i consider the big parsers the bloat...
> XML is a great idea.
But they are dynamicaly linked, and so many things link against libxml
anyway...
> So you say i can implement support for the default hints ???
Yes, I allready promi
---
Torben Hohn --- [EMAIL PROTECTED]
- Original Message -
From: "Steve Harris" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 19, 2002 10:42 AM
Subject: Re: [linux-audio-dev] LADSPA Defaults via RDF
> On Fri, Jul 19, 2002 at 05:11:06
On Fri, Jul 19, 2002 at 05:11:06 +0200, Torben Hohn wrote:
> Please leave the default hints in the native-API. I only want an instatiated
> plugin to produce sound.
> Which is generally not the case when my defaults are 0 :-(
No, well thats what were trying to fix. it is definatly a problem.
> I
On Fri, Jul 19, 2002 at 11:56:02 +1000, Conrad Parker wrote:
> sure, this would only be for author-defined defaults, which would
> assumedly be minimal and available through getDefault(), and thus
> implicitly available on any architecture the plugin is available on.
Well, I'm currently planning
On Wed, Jul 17, 2002 at 12:37:00PM +0100, Steve Harris wrote:
> On Wed, Jul 17, 2002 at 10:28:10 +1000, Conrad Parker wrote:
> > My concerns are:
> > * bloat -- requiring all LADSPA hosts to link against libxml and
> ...
> > * licensing -- requiring all LADSPA hosts to link to GPL code
>
On Fri, Jul 19, 2002 at 05:11:06AM +0200, Torben Hohn wrote:
>BTW:
>I consider XML to be bloat.
At least it is portable bloat ;)
No, seriously, xml has advantages over plain ascii,
when you consider xslt, rdf, ... etc etc
regards
vini
> On Wed, Jul 17, 2002 at 06:49:05 +0200, Richard Guenther wrote:
> > Hi Steve!
> >
> > I really like it! Also it opens up a lot of other possibilities in the
> > future like GUI hints, etc.
>
> Yes, it should also provide a tree of plugin categories, but I haven't
> defined that yet.
>
> So, t
On Wed, Jul 17, 2002 at 08:26:53 +0200, Richard Guenther wrote:
> Thought the other comment was against dropping "native" defaults support
> with ladspa v1.1, not against RDF in general. As you noted RDF will be
> useful for stuff v1.1 does not handle, such as
> - presets
> - categories
> - exchan
On Wed, 17 Jul 2002, Steve Harris wrote:
> On Wed, Jul 17, 2002 at 06:49:05 +0200, Richard Guenther wrote:
> > Hi Steve!
> >
> > I really like it! Also it opens up a lot of other possibilities in the
> > future like GUI hints, etc.
>
> Yes, it should also provide a tree of plugin categories, bu
Steve Harris wrote:
> On Wed, Jul 17, 2002 at 06:49:05 +0200, Richard Guenther wrote:
>
>>Hi Steve!
>>
>>I really like it! Also it opens up a lot of other possibilities in the
>>future like GUI hints, etc.
>
>
> Yes, it should also provide a tree of plugin categories, but I haven't
> defined th
On Wed, Jul 17, 2002 at 06:49:05 +0200, Richard Guenther wrote:
> Hi Steve!
>
> I really like it! Also it opens up a lot of other possibilities in the
> future like GUI hints, etc.
Yes, it should also provide a tree of plugin categories, but I haven't
defined that yet.
So, that seems to be one
Hi Steve!
I really like it! Also it opens up a lot of other possibilities in the
future like GUI hints, etc.
Richard.
On Tue, Jul 16, 2002 at 06:44:59PM +0100, Steve Harris wrote:
> OK, I now have a minimal proof of concept for describing LADSPA plugins,
> presets and defaults with RDF (http://
On Wed, Jul 17, 2002 at 10:28:10 +1000, Conrad Parker wrote:
> For plugin (author-defined) defaults, I really can't see how any use of
> RDF/XML can be a good thing -- we really should be moving towards defining
> a getDefault() method in the API, and even dynamic parameter suggestions.
N.B. that
Hi Steve, all,
For plugin (author-defined) defaults, I really can't see how any use of
RDF/XML can be a good thing -- we really should be moving towards defining
a getDefault() method in the API, and even dynamic parameter suggestions.
My concerns are:
* bloat -- requiring all LADSPA hos
OK, I now have a minimal proof of concept for describing LADSPA plugins,
presets and defaults with RDF (http://w3c.org/RDF).
At this point I'd like to get some feedback so I can decide wether to cut
my losses or finish it (a usable library for hosts would be about another
weeks work, on and off).
>As already stated, I am a newbie on this list, so never mind if my
>questions
>are stupid...
>
>As I am interested in software synths, I wonder how e.g. the parameters
>of a synthesizer like the DX7, can be handled using LADSPA.
>The DX7 has several (>80) parameters to set, and it seems to me a b
As already stated, I am a newbie on this list, so never mind if my
questions
are stupid...
As I am interested in software synths, I wonder how e.g. the parameters
of a synthesizer like the DX7, can be handled using LADSPA.
The DX7 has several (>80) parameters to set, and it seems to me a bit
of a
Sorry, I didn't mean to sound overly authoritative there - I'm just trying to
get a handle on these issues myself because I'm starting to write some
plugins of my own, in which the level of the input signal has quite a big
effect.
> Actually, no. I just used the hints to indicate which plugins
On Mon, Jul 15, 2002 at 03:25:04 +0200, Nathaniel Virgo 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.
> >
> > by convention, -1.0 to 1.0 (i
> >
> > 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.
>
> by convention, -1.0 to 1.0 (in most plugins and hosts)
>
I had assumed that this would be determined b
On Mon, 15 Jul 2002 13:10:08 +0200
Jürgen Zimmermann <[EMAIL PROTECTED]> 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.
>
> > by convention, -1.0
501 - 600 of 884 matches
Mail list logo
