On 30 Jan 2007, at 01:25, Fraser wrote:
Hi Steve,
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably
On 29 Jan 2007, at 02:18, Fraser wrote:
Hi Steve,
Hi Fraser,
Sure. This was an issue in LADSPA, though not a significant enough
one that anyone wanted it changed. I would suspect you're
overestimating the burden compared to the function call overhead and
cache thrashing. I'd be interested
On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote:
Chris Cannam [EMAIL PROTECTED] writes:
What are they? Do they do anything else, besides host LV2 plugins?
I'm aware of these LV2 hosts:
* jack_host from libslv2 project, by Dave Robillard
* elven from ll-plugins project, by Lars Luthman
On Mon, 2007-01-29 at 13:49 +, Chris Cannam wrote:
On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote:
Chris Cannam [EMAIL PROTECTED] writes:
What are they? Do they do anything else, besides host LV2 plugins?
I'm aware of these LV2 hosts:
* jack_host from libslv2 project, by Dave
On 29 Jan 2007, at 14:41, Lars Luthman wrote:
On Mon, 2007-01-29 at 13:49 +, Chris Cannam wrote:
On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote:
Chris Cannam [EMAIL PROTECTED] writes:
What are they? Do they do anything else, besides host LV2 plugins?
I'm aware of these LV2 hosts:
On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote:
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change.
/delurk
What does chop the run block mean?
On 29 Jan 2007, at 15:23, Paul Winkler wrote:
On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote:
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change.
On Mon, 2007-01-29 at 10:23 -0500, Paul Winkler wrote:
On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote:
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values
Chris Cannam [EMAIL PROTECTED] writes:
Is Zynjacku specific to Zyn in any way, or is it just named that way because
you wanted an LV2 host when you happened to be working on Zyn-based plugins?
It is not specific. I loaded and produced sound with some of LV2 plugins
From ll-plugins and with
Hi Steve,
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably small block size, eg. 32 frames and
On 1/28/07, Chris Cannam [EMAIL PROTECTED] wrote:
On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote:
Robert Jonsson [EMAIL PROTECTED] writes:
On Saturday 27 January 2007 06:47, Loki Davison wrote:
why are you coding new stuff for a depreciated system? Why not
LV2?
And why should you
On 28 Jan 2007, at 05:07, Fraser wrote:
however, it and i think all the other issues you raise are all
solved by
LV2 (LADSPA Version 2), which has come about in part from other
people's
difficulties with the same range of problems as you.
ahh, so there is a V2 coming, not too much info
Hi Steve,
ahh, so there is a V2 coming, not too much info about it yet out there
(unless you know where to look)
Which is deliberate, as it's not quite finished yet. There was quite
a lot of discussion here though.
I took me a while to find this list.
The http://www.ladspa.org site
Fraser [EMAIL PROTECTED] writes:
The plugin doesn't know when a parameter has changed, so it must calculate
it's internal values from the displayed parameter 'as often as possible' -
once per run() call (doing it in the for loop itself is just too extreme).
dynparam LV2 extension handles
On Saturday 27 January 2007 06:47, Loki Davison wrote:
On 1/27/07, Fraser [EMAIL PROTECTED] wrote:
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value
On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote:
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading
Robert Jonsson [EMAIL PROTECTED] writes:
On Saturday 27 January 2007 06:47, Loki Davison wrote:
On 1/27/07, Fraser [EMAIL PROTECTED] wrote:
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability
On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote:
Robert Jonsson [EMAIL PROTECTED] writes:
On Saturday 27 January 2007 06:47, Loki Davison wrote:
why are you coding new stuff for a depreciated system? Why not
LV2?
And why should you code for a plugin standard that nothing
supports?
Suggesting that LADSPA is deprecated is a bit of a stretch. It may not
be
perfect, but it's well supported.
What would be really nice for LA scene is to clean up the available Ladspa
plugins so that they all just work while there is still a momentum to
maintain these. Unless this has changed
Hi Paul,
however, it and i think all the other issues you raise are all solved by
LV2 (LADSPA Version 2), which has come about in part from other people's
difficulties with the same range of problems as you.
ahh, so there is a V2 coming, not too much info about it yet out there
(unless you
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading to non-ideal programming habits.
Let me show what I
On 1/27/07, Fraser [EMAIL PROTECTED] wrote:
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading to
On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote:
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading
Yes, it seems to be great! But the project would be xx times greater
if there were some screen shots plus a simple example host so that
it'll be easier for us to add FLAM into our own software.
Thanks for the advice, but I am still in the process of adding basic
functionality, as stated in my
On Sun, Sep 17, 2006 at 11:22:29 +0200, Luis Garrido wrote:
I have also thought of RDF/turtle as per the new LV2 spec but, if I am
not mistaken, raptor doesn't write turtle and, to be honest, all this
subject/predicate/object/ontology stuff seems like a bit of overkill
just to store groups of
Luis Garrido:
Hi there!
I am in the process of adding preset management to my project FLAM
(custom GUIs for LADSPAs, flam.sf.net) which, by the way, is already
running under Rosegarden, checkout the SVN repo if you want to give it
a try.
...
I would be grateful for any advice on this
Hi there!
I am in the process of adding preset management to my project FLAM
(custom GUIs for LADSPAs, flam.sf.net) which, by the way, is already
running under Rosegarden, checkout the SVN repo if you want to give it
a try.
For those interested I include below the specifications I have came up
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote:
Basically all you've added is port grouping. Sure, there's no binary
breakage now - no kidding, you havn't had to change anything yet. All
you've done is added a bunch of metadata that has no reason to be in
binary code at all,
On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote:
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote:
Plus, it's completely useless for GUIs in a separate process, while LV2
is not (it's just a data file, anything can load it, it's not even
architechture dependent).
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote:
On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote:
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote:
Plus, it's completely useless for GUIs in a separate process, while LV2
is not (it's just a data
On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote:
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote:
If the GUI is in a separate process and connected by e.g. OSC, it
could as well be on a machine that doesn't have the plugin files.
Or that has a different
To ensure consistency the GUI should get its plugin descriptions from
the host anyway. This works even with POL (Plain Old Ladspa).
rather a more general format that it could use to describe its
internal modules or other plugin formats as well. The GUI doesn't
in theory, this
: [linux-audio-dev] LADSPA Extension for Extra GUI Data
To: linux-audio-dev@music.columbia.edu
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
To ensure consistency the GUI should get its plugin descriptions from
the host anyway. This works even with POL (Plain Old Ladspa
On Mon, 2006-06-26 at 15:03 +0200, Alfons Adriaensen wrote:
On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote:
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote:
If the GUI is in a separate process and connected by e.g. OSC, it
could as well be on a machine
On Mon, 2006-06-26 at 18:05 +, carmen wrote:
To ensure consistency the GUI should get its plugin descriptions from
the host anyway. This works even with POL (Plain Old Ladspa).
rather a more general format that it could use to describe its
internal modules or other plugin formats
On Mon, 2006-06-19 at 19:31 +1000, Jez Kabanov wrote:
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my personal blatant bias, but...) I'd suggest taking a look at
LV2. There is a data file you can add all this information to (whatever
On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote:
On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote:
A well-designed set of tags like the ones you show above would
probably solve 99.9% of all cases. But you can't expect anyone
to dream that up in a day. Which leads me to my
On Tue, Jun 20, 2006 at 12:57:43 +0200, Fons Adriaensen wrote:
:somePort lv2:unit unit:octavePitch ;
lv2:baseFreq 264.0 .
It's not beyond the realms of the possible to describe the mathematical
relationship between the octave pitch unit and Hz, but it's probably
excessive.
Hello, i'm new here,
i've been working on a very simple, backward-forwards compatible extension to
LADSPA/DSSI to allow hosts to display more meaningful gui's with a
describe_value function which takes the port index and a LADSPA_Data and
allows the plugin to return a meaningful description. eg.
On Mon, Jun 19, 2006 at 06:03:43 +1000, [EMAIL PROTECTED] wrote:
Hello, i'm new here,
i've been working on a very simple, backward-forwards compatible extension to
LADSPA/DSSI to allow hosts to display more meaningful gui's with a
describe_value function which takes the port index and a
On Mon, 2006-06-19 at 18:03 +1000, [EMAIL PROTECTED] wrote:
Hello, i'm new here,
i've been working on a very simple, backward-forwards compatible extension to
LADSPA/DSSI to allow hosts to display more meaningful gui's with a
describe_value function which takes the port index and a LADSPA_Data
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my personal blatant bias, but...) I'd suggest taking a look at
LV2. There is a data file you can add all this information to (whatever
information you want to), without defining any APIs, changing any
On Mon, Jun 19, 2006 at 01:55:27PM -0400, Dave Robillard wrote:
API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h
what i'd like to know is, if this is a stupid idea ^_^
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my
On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote:
FWIW, I think the not changing any code thing is a blind, someone,
somewhere has to change some code if you want new behaviour*. To me the
critical thing is not that, but that a display function or whatever only
solves half the
On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote:
On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote:
FWIW, I think the not changing any code thing is a blind, someone,
somewhere has to change some code if you want new behaviour*. To me the
critical thing is not
On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote:
On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote:
What worries me is that LV2 is *not* going to solve the problem that
DR raised w.r.t. my Moog filter plugins.
This particualr one I'm not worried about, as it's
On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote:
It's not beyond the realms of the possible to describe the mathematical
relationship between the octave pitch unit and Hz, but it's probably
excessive.
A well-designed set of tags like the ones you show above would
probably solve
On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote:
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one, especially if the R. Crumb reference is intentional
hmm ZAP. not only the least offensive recursive acronym i've seen but
it's
also catchy, has one
On Fri, 2006-05-12 at 12:04 +0100, peter wrote:
On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote:
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one, especially if the R. Crumb reference is intentional
hmm ZAP. not only the least offensive
Lee Revell wrote:
On Fri, 2006-05-12 at 12:04 +0100, peter wrote:
On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote:
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one, especially if the R. Crumb reference is intentional
On Fri, 2006-05-12 at 22:39 +0100, pete wrote:
Lee Revell wrote:
On Fri, 2006-05-12 at 12:04 +0100, peter wrote:
On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote:
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one,
Hans Fugal escribe:
What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or
just a cool animal that has Ls and As in the name.
Then we would be faced against a very popular Win32 application that
shouts Winamp, it really whips the Llama's ass!
(Even though I admit I like the
Dave Phillips wrote:
If I recall correctly LV2 was the rock that the Nostromo
set down on (in the movie Alien).
So it's cool with me. :)
Actually that was LV4-26, but it's still cool ;)
On Wed, May 10, 2006 at 07:12:33 +0200, Esben Stien wrote:
Steve Harris [EMAIL PROTECTED] writes:
LV2
What happened to the funny recursive acronyms?;). That they don't show
up in a google search don't hold water; f.ex a search for JACK get
you.. our beloved, sacred one.
They seem to
[EMAIL PROTECTED] wrote:
Dave Phillips wrote:
If I recall correctly LV2 was the rock that the Nostromo
set down on (in the movie Alien).
So it's cool with me. :)
Actually that was LV4-26, but it's still cool ;)
Yep, you right.
Rats, I really wanted it to be that rock... :)
Steve Harris [EMAIL PROTECTED] writes:
if you really hate it speak up now.
BEAP Environment for Audio Plugins
BAM Audio Mangling
ZAP Audio Plugins
A brainstorm on KLANK, PLOINK, SPLAT, SPLASH, BANG, KABOOM, CRASH,
etc;)
A name means a lot, in my opinion. It's about taking care of every
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one, especially if the R. Crumb reference is intentional
Lee Revell [EMAIL PROTECTED] writes:
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote:
ZAP Audio Plugins
I like this one, especially if the R. Crumb reference is intentional
He he, ZAP has in the 90s also been the name of a german Hardcore/Punk
Fanzine.
Matthias
On Tue, May 09, 2006 at 09:59:53AM +0100, Steve Harris wrote:
But I like the idea. LV2 is less taken.
Early work on the all important logo ;)
http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-2/
http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-version-2-continued/
LAMA - Linux(Libre) Audio Modules Architecture
I hope The Dalai Lama will not object.
On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote:
LAMA - Linux(Libre) Audio Modules Architecture
I hope The Dalai Lama will not object.
Good name, but theres a well known VST plugin called Delay Lama.
- Steve
What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or
just a cool animal that has Ls and As in the name.
The Delay Lama is obviously named after the Dalai Lama, I don't think
there would be any serious confusion. Maybe someone would write a Delay
Lama lama plugin too. ;-)
On Wed,
Dave Robillard wrote:
I like LV2. Bit of a mouthful when spoken, but then so is VST.
If I recall correctly LV2 was the rock that the Nostromo set down on
(in the movie Alien).
So it's cool with me. :)
Steve Harris [EMAIL PROTECTED] writes:
LV2
What happened to the funny recursive acronyms?;). That they don't show
up in a google search don't hold water; f.ex a search for JACK get
you.. our beloved, sacred one.
How about a girlie name to accompany JACK, then?;)
Nothing beats daves' PEEP in
Hi!
Requirements in order of importance, highest first:
- not likely to get us into legal trouble
- no too obvious negative interpretations/associations
(too obvious because it's too hard, internationaly, otherwise)
- no conflict with established open source projects
- easy to search for
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote:
Further, you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Since the plugin author writes both and they are strongly
On Tue, 2006-05-02 at 20:32 +0100, Steve Harris wrote:
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote:
Further, you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Several people have suggested that LADSPA is not a great name for what we
are calling LADSPA 2. Reasons for this include:
The L, it's not really linux specific, and though /we/ know that its the L
of LAD, its not obvious to people outside.
The S, it ain't really going to be simple. For
Quoting Steve Harris [EMAIL PROTECTED]:
My suggestion is that we ressurect the XAP name
(http://www.google.com/search?q=lad+xap)
It stood for Xap Audio Plugin IIRC.
Pros: it's short*, relatively unused** and pronouncable***
More pros: we would have a VST -alike logo already! (looking at
On Wed, Apr 26, 2006 at 11:10:02 +0300, Sampo Savolainen wrote:
Quoting Steve Harris [EMAIL PROTECTED]:
My suggestion is that we ressurect the XAP name
(http://www.google.com/search?q=lad+xap)
It stood for Xap Audio Plugin IIRC.
Pros: it's short*, relatively unused** and
don't think that the string is needed
I think that's fair.
One version number should be enough though,
and it doesn't have to match the actual version of the LADSPA spec
Both those points (especially the second) sound simple and sensible.
Okay, so on reflection...
There's a case to be made
On Tue, 25 Apr 2006 22:55:55 -0400
Paul Davis [EMAIL PROTECTED] wrote:
it takes *way* more lines of code than that to use a ladspa plugin in
this way, and thats for the existing header-only specification.
one the design goals of a good plugin API is to make life simple for
plugins, because
On Wed, 2006-04-26 at 07:23 +0100, Steve Harris wrote:
Several people have suggested that LADSPA is not a great name for what we
are calling LADSPA 2. Reasons for this include:
The L, it's not really linux specific, and though /we/ know that its the L
of LAD, its not obvious to people
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote:
This is why the plugin is really a directory, all the stuff in there is
neccesary.
On the plugin bundle thing, I've got working C code that takes a path to
the directory, parses manifest.ttl, gleams the available plugin DLLs and
data files
That's somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail to be able
to load it, or to load it and produce unexpected
On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote:
That's somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail
On Wed, 2006-04-26 at 17:55 +0100, Steve Harris wrote:
On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote:
That's somewhat like saying a corrupt binary
should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote:
if it never refuses then its ok with me ;)
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
so required features have to be checked on both sides. isn't that
On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote:
I think we would select a short name anyway. Most of them are gone already,
so we have the same problem whichever [a-z][a-z][a-z] we select :)
XAP suggests this could be an XML document type. what about FAP (FAP
Audio Plugin)?
GO FAP!
SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but
it is music related. Incidentally, at some point in the near future it
will be possible to register .ax domain names, don't know under which
conditions.
http://en.wikipedia.org/wiki/.ax
CHAP? (Cunningly Hacked Audio Plugins)
On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote:
On Wed, 2006-04-26 at 20:09 +0200, Leonard paniq Ritter wrote:
On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote:
I think we would select a short name anyway. Most of them are gone
already,
so we have the same
On Wed, Apr 26, 2006 at 08:10:23PM +0200, Luis Garrido wrote:
SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but
it is music related. Incidentally, at some point in the near future it
will be possible to register .ax domain names, don't know under which
conditions.
I quite
On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote:
On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote:
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote:
This is why the plugin is really a directory, all the stuff in there is
neccesary.
On the plugin bundle thing,
On Wed, 2006-04-26 at 19:13 +0100, Steve Harris wrote:
On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote:
On Wed, 2006-04-26 at 20:09 +0200, Leonard paniq Ritter wrote:
On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote:
I think we would select a short name anyway.
SAX: Sexy Audio eXtensions (or just make it recursive (TM))
APE: Audio Pluggable Extensions (not my favorite: there is already an
important audio application that uses the term and I cringe thinking
of the simian lingo that is going to develop around it, but well...)
PEA: Pluggable Extensions for
On Wed, 2006-04-26 at 14:58 -0400, Dave Robillard wrote:
PEEP - Palindromic Extensible Environment for Plugins
or PEEPER Extensible Environment for Plugins, Entitled Recursively
10 points to anyone who can fit both Palindromic and Recursive in
there. ;)
-DR-
On Wed, Apr 26, 2006 at 07:13:23PM +0100, Steve Harris wrote:
Thats the kind of suggestion that makes non-free software developers think
were all pissing about.
But I still dont like it that much ;)
EEP - Extensible Environment for Plugins?
PEEP - Portable ...
MEEP - Multiplatform ...
On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote:
Then again, domains aren't free, and I know I'm not paying for it. :)
If we can find one thats not too expensive I'll pick up the tab.
- Steve
If you can put up with not beeing the root domain, you could get
somthing like
Dave Robillard [EMAIL PROTECTED] writes:
PEEP - Palindromic Extensible Environment for Plugins
This is a very good one;).
PEEP Extensible Environment for Plugins
--
Esben Stien is [EMAIL PROTECTED] s a
http://www. s tn m
irc://irc. b - i .
On Wed, Apr 26, 2006 at 10:29:16 +0200, Jens M Andreasen wrote:
On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote:
Then again, domains aren't free, and I know I'm not paying for it. :)
If we can find one thats not too expensive I'll pick up the tab.
- Steve
If you can put up
On Mon, Apr 24, 2006 at 04:12:11 -0400, Jesse Chappell wrote:
On 4/24/06, tom christie [EMAIL PROTECTED] wrote:
In the former, any change in the descriptor structure will always break
backwards compatibility.
In the later, new functions can extend the core functionality without
breaking
Okay, I ought to have qualified my 'will always break...' that's
clearly not true.
But there is still real inflexibility in using a struct based API.
eg. Say a developer comes up with a nice extension (perhaps to allow a
plugin to deal with multi-channel IO / non-causal audio effects /
alter the
Sorry, I just dont feel that motivated by this. We have a bunch of code
and experience around the struct format, and we know were going to need
something equivalent for the forseeable future, so I dont see the point in
changing it over just for the sake of it.
Sure, for some possible future
Sorry, I just dont feel that motivated by this.
No problem :) just wanted to know if anyone else thought it was an
important point.
Two other concerns...
A) There is no built-in way of a host distinguishing between a LADSPA
1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?)
Would
On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote:
Sorry, I just dont feel that motivated by this.
No problem :) just wanted to know if anyone else thought it was an
important point.
Two other concerns...
A) There is no built-in way of a host distinguishing between a
Ok, some thoughts about the headerfile:
- i would find it helpful if the header also contained a definition of
a valid LADSPA URI, along with some examples.
- passing the HostFeatures in instantiate is a bit too late. i wouldnt
want to instantiate a plugin first to find out if they match i.e.
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
On Tue, 2006-04-25 at 23:58 +0200, Leonard paniq Ritter wrote:
Ok, some thoughts about the headerfile:
[snip]
after reading this i do not see why a new ladspa header is required.
there are barely any changes in 2. i think this
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
I think the easiest thing would be for the plugin to list its required
features in the data file, then the host can weed them out without even
getting that far.
yup.
The plugin may just choose to modify its behaviour, not refuse, so the
On Wed, 2006-04-26 at 00:33 +0200, Leonard paniq Ritter wrote:
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
I think the easiest thing would be for the plugin to list its required
features in the data file, then the host can weed them out without even
getting that far.
yup.
++
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote:
Plugins must be able to refuse hosts and hosts must be able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins
1 - 100 of 724 matches
Mail list logo
