Ok, a more modern scripting interface would be great.   It's just that there are (at least on my computer) a large number of 'legacy' programs in CAL; if they no longer worked I would no longer use Cakewalk.   Tom Helvey, you keep saying "lisp" ... if you know Lisp and if you know CAL (and I have to believe you don't know either one) ... well, they are way way way far apart. 
 
Just joking here: but the closest CAL could come to lisp would be something like:   (DO (DO(:O))
 

KPerry
Marginally, surely? I don't think there are enough users who want to get their hands dirty or developers who want to develop for one platform (vs, say, VST) to make the signficant investment in time worthwhile.

+
It is more about customizable processing scripts then VST, but the number of active developers is easy to find looking at MFX plug-ins and Control Surfaces (these API are available since ages).
 
I think the point at which all opinions intersect is the possibility to continue using scripts in the future. Either Lisp/Python/C# or something else is not so important (who can write in one programming language can write in any, they are not so different as human languages...).

Yes it would be CAL++ but the biggest win would be controller support. 

Isn't it 'just' iScriptable (memory?) that it needs to expose? Then one could use JScript and VBScript out of the box, and you can get PythonScript I believe (have to say though, I know of no developers using Python - C#, VB, Ruby, JavaScript, Java but not Python) or even PerlScript if you're feeling perverse.

That said, I think a better use of the Bakers' time would be to identify the (say) top 6-10 functions that people use CAL for (deduping notes is an obvious one), make them native functions and then drop CAL: supporting and testing, let alone enhancing, a scripting environment is always going to be difficult and not a good ROI given the environement/market.

Please Kperry, that's a basic misunderstanding of CAL (not surprising since it's such an obscure thing).    But "top 6-10 functions" implies that people use the few legacy default cal programs.   So to follow that with, "and drop CAL" ... well, imagine your favorite reason for using Sonar being "dropped"?  You wouldn't like that.      My "top 6-20 CAL functions" are all written by me, and no one else knows anything about them, except the one or two I've posted here.   Just to give an idea, I believe Sonar ships with under 40 cal programs, and I have about 80 in my CAL folder; I use exactly 0 of the shipped CAL programs (though I've used some of them as templates for other programs).
 
Some of the things CAL can do:  set all midi events selected to a given channel; change a set of program changes into a different set of program changes; change program changes to keyswitches; change keyswitches into program changes; set pitchwheel values by key major or minor; change program changes for one VST to program changes for a different VST; change keyswitches for one VSTi to  keyswitches for a different VSTi; assign key switches by note distance; assign legato program changes by note distance and difference in end to start time;  adjust velocity by a variety of curves; adjust controller values by a variety of curves; delete all of a controller; delete all of pitchwheel; delete all program changes; add default program changes for each note; divide according to various criteria into midi channels;  ...
 
 

I appreciate that losing those would be something of a pain (to put it mildly), but in the grand scheme of things, I think that trying to support a scriptable interface is so much work (complexity/keeping up-to-date/bugs/chance of data loss) that the least bad solution *on average* is to deprecate CAL and replace the most commonly used functions natively.
 
Yeah, it'd suck if you're badly affected, but I believe the net result would be beneficial.

I think from the available evidence, that this is Cakewalk's perspective as well.

given we're a windows-centric bunch, and ignoring Noel's issues with exposing an API, my preference for scripting would be PowerShell :-)

Noel Borthwick [Cakewalk]
The root problem is not replacing CAL. It is exposing the object/document model to the outside world. 
Designing and exposing an interface to all the internal objects is the main job here. Choosing a scripting language to access that is secondary. Obviously CAL itself is obsolete and inappropriate.
I've wanted to do this since I joined Cakewalk but its a big project and its been difficult to justify spending resources on since we have a big pipeline of things to do.

I'd imagine the demand isn't very high for this, but what demand is there is high. But writing APIs for the vast features/functions of Sonar can't be easy at all. 

KPerry
I appreciate that losing those would be something of a pain (to put it mildly), but in the grand scheme of things, I think that trying to support a scriptable interface is so much work (complexity/keeping up-to-date/bugs/chance of data loss) that the least bad solution *on average* is to deprecate CAL and replace the most commonly used functions natively.
 
Yeah, it'd suck if you're badly affected, but I believe the net result would be beneficial.

Yes - but what if YOU'RE badly affected. The same sort of argument is propagating around things like notation view - that Cake should spin off a special version to get Notation OUT of SONAR. I'm like the Hulk when I'm mad - all green and nasty. To me "membership" implies something more than "we make it, you buy it". A reasonable position (to me, and maybe it's a bit naive) is nothing comes out . Build on what's there. Yes put in something new to replace CAL, but leave CAL itself in place until it is truly unmaintainable. Pulling it out to replace it with something that is 75% as complete is, IMO, a mistake.