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 smal
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
> qua
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
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 v
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.
/delurk
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 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, 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 proj
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
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 t
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
* zynjacku, by me
* maybe ingen (om), by Dave Robil
"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 handle
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
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 ab
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?
> >
> > An
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
> > 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 c
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 nothi
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 - th
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 le
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 dis
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 le
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 non-
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 m
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 fi
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 th
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
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
w
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 pl
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
bject: Re: [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 (P
> > > 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 (cli
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
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
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 depen
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, 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 (
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
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
> > e
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
> probab
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,
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
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 th
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.
>
> (Co
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, 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
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 L
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 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
>
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 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 leas
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, ha
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 na
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,
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
LAMA - Linux(Libre) Audio Modules Architecture
I hope The Dalai Lama will not object.
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/
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 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
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
co
[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... :)
B
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
Quoting Esben Stien <[EMAIL PROTECTED]>:
> 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
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 ;)
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
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. :)
On Tue, 2006-05-09 at 09:59 +0100, Steve Harris wrote:
> On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote:
> > On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> > > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > > > Hi!
> > > >
> > > > Requirements in order
On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote:
> On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > > Hi!
> > >
> > > Requirements in order of importance, highest first:
> > > - not likely to get us into leg
On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > Hi!
> >
> > Requirements in order of importance, highest first:
> > - not likely to get us into legal trouble
(snip)
> L2, where the L is for LADSPA.
http://www.waves.com/co
On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> 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 con
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
Pret
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.
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 13:50 +0200, Alfons Adriaensen wrote:
> On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
>
>
> > You are completely missing the entire point of LADSPA2. All the
> > unecessary data has been removed from the header file (ie the plugin
> > code).
> >
> > Look
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
> You are completely missing the entire point of LADSPA2. All the
> unecessary data has been removed from the header file (ie the plugin
> code).
>
> Look at the example plugin's code, it will be painfully obvious what the
> advant
On Sun, Apr 30, 2006 at 11:49:32PM +0100, Gordonjcp wrote:
> Jan Weil wrote:
> >Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman:
> >>How about a machine-friendly interface for searching and downloading
> >>plugin tarballs (or references to distribution packages) so one could
> >>wri
Jan Weil wrote:
Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman:
How about a machine-friendly interface for searching and downloading
plugin tarballs (or references to distribution packages) so one could
write a tool like CPAN for LADSPAs? An automated way to download and
install
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
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, 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 [ladsp
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 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-
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 A
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
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
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 qui
On Wed, Apr 26, 2006 at 01:14:06PM -0400, Dave Robillard wrote:
> Thinking about this I was worried about parallel installed multiple
> versions of the same plugin, but as long as the URI refers to a
> compatible version of the plugin, we don't need versioning in the struct
> itself, since the URI
On Wed, Apr 26, 2006 at 08:09:26PM +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 problem whichever [a-z][a-z][a-z] we select :)
>
>
> XAP sugge
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
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)
W
On Wed, Apr 26, 2006 at 08:04:35PM +0200, Leonard paniq Ritter wrote:
> 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 featu
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, I've got working C code that takes a path to
> the d
On Wed, 2006-04-26 at 20:04 +0200, Leonard "paniq" Ritter wrote:
> 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 l
On Wed, 2006-04-26 at 15:56 +0100, Steve Harris wrote:
> That's somewhat like saying a corrupt binary should never cause a
> segfault... if the data file gets corrupted in a way that breaks the
> syntax, then there wont be enouhg data for hte host to attempt to load the
> plugin and it will refuse,
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 problem whichever [a-z][a-z][a-z] we select :)
>
>
> XAP suggests t
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
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
red
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
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 t
On Wed, Apr 26, 2006 at 10:55:12AM -0400, Dave Robillard wrote:
> > 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***
>
> I know it's stupid, but s
1 - 100 of 884 matches
Mail list logo
