Replace CAL With Python

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.
 
 

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 !!! :)

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.
 
 
 
 

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. 
 
 

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.

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. 

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.

See post #7.

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.

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

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

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 think from the available evidence, that this is Cakewalk's perspective as well.

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.