Subject: Re: [linux-audio-dev] plug-in design space
From: Eli Brandt (eli_AT_v.gp.cs.cmu.edu)
Date: ma elo 30 1999 - 18:44:55 EDT
est_AT_hyperreal.org wrote:
> > I've seen an arbitrary-sample-rate architecture (Nyquist), and it's
> > not pretty.
>
> Oooh..details? I may be getting your terms crossed here though. I
> can see how fixed sampling rate plugins (with different sampling
> rates) would require a variable sampling rate architecture..and vice
> versa. It's the `vice versa' that I prefer. :)
Nyquist is a computer-music language that is quite general.
(http://www.cs.cmu.edu/afs/cs/project/music/web/music.software.html)
You can mingle arbitrary sampling rates, vary block lengths on the
fly, make every parameter constant or voltage-controlled or audio-
modulated as you choose -- from the user's perspective it all Just
Works.
The price is that component code is pretty scary, and has to be
elaborated by a special Lisp program from a core written by the
programmer. The handling of ugly details like partial blocks is not
sufficiently hidden. I have to re-read David Olofson's look_ahead /
skip_behind mechanism to see if it can help here, but let's just say I
think there's a reason why most computer-music languages do
synchronous blocks.
(Full disclosure: Nyquist's designer is my advisor.)
> > * How are feedback loops handled?
>
> What I'm hoping for is a spec that will handle a variety of plugins,
> not all of which will be appropriate for given architectural decisions
> on these sorts of questions.
Ah, that sounds like a Solomonic solution. I'll have to think about
what this boils down to for plugins.
> Eli, this is one great set of points/questions!
Hey, thanks.
--
Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST