Please :)
Lisp is a dead language, it may have been perfect but New Jersey won a long time ago. Prefix notation is awkward and counter intuitive and even CS students have a hard time groking recursion (Lisp is recursive, not iterative). It would be much nicer to be able to script in a language that can be picked up and understood quickly.
 
 

I guess you could develop a CIL and then you could use any language !!! :)

True, but you might as well write your own VSTs. Not a lot of separation between the two, scripting languages should be easily understood by non-programmers. It takes a lot more code and effort to write to a CLI. An infix scripting language is a lot easier to code to than a COM interface.

CakeAlexS
I guess you could develop a CIL and then you could use any language !!! :)

Sorry I but wrote CIL not CLI. And it does not necessarily have to be COM (a la .NET framework) thing. You could adopt a variation using CAL as a CIL if you like. Any layer on top could be a scripting language. Important again ... Forget about .Net framework.

Regardless I'd be surprised of resources would be put into this...

Cheers..

Perl isn't really much of an easy language for someone not already versed Unix shell-speak. Python, maybe, but why a half measure when you could C# (ala .Net)?
 
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.
 
As I mentioned, Sony Vegas is *the* key example to follow for a commercial application. Their documentation simply list all the objects, (i.e, tracks, etc..) you can get at - and you can use any language that torques your motor.  
 
I was so impressed with how Vegas implemented there system that I implemented myself an identical system for a manufacturing test platform. It let manufacturing engineers add or modify existing tests without needing to be a language export, using nothing more than windows notepad.
 
I would think it certainly doable for CW - it's a Windows shop after all, and .Net isn't even limited to windows these days - some of the embedded product I've worked on are linux based and have .Net available for system extensions.
 
 
 
 

Really, anything other than other than Lisp would be fine, JavaScript? As long as you don't have to install anything other than Sonar to make it work. Scripts need to be exchangeable, most people aren't going to have Visual Studio installed on their DAWs.

TomHelvey
Really, anything other than other than Lisp would be fine, JavaScript? As long as you don't have to install anything other than Sonar to make it work. Scripts need to be exchangeable, most people aren't going to have Visual Studio installed on their DAWs.

Of course.
 
You don't need Visual Studio to create a .NET script, a plain text editor works fine - because the scripts are text, there is no 'compile' step, and scripts are used by the application in text form - text is about as exchangeable as it gets.
 
Many folks might be under the impression that you need to be a sort of big-time programmer to use .Net in a scripting scenario, but nothing could be further from the truth.
 
There's quite a lot misconception out there about what .Net is, how it's put together, and how it can be used. A lot it is due to incorrectly applying traditional compiled/linked language concepts to it. 
 
 

For a million reasons, most of which should be obvious.
Lisp is dead and buried, all the kids hack Python these days. Seriously, Python is easy to learn and using a tool like boost::python, the bakers could easily make the scripting API much more powerful and robust, not to mention maintainable.
Python is ubiquitous for scripting and automating things like DAWs and your living room, the entire Ableton control surface API is written in Python. If you want to hack your Push, you can decompile the control surface libs and tweak away.
There are myriad reasons for supporting scripting in DAWs, re-implementing the scripting interface in Python would future proof Sonar for at least a decade while endearing it to power users.
 

TomHelvey
Lisp is dead and buried

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...
 

all the kids hack Python these days.

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

... boost::...

A collection of nice theoretical concepts projected into practice... I was born in USSR, I know how it ends.
 
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.

An interesting discussion but to no avail as CAL has been deprecated. Once Cakewalk decide to remove the remaining functions in place of some newer function that requires it, then say goodbye to CAL forever.

It's a shame.