egration significantly.
My 2 cents,
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Stefan
Kost
Sent: Wednesday, September 11, 2002 1:50 AM
To: [EMAIL PROTECTED]
Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST
support under OS X)
On Fri, Sep 06, 2002 at 12:54:28 +0200, Tim Goetze wrote:
> Steve Harris wrote:
>
> >OK, heres a graph of how I think a simple plugins via jack session could
> >look: http://www.ecs.soton.ac.uk/~swh/jack-plugin-graph.png
>
> nice. where's the sequencer, and how does it connect? :)
Using the pha
OK, heres a graph of how I think a simple plugins via jack session could
look: http://www.ecs.soton.ac.uk/~swh/jack-plugin-graph.png
Control data is in red, audio data in black, and I know you can't have
bidirectional jack connections, but it makes the diagram simpler ;)
The apps are App A+B the
On Wed, Sep 04, 2002 at 03:57:19 -0400, Paul Davis wrote:
> yes, and it would be less than a few hours to get it working.
>
> the problem is that many of the interesting data types are variable
> sized. MIDI is the most obvious.
I think MIDI is OK, the ammount of events you can have per unit tim
On Wed, Sep 04, 2002 at 09:36:52 +0200, Tim Goetze wrote:
> that's a complication that i'd like to avoid, but i admit it's not
> easier with the sequencer between gui and plugin either, although
> in that case the sequencer playback could be directed at both the
> gui and the processor.
I dont
>>> * lock-free, cross-process, cross-client event/object communication.
>>> this is a tough one especially if events/objects can be of arbitrary
>>> size. maybe a proof-of-concept implementation could use fifos/
>>> AF_UNIX sockets here initially. eventually i think one will need to
>>> u
On Wed, Sep 04, 2002 at 04:46:36 +0200, Tim Goetze wrote:
> > Automation. Sequencers and the like need a way of recording user activity
> >in these uber-plugins. LADSPA makes this very easy.
>
> afaics, this can be solved by inserting a recording/playback plugin
> between gui and processor clien
>Ok, this is kind of what I was getting at. So in effect what we could
>do right now is simply come up with our plugin abstraction layer
>straight away without waiting for JACK to implement anything else?
the only real obstacle to JACK implementing anything else at this time
is providing som
On Wed, Sep 04, 2002 at 06:11:23 -0400, [EMAIL PROTECTED] wrote:
> Before I go off ranting about the current state of audio guis, are you
> saying that clients with different gui toolkits can't connect to the
> same jack server? That seems kinda messed up to me... I feel like I'm
> misunderstandi
On Wed, Sep 04, 2002 at 02:55:08 +0100, Richard Bown wrote:
> Erm. *cough*
>
> Nice app though?
Very. Could do with a friendlier LADSPA GUI, but very fast and easy to use
otherwise.
Multi range selections rule.
- Steve
>Before I go off ranting about the current state of audio guis, are you
>saying that clients with different gui toolkits can't connect to the
>same jack server? That seems kinda messed up to me... I feel like I'm
>misunderstanding.
its not possible to have two instances of an X Window event lo
On Wed, Sep 04, 2002 at 10:37:34AM +0100, Steve Harris wrote:
> On Tue, Sep 03, 2002 at 11:26:04 +0200, Tim Goetze wrote:
> > agree, that would be great. it doesn't solve problems like running
> > for example both ardour (gtk) and muse (qt) under the same jackd
> > though.
>
> Nope, like you sa
On Wednesday 04 September 2002 14:44, Steve Harris wrote:
> [builds sweep]
> No that just looks like its alphabeltical to me.
Erm. *cough*
Nice app though?
B
On Wed, Sep 04, 2002 at 02:16:34PM +0100, Richard Bown wrote:
> On Wednesday 04 September 2002 13:49, Steve Harris wrote:
>
> [RDF]
>
> > 2) A way of ogranising plugins into
> > meaningful categories (so you can pick them from a menu).
>
> Ah, is this what I see implemented in Sweep 0.5.2?
no,
On Wed, Sep 04, 2002 at 02:16:34 +0100, Richard Bown wrote:
> > 2) A way of ogranising plugins into
> > meaningful categories (so you can pick them from a menu).
>
> Ah, is this what I see implemented in Sweep 0.5.2?
[builds sweep]
No that just looks like its alphabeltical to me.
- Steve
On Wednesday 04 September 2002 13:28, Tim Goetze wrote:
> >Isn't this where the audio servers such as aRts have hoped to do
> >business too?
>
> i don't know much about aRts, but from what i have heard it isn't
> 100% clean realtime, and it's based on a particular programming
> toolkit that not e
On Wednesday 04 September 2002 13:49, Steve Harris wrote:
[RDF]
> 2) A way of ogranising plugins into
> meaningful categories (so you can pick them from a menu).
Ah, is this what I see implemented in Sweep 0.5.2?
B
On Wed, Sep 04, 2002 at 12:20:24 +0100, Richard Bown wrote:
> Also I'm getting more confused by the RDF stuff. I was
> under the impression that it was going to be a grammar for describing
> plugins and therefore I hoped something to extend LADSPA hints somewhat
> perhaps/help wit
On Wed, Sep 04, 2002 at 12:33:45 +0200, Tim Goetze wrote:
> what i am trying to steer towards is an approximation of 'plugins'
> and 'applications'. if both interface with the same system-wide
> graph in the same way we get possibilities for free that must be
> coded over and over again with the
On Wednesday 04 September 2002 11:33, Tim Goetze wrote:
> what i am trying to steer towards is an approximation of 'plugins'
> and 'applications'.
approximation == abstraction?
> if both interface with the same system-wide
> graph in the same way we get possibilities for free that must be
> cod
On Tue, Sep 03, 2002 at 11:26:04 +0200, Tim Goetze wrote:
> agree, that would be great. it doesn't solve problems like running
> for example both ardour (gtk) and muse (qt) under the same jackd
> though.
Nope, like you said, that has to be solved by having them in seperate
processes. I think th
On Tue, Sep 03, 2002 at 03:58:05 +0200, Tim Goetze wrote:
[toolkit problem]
> that's where out-of-process is our only hope of unification i think.
> this or that some sunny day all of the toolkits agree on a common
> divisor.
Well, it is possible to write a plugin-specific common denominator.
Steve Harris wrote:
>On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
>> i believe that with patience and prudence 'lad' may be capable of
>> producing an interface definition capable of connecting all our
>> audio/MIDI apps and libraries in style, without deriving from CA
>> or VST.
>
On Mon, Sep 02, 2002 at 08:05:01 +0200, n++k wrote:
> |> here, but i also think that o-o-p is a big performance burden in
> |> most cases (otoh i seem to have a faible for aged hardware ;).
> |
> |I'm not to sure about the OOP comment. A few years ago I would have
>
> I think he meant _O_ut _O_f
/wrote Steve Harris <[EMAIL PROTECTED]> [Mon, 2 Sep 2002 18:27:50
+0100]
|On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
|> i think that Jack and its quick adoption shows the potential is
|> here, but i also think that o-o-p is a big performance burden in
|> most cases (otoh i seem t
On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
> i think that Jack and its quick adoption shows the potential is
> here, but i also think that o-o-p is a big performance burden in
> most cases (otoh i seem to have a faible for aged hardware ;).
I'm not to sure about the OOP comment.
On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
> i believe that with patience and prudence 'lad' may be capable of
> producing an interface definition capable of connecting all our
> audio/MIDI apps and libraries in style, without deriving from CA
> or VST.
I agree. Entirely. But I ha
Things may not actually bode that well for apple, most musicians I know
are still on os9, using protools or cubase and have thousands of dollars
invested in their plug-ins. The beauty of ladspa is that all you invest
is time. I think apple is screwed in the long run because Verizon and
the other m
Paul Davis wrote:
>steinberg; CoreAudio comes *with* OS X, and so they have no
>distribution issues to worry about - its part of the same overall
>license as the OS. i presume that means that implementing a version of
>the API for a different OS is completely legal. header files? not
>sure.
that
On Mon, Sep 02, 2002 at 08:41:10 -0400, Paul Davis wrote:
> my impression from reading the AudioUnits docs of late last year was
> that there was no mention of graphics at all in the API. thats why it
> seemed hard to figure out if they are in-process or o-o-p. otoh, i
Yes, the API doc I found af
>> http://www.emagic.de/english/news/2002/osx3.html
>> http://www.emagic.de/german/news/2002/osx3.html
>
>OK, so the inevitable question. do we know how 'free' the spec is giong to
>be? Is it a good candidate for LADPA?
>
>I get the impression that the graphics API is tied to the DSP API, whic
On Sun, Sep 01, 2002 at 02:23:36 -0400, Paul Davis wrote:
>
> http://www.emagic.de/english/news/2002/osx3.html
> http://www.emagic.de/german/news/2002/osx3.html
For those, like me who have no idea about the API, there are some docs at:
http://qtj.apple.com/pub/audio/docs/com/apple/audio/un
On Sun, Sep 01, 2002 at 02:23:36 -0400, Paul Davis wrote:
>
> http://www.emagic.de/english/news/2002/osx3.html
> http://www.emagic.de/german/news/2002/osx3.html
OK, so the inevitable question. do we know how 'free' the spec is giong to
be? Is it a good candidate for LADPA?
I get the impre
> if anyone has any more information on this (john l?
Doug Wyatt posted something on friday to coreaudio-api, that
seemed to indicate that a candidate build for sample code for
audio units exists, and should be out the door in a week if
things go well. See this thread:
http://lists.apple.com/m
>Paul Davis wrote:
>
>> http://www.emagic.de/english/news/2002/osx3.html
>> http://www.emagic.de/german/news/2002/osx3.html
>
>do you happen to know whether these Audio Units are in-process,
>o-o-p or both?
its really hard to tell from the reading i have done on
AudioUnits. the API leaves it e
Paul Davis wrote:
> http://www.emagic.de/english/news/2002/osx3.html
> http://www.emagic.de/german/news/2002/osx3.html
do you happen to know whether these Audio Units are in-process,
o-o-p or both?
tim
http://www.emagic.de/english/news/2002/osx3.html
http://www.emagic.de/german/news/2002/osx3.html
37 matches
Mail list logo
