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

[NadaSpam]

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.