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.
