While it's obscure and old, CAL as it is right now does things that no other daw can do (afaik).   Cubase's 'logical editor' can do some of it, but not all.    And it is far from lisp as a language!    I seriously doubt if it can handle recursion, though I've never tried.   It just a simple thing that takes arguments in the order you give them (prefix or reverse-reverse Polish, maybe).   And since you can set a key command to a specific CAL program, it can be lightning fast to do.  Cubase takes a good while to get your 'presets' found and set so the things I do in half a second take 30 seconds, and disrupt the flow of work. 

azslow3
Old, proved by time and standardized solutions will be dead once there is a change in computer architecture, which has not happened during the last 60 years...

Name one application in current use written in Lisp or Pascal for that matter.

azslow3
Modern, out of concept non standardized solutions are good for kids... only.

Python is widely used and supported on virtually every platform. It's been around for years. Even old people can learn it easily.

azslow3
A collection of nice theoretical concepts projected into practice... I was born in USSR, I know how it ends.

Most of the production code I've worked on over the last 10 years or so has used boost in some capacity. A lot of it makes it into the std library.

azslow3
I think the problem of CAL is not the language but underlying connections to the features in SONAR introduced since CAL was revised for the last time.

Exactly my point about maintainability. It's much better to have a compile time failure when an incompatible change is made than a run time failure.
 

SuperG
Using .NET as a scripting interface is quite smart, because scripting can be as easy or as involved as desired. The quintessential example of a application using .Net for scripting is Sony Vegas. You don't need a compiler, just a text editor. You don't need to be a .Net expert either, and you can use VB as your script language if that's what floats your boat.
 
It has it advantages, .NET, for scripting, over a roll-your-own language, or even something like python. In those cases, you still need to expose the application internals variables and/or functions you want to be scriptable, both through the language and into the application's internal representation. you'll likely need to some memory management as well, plus some level of error handling, both syntactical and run-time.
 
A .Net scripting interface handles most all of that automatically, removing a whole lot of concerns for the scripting system developer. The basic job becomes simply exposing internal objects as .Net interface objects, nothing more.
 

 
Makes so much sense.
 
But you know, however Cake implements it, we really need a new scripting interface to replace the dead CAL. This is actually one of the star features of some DAWs like Bitwig with its javascript API. Many have jumped in w/ controller support, etc.

Correct me if I'm wrong, but wouldn't a .NET scripting interface require a user to drag in Visual Studio and all the bulk that implies?
Whatever language is used, a scripting API has to be usable with just Sonar installed.

See post #7.

In making the decision to deprecate CAL I can't see Cakewalk now turning around to say we're going to open it up to language such and such for scripting. I wish there could be a different outcome.

My question to all you programming guys is, Is it feasible or even possible for that matter, for Cakewalk to go in and create the hooks for a new scripting interface when they weren't prepared or able to keep up the old one?

mudgel
My question to all you programming guys is, Is it feasible or even possible for that matter, for Cakewalk to go in and create the hooks for a new scripting interface when they weren't prepared or able to keep up the old one?

For programmer who knows what he/she is doing (I mean with an experience of writing interpreters/compilers, "python kids" are not helpful in this case) I estimate 1-2 weeks to make required hooks from existing, independent in which form they currently are. Cakewalk was experienced in that area in time of MFX and Control Surfaces API. But either the person who did that back in time or comparable skilled another one is still available is a questions...
 
@Tom. I am not going to begin "old school" against "new school" war here. If you have ever written any interpreter, you should already understand my (subjective) point of view, and it will take to long to explain the reasons otherwise.

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.

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.

This is an investment you need to make. The API will open up all kinds of possibilities for Cakewalk, internal and external in terms of cross-product functionality, s/w to s/w, s/w to h/w. And all of this will drive Cakewalk sales.
 

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.