Suggested CAL upgrades

Even at this time, CAL did not keep up, because once clips were introduced, CAL could no longer be counted on to process events sequentially in a track -- it would process one clip at a time, in unpredictable order. As new types of events have been introduced, starting with audio, CAL has become able to recognize them in the Event Filter commands and conditionals (see Web page documenting this enhancement, which is not documented in Cakewalk manuals), but has not been upgraded to allow inserting them or processing their parameters. CAL remains a tool which is most useful for processing MIDI events; it could be far more useful if it also processed other types of events. But CAL has its weaknesses even with MIDI --

IMPROVING MIDI PROCESSING

Recognize and process xRPNs

Recent versions of Cakewalk software. have automatically read and displayed RPNs and NRPNs. But this capability makes it impossible for CAL to process the RPNs and NRPNs, as it no longer recognizes them as controller data. Reading and writing RPNs and NRPNs.is important, for example when processing pitch wheel events, because an RPN contains the information about the pitch bend range.

Read and write SYSEX and SYSEX BANK data.

With this ability, CAL could, for example, translate SYSEX commands between instruments.

Read (not only write) track parameters

CAL should be able to read (not only write as at present) track parameters. Examples: controllers on the same channel in different tracks conflict only if sent to the same port, but CAL presently is blind to which port they are being sent to. Controllers on different channels conflict only if the track is forced to a channel, but CAL has no way of knowing whether it is forced. Etc.

Count events

Programs could run faster if CAL had constants giving the number of events 1) in the selection and 2) in a track -- useful when using a forEachEvent loop to compare events. There is a workaround -- using ar forEachEvent loop to count the events. But this is slow.

Read and write tempos

CAL should be able to read and write tempos and the musical times at which they occur. In other words, treat tempo messages as events like any others. The only way CAL can adjust tempos now is by working backward using commands such as Fit to Time and Fit Improvisation, or by cutting/copying and pasting.

Read and write time signatures

CAL should read and write time signatures.There is a workaround for this, but it is very cumbersome.

Specify track when inserting events

CAL should allow the user to specify the track into which to insert events. Getting events into the desired track often requires working backward from the arbitrary rules which CAL now imposes.

Identify and compare markers

CAL should be able to find markers, and compare marker text with a text variable.

AUDIO-RELATED UPGRADES

Store and retrieve audio clips

CAL should read and write audio clip paths and filenames, so it can store and retrieve audio clips.

Identify length of audio clips

CAL should know the length of audio clips so that it can determine, for example, whether they overlap, and can apply the Length command intelligently to them.

Read and write audio event parameters

Cal should read and write audio envelopes, audio event velocities, and audio event peak levels so they can be adjusted, stored and compared.

Support audio mixdowns

Audio mixdowns should be supported in CAL.

SUPPORTING ADDITIONAL EVENT TYPES

Read and write dynamics markings and hairpin text.

With this capabillity, for example, these could be automatically generated from controller data, and vice versa.

Read and write guitar chords.

With this capability, a CAL program could be written to insert chord symbols automatically based on MIDI notes, and vice versa.

Read and write lyrics.

Read and write TEXT and LYRIC strings (would allow conversion between Cakewalk Lyrics format and Karaoke text).

TO MAKE PROCESSING EASIER AND MORE FLEXIBLE

Support real time, not only musical timing

CAL should be able to read and write events according to their real time (not only musical timing, as at present). There is a workaround through insertion of MIDI events at second or frame times  as markers, but the workaround is very cumbersome, slow and inexact.

Copy to scratchpad

Copy the selection to a scratchpad location where it can be processed including making new selections within it. Then when processing is done, copy it back (There is a workaround, shifting the selection past the END time, but the workaround is cumbersome).

Allow work with more than one file

By working with more than one file at a time, CAL could use one of them as a scratchpad, or could compare them, concatenate, etc.

Support functions

Functions, with parameter passing, would allow variable names can be reused and CAL programs to be ocnstructed from a library of modules. The present include command does not pass aprameters, and sovariable names can not be resued.

Support tables

Table support wold make it possible to store and process all RPNs, NRPNs or controllers (for example) in a single step instead of one at a time. The SWITCH command is as close as we get now to a table in CAL but it is limited to 122 statements, -- but there are 128 controllers, keys etc. (so near and yet so far...) As there are 16384 RPNs and 16384 NRPNs; processing them sequentially would be very slow (even if CAL could store their parameters, which it can't), and it is not possible to store values of all of them at once. Supporting tables in this way is essential, for example, in using CAL to do a searchback before doing a copy, cut or paste operation.

Sequential processing regardless of clips or tracks

CAL should allow processing sequentially by time of all events in a selection (regardless of track); or of events in each track sequentially by time; or by clip, as at present. forEachEvent loops which compare events often now require combining clips (and even tracks) in order to process events in time sequence. Combining clips and tracks destroys useful information.

Optional single step in History list

The ability to step backward and forward within a CAL using the History list is a very important debugging tool.

But once a CAL has been completed, having it recorded as a single step in the History list would be much more convenient. Complicated CALs that operate sequentially on multiple tracks or channels may take hundreds of steps. Though the History list can be lengthened to accommodate them, finding the first step of the CAL takes time; and the computer takes time to undo the many steps. When the History list is full, processing both inside and outside CALs slows down substantially, because the oldest editing steps must be deleted. And there is no ability to return to the steps which have been deleted, except by quitting the file without saving..

EDITING AND DEBUGGING IMPROVEMENTS

Error locators

CAL presently has error messages that explain what a problem is but provides no help in finding it. Improved debugging aids should include

• An unmatched parenthesis finder:, to find where parentheses are unmatched inside a line. If the line is part of a conditional or loop, the finder accounts for the deferring of a parenthesis to the end of the loop.
• An incorrect number of arguments finder, which indicates which statement has the incorrect number of arguments. The present message is, for example: "incorrect number of arguments: +".
• Other, similar tools.

Improved scrolling

Automatic horizontal scrolling to the left margin should not occur when extending the selection upwards or downwards. This behavior is very annoying when working on indented code.