Re: [linux-audio-dev] Developing a music editor/sequencer

I wanted to post this to the root of the thread since this isn't a reply to
any particular post, but I lost the beginning of the thread somehow.

This is my initial stab at a development plan. I'm tentatively calling this
project Scortch. Because of fundamental differences in design, I don't think
I can directly build anything off of Rosegarden, but I intend to use it (and
denemo and kguitar) for inspiration. (I have a couple of very hacked up
versions of these programs, mostly demonstrating to me how difficult it would
be to directly branch from one these.)

This isn't meant to be the "ultimate music development system", perfect for
everyone's needs. Rather, I have the needs of a particular audience (me!) in
mind. While I'd like to leave the door open for OSC, algorithmic music, etc.,
my primary goal is to give me tools that I can (and will) use. Because of
this, and (at least as importantly) because I'm familiar with them, I'm going
to concentrate on MIDI and WAV audio. I want to do most of my editing in a
ScoreView. The TrackView is there as a convenient way to manipulate large
portions of the score. While midi and audio are different, both can be
represented in a score. We don't have a normal musical staff for a wav, but
we can have a "wav staff" which just appears as a single line (or bar). The
advantage? We can see everybody together. I want to treat midi/audio effects
in the same way as standard music notational effects such as (stacato, let
ring, slurs, etc.) Thus, "echo" and "let ring" should have a similar
appearance on the page. (Obviously, midi-only effects need to be disabled
from selection for audio tracks, and vice versa.)

I've been thinking of the Scortch system as a suite of plugin-like or
embedable programs that have some measure of independence. We should be able
to play our project without the need for a gui. We should be able to notate
without a player (sequencer). Of course, they should cooperate and enhance
each other's functionality. The other night I sat down and thought of how to
proceed. The following is what I came up with:

Scortch Notes

Let's try and divide things up into logically distinct pieces in order to make
the system more manageable. Here are the programs and plugins:
 
ScortchEditor -- score editor with score, track, and event views. Tracks are
generic entities that get handled by plugins. Specialized tracks should have
minimal restrictions, just enough to make it so we can play, record, and
display properly. Each track must map its timing to seconds (or some division
thereof). The editor creates .sco files, which are xml files storing all the
relevent information. Each type of track would be responsible for its own
editor. The ScortchEditor is just a way to see everything together, and gives
a unified face to the project.
 
ScortchPlayer -- plays compiled (.scoc or .scop) files. The ScortchPlayer
contains a ScortchMixer. For the mixer, think of a 12-channel mixer board, or
an 8-track tape deck. We have a slider and buttons for each track, and we can
apply effects and adjust volume levels in (near) real time. The mixer outputs
"mixer automation" data to a file (.scomix). This file can be used on
subsequent runs to reproduce the same mixer settings. We want this file
separate so we can keep our same mixer settings while re-editing the the
score. The mixer can also create mixdowns, so that we can mixdown to a MIDI
file, a wav file, etc. We can also mixdown to a .scop file, which is the
compiled score (.scoc) with the mixer settings applied. You might consider
the .scop file as a finished product.
 
ScortchRecorder -- record tracks from MIDI, audio, etc.
 
InstrumentEditor -- create/edit instrument definition files. We begin with
simple mapping to GM patches, but we try and make it general enough so that
other (non-MIDI) instruments can be created.
 
MusicSystemEditor -- create/edit a music system. This is a broad view that
defines the behavior and appearance of staves. We begin with modern western
notation as the only option. But let's leave the door open for ligatures,
user-defined notation, etc. Embedded within this is how notes are defined and
how they are mapped from the simple integers stored in the .sco file. (This
information would be stored in a note definition file.) Also included would
be how these notes are rendered (i.e. a tuning file). The tuning file maps
the notes to frequencies. We would have some shortcut notation for "regular"
tunings (tunings that repeat at some regular interval, which we will define
as an "octave".)
 
ScortchCompiler -- compiles as many abstractions away as possible. For MIDI,
the compiler converts the abstract notes from frequencies to MIDI note
numbers with pitch bends. All notational modifier symbols (e.g. dynamics,
trills, echo effect, hold pedal on/off) are applied. The result is a simple
xml representation of MIDI. Similarly for wav audio, we apply static effects
(e.g. echo, flanger) and store the result as a new wav. Other formats can be
defined. Compiled files are stored as .scoc files.
 
ScortchPerformer -- a hook for future abilities. It takes a score, a
conductor, and players (who own the instruments in the score) and generates a
performance, which is another score and the results of the interpretations of
the conductor and players (who are algorithms of some sort). In this way
users could have a different performance each time the score is
performed/compiled/played. Additionally, users can lock in a particular
performance and subsequently overdub their own tracks. The first method would
be useful for a musician who wants to play live. His virtual band will play a
unique performance. The second method is more akin to making a studio
recording. The band plays and it's recorded. Now we do overdubs.
 
We generate quite a few files. The music system, inst definintions, etc. may
be used for many different scores. The .sco file contains the actual music in
xml format. It also references these other files.
 
 This project does not attempt to satisfy the needs of every musical
experimentalist. It's not that general. But I believe it has the potential to
satisfy most of those who want to write traditional western style music as
well as those who want to write something a little different.
 
 
So where does this project stand? It doesn't. Currently, I'm sitting and
thinking of how to organize this. Things I need:
 
an xml file format. I at least need some basics.
 
the in-memory representation. I want this to be tightly coupled with the file
format, so that reading and writing are easy. Just having a DOM tree in
memory probably won't work. The system is too complicated. We'll have to have
a class hierarchy.
 
a class hierarchy complete enough to let me work with MIDI tracks.
 

My development plan currently looks like:
 
Version 0.01
 Initial planning.
 
Version 0.02
 Single MIDI track with a single staff
 keyboard/mouse input.
 Treble clef, 4:4 time.
  load and save file
 very simple compiler and player
 
Version 0.03
 simple MIDI patches for instruments
 multiple tracks
 
Version 0.04
 tablature staff (basic functionality)
 guitar clef (octave treble)
 
For Versions 0.05-0.09, I'd like to get in piano staff, simple wav audio (can
import the audio, read/write file info to xml, simple playback), tempos,
meters, and keys.
 
 If I can figure out how to incorporate simplified versions of Rosegarden's
recording/playback, the Version 0.1 series should allow some basic recording
of midi & wav.
 
 The goal is to have a relatively rich feature set for wav and MIDI for
Version 0.6 or thereabouts.
 
Received on Wed Feb 2 20:15:11 2005