On Wed, 2006-04-12 at 08:40 -0400, Dave Robillard wrote:
> On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog Matheussen wrote:
> > Paul Davis:
> > >> As an interface designer, the first thing I look for on an engine's
> > >> project site is some sort of asynchronous API - I should never concern
> > >> myself with anything outside referencing the api from my app's one
> > >> windowing thread. FMOD, gstreamer, and my dead pkaudio project do this
> > >> very well. I don't ever want to worry about what thread it happens in,
> > >> what threads it will affect, or what the performance effects of
> > >> *making* the call will be (as opposed to residual effects).
> > >
> > >although i agree that this is the right design for many classes of
> > >application design, i would like to see how you propose to tackle
> > >metering and waveform display (the two most difficult examples).
> > >ardour would be relatively easy to separate into interface+engine
> > >processes (as opposed to just a lib/lib-client separation) if it were
> > >not for these issues. moving waveform and metering data back and forth
> > >between two processes via a wire protocol is very expensive and
> > >inefficient.
> >
> > How about creating the gfx waveform data on the engine and then just
> > send a pointer to the gfx process, which displays the data using the
> > MIT-SHM X extension?
> >
> > PS. Please don't let this inspire you to reimplement Ardour. :-)
>
> Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this.
nice idea, except that it needs to work across a LAN too, which MIT-SHM
doesn't accomplish.
anyway, the comments here last week/last weekend convinced me to look at
this in a new light. the bandwidth is really much less than i had been
imagining. and i stress "imagining" :)
--p
Received on Wed Apr 12 16:15:05 2006
This archive was generated by hypermail 2.1.8 : Wed Apr 12 2006 - 16:15:05 EEST