CAL - Cakewalk Application Language

For those of you who use Sonar, there is a pretty well hidden gem, CAL, which is an event-processing language that allows extending SONAR with custom editing commands. You get to the CAL scripts by clicking Process>Run CAL or CTRL-F1.

Doing so gives you a list of CAL Scripts that shipped with Sonar (and maybe some you added).

So what do you do with this list? First of all, notice that some of the file names are in all CAPS and they are no longer than eight alphanumeric characters followed by the .cal. This means many of these scripts were written back in DOS Cakewalk days when a file name could not be longer than eight characters.

It may also mean that the CAL no longer works because Cakewalk has broken CAL over time, and they no longer actually support it except to include what is old code for backward compatibility.

For those of you familiar with Cubase, CAL is the Cubase Logical Editor on steroids (when CAL works in its present state).

Many Sonar users think CAL is merely a macro capability. It can be that, but it can manipulate data based upon the state of that and/or other data.

How do you find out what one of these CAL's with cryptic names do? They are merely text files with a .cal extension (instead of .txt). You can open the list of CAL files (as explained in the first paragraph), right click on one of them and open it with Notepad to read the comments by the author.

A CAL script works like any of Sonar's built-in editing commands. You have to select the data you wish to be edited [track(s) and time selection (From and Thru)].

One of the shipped CAL scripts is named "ANY_THIN.CAL." If you right click on it and open it in a text editor, you'll see Marty Schor wrote it to thin controller data based upon the change from one controller value to the next. You, the user, chooses which controller you want thinned and the minimum difference you want between two consecutive controller values. This is much better than just deleting every 2d, 3d, 4th, so on controller value. It keeps the data smoothly changing in keeping with the original shape of the controller data (the visual representation in Sonar). This CAL still works -- I just tested it.

Why would you want to thin controller data? Maybe for reasons unknown a lot of controller data causes glitches in playback on a VSTi or hardware module. You can thin the data and see if that removes the glitches.

In case there is a problem with undoing a CAL command, you should always work on a copy of the track you run a CAL on. I've not lost data due to CAL, but it could happen.

So, think about this: How would you do what ANY_THIN.CAL does if CAL were no longer supported in Sonar? Any method I can think of would certainly be extremely time consuming.

Yes, it could be built in to Sonar.

But how about this? You have a stringed instrument VSTi. It allows setting a capo to any of 24 frets plus Open -- no capo. It accepts key-switch data or Controller 4 data to set the capo. You don't know the final key of a song you're working on, so you decide not to use key-switches so you won't transpose them when you transpose the key data on that VSTi's track.

The capo position chart in the VSTi docs gives the CC#4 values for each fret. You have a lot of fret changes. So you start inserting Controller 4 data in multiple places, each time having to check the position chart for an appropriate value. You use this VSTi a lot. All of this gets very tedious. Macro software won't help you here. How will it "know" what values to insert for proper capo placement?

Here's where a CAL script can really help. Reading this script in Notepad, it says you should run it in Event View for the track(s) you want to use it on. You click on the first note you want the capo to affect. You also select the note to set the From/Thru times for that note (click in the leftmost column of Event View on the same row as the note and the cell turns black).

Now you CTRL-F1 and double click FretInsert.cal. It opens a small window with "Capo at which fret position? (0-24)." you enter 8 for the 8th fret. Blam, a Controller 4 event with a value of 43 is inserted one tick before the note you selected.

How does this work?

Using a CAL function called "switch," the script finds the appropriate controller data based upon your capo fret selection. Say "FretPosition" is the variable that stores the user's input and "FretPositionData" is the controller 4 data required to set that fret position. Switch takes the value of FretPosition, looks that value up and sets FretPositionData to equal the controller data for that fret.

(do

(switch FretPosition ; set the CC# 4 data value for the chosen fret position
 
  0 (= FretPositionData 0)
1 (= FretPositionData 3)
2 (= FretPositionData 9)
3 (= FretPositionData 15)
4 (= FretPositionData 20)
5 (= FretPositionData 26)
6 (= FretPositionData 33)
7 (= FretPositionData 38)
8 (= FretPositionData 43)  <<< The user entered 8 so switch ran this function
9 (= FretPositionData 47)
10 (= FretPositionData 53)
11 (= FretPositionData 58)
12 (= FretPositionData 64)
13 (= FretPositionData 69)
14 (= FretPositionData 74)
15 (= FretPositionData 79)
16 (= FretPositionData 85)
17 (= FretPositionData 91)
18 (= FretPositionData 96)
19 (= FretPositionData 103)
20 (= FretPositionData 108)
21 (= FretPositionData 114)
22 (= FretPositionData 119)
23 (= FretPositionData 124)
24 (= FretPositionData 127)

)

; now insert the event one tick before the Now time (which the user set when he/she clicked on the note in the Event List.

(insert (- Now 1) Event.Chan CONTROL 4 FretPositionData)

(- Now 1) is the computereze version of  Now minus one (Now - 1).
Event.Chan inserts the selected note's channel for this controller event.
CONTROL means insert a controller event.
4 is the controller number to insert.
And FretPositionData is the value that switch looked up -- 43 in this case.

This is explained only to show you how powerful and time saving a CAL script can be.

And I'm not an expert on CAL -- I hack the code/test it/hack it/test it and so on seemingly out to infinity before I get a script to work.

There are a lot of CAL scripts on the internet. If you decide to try some of them out and they work or do not work, post a message here with the name of the file. Maybe there are some that do not work but are worthy of editing so they do work. Maybe others should be tossed because they do not work any more.

For those of you reading this who do use CAL, please post a reply and let us know which scripts you use. Also, if you know of some that do not work, post that too.

Maybe a fire can be built under Cakewalk so they will bring CAL back in a big way, with great documentation for its use. Else it will certainly be well behind Reaper SWS and Cubase Logical Editor.

Right now CAL is like a map based computer game that doesn't have a fully working, updated map editor, but it can still help do things with CAL that no other DAW I know of can do. SWS (for Reaper) may be able to do it, but I didn't see anything like it mentioned in the SWS docs.

For those of you who write your own CAL scripts, I learned the hard way that you cannot insert data where no clip exists. This means even between clips. The insert goes into limbo. Also, there is already a documented problem working with CAL and Linked Clips

For documentation on CAL, do a search for "Cakewalk Application Language Programming Guide for Sonar." The latest I've found is version 2.2 (24 FEB 2010). There's other documentation out there, too.You won't find any documentation like this in Sonar's help file.

Thanks to Glen Gardenas, Ton Valkenburgh and Frans H. M. Bergen for putting the CAL info together!