Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: la elo 21 1999 - 19:44:37 EDT
On Sat, 21 Aug 1999, Paul Winkler wrote:
> What's CAL?
Cakewalk Application Language, the scripting language for the Cakewalk
sequencer. It is very roughly Lisp-based, but lacks all of Lisp's
expressive strength. Truly, it is difficult to do even the simplest of
tasks with it, and is impossible to do many advanced but useful things. To
make life worse, its documentation is both inaccurate and incomplete.
I've been using Cakewalk for years, and consider it the best of the
various sequencers I've tried, but it has many faults (not just its
commercial, Windows-only status) which drive me nuts.
> And while I'm asking: Why does separate lists for separate tracks make
> things harder? How might one implement tracks with a single list? (I ask
> because I might someday resurrect my "pscore" project, which was a perl
> module for playing with csound scores; I found keeping tracks in
> separate lists was an obvious way to make sense of what I was doing, but
> then I didn't spend much time thinking about alternatives.)
The way to do it is very simple: for every event in the list, include a
field that says what track it's in. Then as you iterate over the list,
you can either use that field or ignore it according to your needs at the
time.
The reason to do it this way is less clearcut. Actually, now that I stop
and think about it, neither approach is particularly better, since it is
easy enough to use a nested loop to address all tracks in the multiple
list version, or use a filter to address one track in the single list
version.
My initial decision was based on extreme frustration with CAL, which uses
separate lists for separate tracks but does not support nested loops
(aaaaaagh!). I decided to keep it for a couple of reasons:
1. The single list approach is easier to send over a stream, for instance
to an external script for algorithmic processing (Bourne script-based
plugins or such).
2. For displaying the event list gui, the natural structure is to have
them merged. For my initial design of the piano roll gui (all tracks
mixed together on a single graph, distinguished by color), the merged
structure is also more natural. However, I've since decided to separate
tracks into different (vertically stacked) graphs in the piano roll, so
that is no longer a consideration, but the filtering (extracting a single
track from the list) is very computationally cheap.
3. For playback, there's no mixdown required. This is one area where the
computational complexity really does count.
> Any idea when your code might be made public?
> I'm pretty frustrated with most sequencers I've tried...
Now look what I've done... I was trying so hard to avoid vaporware, but I
got too excited about the project to keep my mouth shut. :-) I'll start
releasing the code as soon as I have something useful.
Probably the first part that I release won't be a functioning sequencer,
but just the core event list structures and SMF I/O routines with some
samples of them in use. Soon after will be the first shot at the event
list view gui. Next will be the first shot at the piano roll gui, which
will be the first release that looks vaguely like a sequencer. More will
come later. I expect the first part to be ready within a week or two, but
don't quote me on it.
> Cool! Rt remains the only non-MIDI computer-music system with which I've
> ever actually _finished_ a composition. (It's on my webpage, in fact.
> Too bad I have long since lost the rt script, and all the source
> soundfiles. :( )
Rt was the central tool we used in CS/Music-325 class under Prof Lansky,
although we also worked with Ein and CMix, all on black-hardware NeXTs
(they were so very cool). I rather liked Rt, but wished it didn't focus
on realtime or have the stupid gui so that it would be more portable.
(Yes, you could make Rt run handmade score files, but it still loaded the
damn gui.) I actually had started work on a replacement for Rt that
addressed these two issues, but I decided that the sequencer was more
worth my time. The code's up for grabs if anybody would like it, but it
doesn't work yet.
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST