This is the main arrangement window -- the first thing you see when
the application is started, and where the song's structure is
Down the left, we have the track numbers, along with their user-assigned
names (don't be alarmed -- the maximum track number will be something
like 256, not 33 as shown here). Text fields can be edited by moving a spreadsheet-style cursor
up and down with the cursor keys or mouse. Like practically all
sequencers, different vertical positions will represent different
tracks (I mention this because MeV deviates from the standard here).
To the right of the track names, there are the mute/solo controls.
Again (like practically everything else in this application), keyboard
shortcuts can be used to mute/unmute/solo a track, or you can click
the mute control with the mouse. Muted tracks are shown here in red --
some kind of highly-visible indicator is probably a good idea here,
especially for 'solo'ed tracks.
On the right, we have the main arrangement area. Many current
sequencers use the "tape-clipping" editing approach (made popular
by Cubase, especially Cubase Audio), with each phrase in its own
self-contained block. This sequencer does not -- it will use the more
traditional "blob-based" editing. This can save time in many
situations, and encourages non-repetitive song construction.
Each square of the grid represents a 32nd note (hemisemiquaver). The
size of the squares (and density of the grid) is determined by the
currently-selected zoom level.
The colour of each square depends on what events are in it. The
specific colour scheme is to-be-decided, and may be user-configurable.
In the above example, I've used the following colours:
- White: Empty,
- Dark blue: Note events occur here,
- Light blue: No events occur here, but note(s) are being sustained into this block from a previous block,
- Pink: Controller events occur here,
- Dark purple: Controller AND note events occur here,
- Light purple: Controller AND sustained-notes occur here.
As you can probably see, there's rather a lot of colours. Maybe too
many to be useful. I might combine some of these categories together --
perhaps three colours like this would be better (any thoughts?):
- White: Empty,
- Dark blue: Note events occur here (with or without controllers),
- Light blue: Controller events AND / OR sustained notes occur here.
Or maybe this: (personally, I'm leaning
towards this four-colour version)
- White: Empty,
- Dark blue: Note events occur here (with or without controllers),
- Medium blue: Controller events occur here, with or without sustained notes,
- Light blue: Sustained notes occur here, but nothing else.
Before anyone asks, the squares can't display any more information,
such as which specific notes are being played, or displaying different
velocities as colours, etc. Aside from making the visual clutter
worse, it would consume much more memory and CPU time to draw the
screen. For BeOS applications, this is punishable by death. It would
also make features such as smooth scrolling (while the song plays)
impossible, and could suck valuable processor time away from
other applications (e.g., multitrackers).
On the other hand, user-assigned colours in certain areas (e.g.,
marking an important area of a track red) would be possible -- any
thoughts on whether this is necessary? (I'll probably be implementing
"cue markers" in any case, which can be used to mark specific moments
in time with a vertical line down the arrangement window).
The current play position will be marked as a vertical line down the
arrangement window, with some kind of play position "handle" in the
bar display near the top, so you can grab it and move it to different
The transport can be controlled via toolbar buttons, keyboard
shortcuts (space / enter / 0 / etc.), and MIDI messages (remote
control of the transport from the master MIDI keyboard).
In the current screenshot, you can see a number of toolbar buttons.
These are carried over from MeV, so won't be present in the final
sequencer. However, there will almost certainly be a toolbar, just
with different controls (exactly which controls is to be decided,
though the transport controls will be present here).
Editing using cut+paste / drag+drop is where the differences between "blob-based"
editing (this sequencer), and "tape-clipping-based" editing (e.g.,
Cubase) become significant.
To edit the MIDI data, a certain range is selected by clicking and
dragging -- no special "selection mode" needs to be selected, because
this will probably be the only mode you can use in the arrangement
window. The selected area is highlighted in inverse-video (see the
4-bar-long, 2-track-tall selection on tracks 13 and 14 in the above
screenshot for an example). There will be a "snap" size setting on
the toolbar, allowing you to select whole bars at a time, 32nd notes,
etc. There will be some way of including/excluding tracks in the
selection, so you could, for example, select tracks 10 and 12, but
not 11. Perhaps shift+clicking another track to include it in the
Selection may also be possible via the keyboard, using the familiar
shift+cursor key method used by text editors.
Once an area has been selected, it can be dragged to a new location.
If it was dropped onto an area already containing events, the events
are merged (e.g., it doesn't erase the data it collides with).
In addition to dragging+dropping like this, standard cut/copy/paste
menu commands can be used.
If there are notes sustaining into the selected range from earlier
(e.g., a note starts on bar 17 and extends to bar 20, and a selection
is made from bars 19 to 30), what happens to these notes when you
perform a cut operation is to-be-decided. Some options I can think of:
- Leave the overlapping notes untouched,
- Cut the overlapping notes,
- Slice the overlapping notes so that part of it remains where it
was, and the "sliced" part is included in the selection,
- Determine automatically which of the above to use, based on
how far the note was overlapping (e.g., if it's the last 5% of
a note, ignore the overlap, if it's 95% of a note, cut it, if it's
somewhere between the two, slice it into two parts),
- ... Or possibly let the user decide, based on a global
preference setting. Any thoughts?
"Bulk processing" operations can also be performed in the
arrangement window. These include things such as transpose, quantize,
retrograde, etc. When these commands are selected (using a menu, or
keyboard shortcuts), all the events in the selected range are processed.
These commands will probably be implemented using plug-ins, so users
can easily implement whatever fancy commands they want (e.g., groove
quantize, vertical flip, algorithmic composition, etc.).
As per Cakewalk, all bulk-processing operations, including cut/copy,
go through an "event filter". The event filter can be turned on and
off somehow, perhaps via a menu option. Or perhaps it could ask you
each time you perform an operation? (obviously, drag+drop
operations would skip this because so common, and would annoy the
user with popups).
When the event filter is turned on, every event that passes through
the plug-in (or cut/copied from a track onto the clipboard) is
compared against the event filter. If it matches, the operation goes
ahead, otherwise the event is left untouched. The event filter can
be set to include/exclude a certain note range, velocity range,
controller range, event type, etc.
The presence of such an event filter makes the rest of the application
quite a bit simpler to use (and write), because many fancy operations
can be done easily with the event filter, without needing special
Back to the track list on the left, as previously mentioned, there
will be a spreadsheet-style cursor, which shows the currently
selected track, and allows you to edit its name.
This cursor also serves to select a track for recording -- therefore,
when a track is selected with the cursor, the track number will
probably be filled red, to show clearly which track is selected.
The selected track is also used for "MIDI thru" purposes -- anything
you play will be sent to the selected destination for that track.
Unless someone specifically requests otherwise, all recording
will take place onto one track at a time -- recording to multiple
tracks at the same time is not possible. I may allow each event
to have its own channel number associated with it, thus allowing a
track to be split into 16 different tracks (one for each channel)
after recording, but this is bordering on feature creep. Is anyone
remotely interested in recording more than one track at the same
moment in time? (seemingly this would only be necessary if you have
multiple MIDI keyboards, and wish to record several players
simultaneously... seems unlikely to me...)
To keep timing as tight as possible (excellent MIDI timing is a BIG
design requirement for this app), recording will NOT be done directly
to the track. Instead, all recorded events are stored in a temporary
area in memory, which is automatically dumped onto the selected track
when you disengage record mode (or change tracks).
As a user, you probably won't notice any side-effects of this, but
there are two things to bear in mind: Firstly, you won't see your
playing appear on-screen "live" while record mode is running -- it'll
appear as soon as you stop recording. Secondly, the record buffer is
*always* recording during playback, even when you're not in record
mode. This is potentially useful, because if you came up with a good
idea during a "dry run" (transport in play mode, not record), you can
recover it by selecting "dump record buffer" from the menu.
Something I'm not sure about yet is multiple-take recording mode. This
is where you set a section to be looped, and play many takes, over and
over again, each recording to its own track, so you can pick the best
This should be possible to implement, although it increases complexity.
I could implement a "cheap and nasty" alternative, by simply dumping
the record buffer when the end of the selection is reached,
automatically advancing to the next track, and looping. The downside
is that there will be a pause (a beat or so) whenever it loops back to
the start -- it takes a tiny fraction of a second to flush the record
buffer, but possibly enough to hear. My feeling is that this might
upset the "groove" enough during a looped recording session to make
this feature worthless, but I'd very much like your input here!
I don't use multiple-take recording very much, so I can't say how
significant a problem delay-on-repeat will be. Note: This problem
does NOT affect normal looped playback mode (no recording).
Another alternative way of making multiple-take recording simpler
to implement is to simply overwrite the previous take each time it
loops. That isn't strictly multiple-take recording though, because
you have to manually stop the transport when you think you've made
the best performance (as opposed to choosing between them later),
or alternatively, advance to the next track yourself by pressing
a key (which might cause the dreaded tiny delay mentioned earlier).
However, it's so easy to implement, I'll probably do this even if
nobody needs multiple-take recording at all.
As you can see, in addition to writing a sequencer, I'm also
writing a feature-length novel, so I'll spare you and move onto the
next screenshot now (the worst is out of the way now). =P