Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Wed Sep 04 2002 - 23:31:17 EEST


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 think the sequencer has to be /between/ the gui and plugin, I think
it can just bind to the gui's control output (and dsp parts control input
if you want automation). That way there is still a direct connection from
gui->dsp.

> agree. it boils down to making a client emit 'serialized' instance
> state data, and restore its state from this data. the who and where
> of persistent storage is another problem. you're right in that it
> would better be done by the graph maintainer though.

Yes, I think I have an algorithm (see followup mail).
 
> >> * common timebase (audio frames <-> 'real' <-> 'musical' time).
> >
> >Jack does this allready.
>
> for musical time, based on ticks and a tempo map? if your version
> of jack does this, you should commit your changes to CVS. ;)

Ahhh... um, yes. ;) I was thinking 'real' time = 9:15am and musical time =
23sec 242ms since track start. I'm not a very sophisticated sequencer
user! I assume you'd want a timebase client (eg. muse/ardour) that
handles the frame -> bars:beats:ticks mapping.

[malloc]
> a possible halfway solution:
 
> that doesn't solve the generic malloc problem (strings of arbitrary
> size) but it does look attractive for the common case of fixed-size
> events.

Yes, I think that is OK for the time being. As long as the ram chunks
are big enough, (to allow plausible filenames) it should be fine.
 
> >I'm not 100% sure that using the jack audio data graph for this is optimal
> >(it will complicate the graph and maybe make it difficult to pick a good
> >low-latency ordering), but I also haven't thought about it hard enough.
>
> not sure either. two or more graphs will make it more complicated for
> the user en tout cas.

Actually, its allright (drew a graph just before I left work) especially
if the subgraphs are explicity labeled. That way jack /could/ sort them
independently.

The restriction is that the clients shouldn't make connections outside
thier subgraph

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 23:44:01 EEST