Re: [linux-audio-dev] News about sequencers (not my own though!)

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

Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: Bill Gribble (grib_AT_billgribble.com)
Date: ke tammi  26 2000 - 20:11:48 EST


David Olofson <audiality_AT_swipnet.se> writes:

> > I agree. The problem is when I want "real time" sequencing with
> > "logic" (not Logic(TM)). If I want to give a command to my
> > sequencer like "in this given MIDI pattern, reduce all CC#11's
> > greater than 72 to 72." my only hope is with a little
> > extension/command language. It's a hard problem and any solution
> > is impressive.
>
> Hmm... Sounds like you need a small, fast and very flexible sequencer
> core, with a nice interface that allows you to "directly" access
> events using a nice scripting language.

This could also be where a model like the one Quasimodo uses could be
handy. In Q, you set up a "network" of signal processing modules, in
a patch-bay metaphor. Modules have graphical knobs that can be
tweaked in real-time to change the way the module operates; MIDI
controller signals can also be assigned to control the knobs. In your
example, the module would be a "MIDI stream massager" rather than an
audio signal processor. You have a sequencer which is just a fairly
dumb MIDI stream recorder/player, and then you patch that stream into
a filter/massage block. In your case, it's just a threshold clipper
(if I understand your notation) that selects control messages for
continuous controller 11 and modifies the values sent in that CC
stream.

Right now, there's not a great language in Q (other than graphical)
for building these networks and connecting the controllers to them.
I'm working on insinuating Guile into Q right now and hopefully when
that's done we can export an API that lets you write simple scheme
code to do this stuff.

> This, however, does not enable you to do true real time
> nondestructive MIDI processing with your scripts - the scripts are
> more like non-RT software controlling a piece of custom hardware.

Q's model makes the limitation that the real-time primitives are
written in a Csound-like orc language, but to me it seems reasonable
to separate the writing of bits that must operate in real time from
the bits that script the usage of the real-time components. At this
stage of the computer-music development process it's not yet
reasonable (IMO) to try to unify the real-time and scripting "time
scales" of program control.

> Perhaps there really is a need for an
> interpreted or "semicompiled" language that's deterministic rather
> than "nice" and fast?

Well, that sounds right to me; Paul has made the point before that you
really want to be able to compile the real-time parts down to thunks
that can be efficiently scheduled and sequenced by an engine that can
keep track of buffer fullnesses, compute load, etc to do the right
thing.
 
Bill Gribble


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST