[contact John S. Allen by e-mail]

Bikexprt.com Web site

Cakewalk software lets you send data from more than one sequencer track to the same MIDI channel of your synthesizer. When you do this, the latest message, no matter on which track, always takes control, and as a result, you may have wild, rapid changes in volume, pitch or other characteristics of the sound. Cakewalk lets you generate these conflicts in two different ways:  

1. Each track sending messages to multiple MIDI channels: You can input and output data on any MIDI channel to and from any Cakewalk sequencer track. Controller data on one track can affect other tracks, since Cakewalk makes no attempt to find and resolve conflicts between controller data on different tracks. Cakewalk also provides no guide to which controllers and which MIDI channels are active on a track.
   
   Each track supports 16 MIDI channels. Since there are over 120 controllers for each channel, you have over 2000 locations for controller data in each track without any way to find the active ones other than to open up Cakewalk's event list view. Looking up this information in the event list view is like reading a debugger dump of your disk directory, when you would like to see a directory tree instead.
   
2. Multiple channels on the same track forced to the same MIDI output channel: You may select Cakewalk's option to force output from a track to a single channel. This does make your controller data work on notes recorded in the same track but in other channels. All the data on the track -- notes and controller data alike -- come out in the same channel. But this approach prevents you from using more than one MIDI patch per track, and controller data no longer has to be in the same MIDI channel -- only in the same Cakewalk track -- to generate conflicts.   

Cakewalk 5.0 controllers view -- thousands of locations for data but no directory

The drop-down list below
selects which of the over120
MIDI controllers per channel is
edited in the window.

The drop-down list
below selects
the MIDI channel,
1 through 16.

|
|
v

|
|
v

^
|

The two arrows
above select the
Cakewalk track
viewed in the window.

The underlying issue that leads to all of these problems is that most Cakewalk cutting and pasting functions only move MIDI data around, rather than being able to modify the data. This is a problem which runs all through the program design of Cakewalk: Cakewalk can move MIDI data from one track to another, since tracks are structures within Cakewalk itself. But Cakewalk can not as easily move data from one channel to another, since the channel address is stored in the MIDI data rather than in the Cakewalk track structure. Changing the channel allocation of the MIDI data would require actually rewriting the data, which Cakewalk does not do easily.

Musically, the distinction between MIDI data and Cakewalk structures doesn't make good sense. About all you can do to avoid it is to keep all of the data in each track on one MIDI channel as much as possible. But how should a sequencer handle MIDI channel assignments to avoid these problems, and for maximum flexibility and ease of use?

Track allocation as I would like to see it done

 Input into the sequencer would be allowed on as many MIDI channels as the input device(s) support. But then, the user would be allowed to group the MIDI input data into tracks at will and move it between channels. (Cakewalk already lets you record on multiple channels, only it limits your options in dealing with the input data.)

 There are different reasons to send on separate channels. A guitar synthesizer, for example, must send on six channels to support independent controller data for the each of the guitar's six strings. Despite this, all six of the strings ought to appear as one instrument in the same sequencer track, so they display in the same piano roll view and staff.

 Or you might have several instruments that you want to group on the same track -- a slide trombone section, for example, where you want to use different pitch bends; maybe you also want one of the trombones to be muted, so it will require a different MIDI patch. But you still want the whole trombone section to display in one staff, one piano roll pane and one controllers pane.

 Actually Cakewalk does let you put data from multiple MIDI channels into one track, but neither its Piano Roll View nor its Staff View has any way of showing you which notes belong to which channel. And in the controllers pane, you can only select one MIDI channel at a time. There just isn't room on the screen for 16 panes, one for each channel.

Appropriate use of color in the display

One good approach to these problems is to color code the display. Several sequencers (for example, Mark of the Unicorn Freestyle) color code the piano roll and controllers panes. I do not know of any sequencer program which color codes its staff view, though Passport Designs Encore, a notation program, does use color coding for notation. In my opinion, Piano Roll, Controllers and Staff views all would benefit greatly by being color coded. (This is being done for Piano Roll View as of Cakewalk 9).

 With a guitar controller, color coding would let you instantly see which string a note or controller function belongs. You could place all of the data for the different channels in a single controllers pane, as Freestyle does.

 What I describe is not exactly the same as Freestyle's metaphor of MIDI channels as "players." Logically, the same "player" works all six strings of the guitar, yet the six strings are input to and output from the sequencer on different MIDI channels to allow independent controller functions and/or different patches. While the six guitar strings are logically grouped together in one piano roll and in one staff as a "player," each MIDI channel in a trombone section, for example, does correspond to a different "player." The software should provide the option to group input MIDI channels into "players" or "instruments" at will to reflect such varying realities. Then, the software should let you group "players" or "instruments" onto tracks, which correspond to staffs in a staff view. Color coding makes all of these options practical.

 Editing functions also should let you move data from one channel to another at will by cutting and pasting, or even more elegantly, by clicking the appropriate color in a palette color-coded the same as the data in the piano roll, staff and controllers panes. If moving data to a different MIDI channel results in conflicts in controller data, the program should alert you and then give you the option either of creating a new channel to resolve the conflict, or resolving it manually.

Another, related controller issue is the ability to mix multiple inputs to a single MIDI controller: for example, a global volume setting could be combined additively with local crescendos and diminuendos. Cakewalk does not provide this feature: the volume setting in track view, for example, is active only until the first volume control message in the track. This problem and its solutions are described in another article on this site.

 The channel/track allocation issues discussed in this article are separate from, and should not be confused with, the issue of dynamic voice allocation at the output of a sequencer, which allocates output channels only as needed. This feature automates support by a synthesizer of more MIDI voices than the synthesizer has channels, as long as the number of voices playing at one instant does not exceed the number of available channels.  

[contact John S. Allen by e-mail]

Last revised 18 October 1999