Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
From: Eli Brandt (eli_AT_v.gp.cs.cmu.edu)
Date: ke elo 25 1999 - 11:48:58 EDT
David Slomin wrote:
> On Sat, 21 Aug 1999, Andreas Voss wrote:
> > Editing a csound .sco file and a MIDI files is very similar.
>
> I take issue with this. In CSound you specify all parameters for a note a
> the time that it is fired. In MIDI, you add or modify parameters over
> time after the note has been fired.
That's a conceptual bug in Csound that IMO should be patched over --
Whatever the renderer, I'd like to approach a musical event as a
timestamped bundle of parameters:
(pitch_envelope == [3 3 3 3.1 3.2 3.1 3 2.9 ...],
FM_index_envelope == [1 0.8 0.6 0.5 0.4 ...],
filter_Q == 0.8
)
If the rendering of abstract temporal data involves making a Csound
instrument accept continuous control from a table or through a
global(!?) variable, or involves placing each note on a separate MIDI
channel so it can be addressed... so be it.
Each instrument of course takes different parameters; one interesting
one would be the "cue audio" instrument, taking
(sample: <an (audio) sample or a reference to one>,
amplitude_envelope: float signal,
pan_envelope: float signal,
<whatever parameters seem like a good idea>
)
So synthesizer control and audio sequencing fit into the same framework.
> Basically, to do this right, you'd want a complete set of scripting
> functionality: conditionals, loops, functions with parameters, etc. These
> don't fit well into the linear event list model that's at the core of the
> sequencer.
The linear event list model is at the core of MIDI, but should it be at
the core of the sequencer? I hope to deal with music not as a flat list
of events, but as something with more temporal structure (structure laid
out by the composer, not the programmer), more parallel shape and control.
I see a few basic data-type constructors, each applicable to constructed
as well as atomic types. And each, in a sequencer, with an associated
editing idiom (or several). (This mention of temporal data types is way
too brief to be comprehensible, but if I get started I'll never stop.)
> > - simple algorithms (linear interpolation from start value to end value)
>
> Algorithms tend to come under the category of plugins. This is another
> issue I've thought a lot about. Keeping plugin-writing simple and
> powerful is the main reason I'm so adamant about keeping the fundamental
> data structure a single event list for the whole song (not even separate
> lists for separate tracks). The algorithms are far simpler when you're
> dealing with linear streams. I've lost a lot of hair because of CAL.
CAL is far too badly designed to be used as a warning against any
particular design approach. :-) Seems to me it's easier to ignore
structure than it is to add it in after the fact. Say something like
function delay_each_track(merged_tracks) =
for each_track in merged_tracks,
for each event e in each_track,
old_e.time = e.time; output old_e
old_e = e
vs.
function delay_each_track(merged_tracks) =
for each event e in merged_tracks,
old_e[e.track].time = e.time; output old_e[e.track]
old_e[e.track] = e
Okay, the difference is not dramatic here, but as I start wanting more
and more temporal structure, it can either go in the data typing, or
I the programmer have to write code that parallels and maintains it by
hand.
> 1. A good MIDI sequencer. This is the most important for me, and as the
> expression goes, if you want something done right, you have to do it
> yourself. (Especially when nobody seems to agree with your definition of
> "done right"!) That doesn't mean that I expect everyone to agree, but
> Jazz and KuBase aren't about to disappear either.
Fair enough, and I don't really expect you to turn on a dime and revamp
your stuff's conceptual basis after N years of development. Just
getting some ideas skittering about....
--
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