My suffering is vast, but not due to CAL.  Although most of my stuff is audio, I find that the CAL "undup" capability is quite useful when dealing with Addictive Drums editing, especially when layering fills.  Sometimes you get a doubled snare hit that goes "whack whack whack WHACK whack".  Sucks hunting those down manually, especially if you wind up somehow with hundreds.

Never used CAL it any other scripting as it relates to creating music.

Very few musicians care about such things let alone how to use the tool.

rogeriodec
 
Right. I know Python. Do you know how to communicate Python With CbB?

The short answer, for all practical purposes is, you can't.
 
There are currently two ways of communicating with Sonar/CbB:
 
1. As an Audio VST or MIDI VST (e.g. AzLua is implemented as a MIDI VST)
2. As a custom control surface through the ControlSurface API.
 
For what I think you want it for (i.e. manipulating MIDI data), AzLua is about as close as you'll get to having MIDI control outside CAL, but in the end it's just a MIDI effect, so you'll have to live with the limitations of what a MIDI effect can do.
 
Outwith the usual control surface operations, the most the control surface API can do is invoke key shortcuts and menu commands - basically anything you could assign a hardware function key to. But manipulating MIDI data at the event level, it can't do. Also, unlike CAL, none of the cakewalk "commands" are parameterised, so many of them will use default parameters or pop-up a dialog.
 
What the control surface API can do however, is run CAL scripts. So in theory, you could programmatically translate parts of the LUA/Python script into a temporary CAL file, then run that in the background.
 
Getting information out of the CAL program is tricky though... My thoughts around this were that since the control surface DLL is already loaded, invoking a CAL DLL command on the same DLL to store any results would allow the results to be available to the rest of the LUA/Python script.
 
 
Doing any of this is a huge job though, as you'd basically have to:
1. Write a completely new Control Surface DLL
2. Embed Python or LUA into the DLL
3. Find some way of overriding/implementing new Python/LUA functions to call the Cakewalk API functions
4. For any loops, translate them to CAL
5. Deal with all the parameter passing / external file creating & locking / DLL loading & unloading issues.
 
None of the above is trivial.
 
So unless BandLab provide a new API (or extend the Control Surface API) to allow direct access to the track/clip data, and extend the command invoking to allow parameters, I doubt if anyone would want to take this on.
 

we don't know what any of bandlab's plans are, or even if they have any

Quite a few years ago it was announced that CAL was being being deprecated. Can’t find the appropriate reference; sorry

Deprecated according to techterms.com

In the world of software development, "deprecated" refers to functions or elements that are in the process of being replaced by newer ones. The term comes from the word "deprecate," which means to disapprove of something. While deprecated items may work in the current version of a programming language, they may not function in future updates. Therefore, software developers are advised to replace deprecated items with other options.

Midi would be enhanced by means other than a scripting language.

mudgel
Quite a few years ago it was announced that CAL was being being deprecated. Can’t find the appropriate reference; sorry

Deprecated according to techterms.com

In the world of software development, "deprecated" refers to functions or elements that are in the process of being replaced by newer ones. The term comes from the word "deprecate," which means to disapprove of something. While deprecated items may work in the current version of a programming language, they may not function in future updates. Therefore, software developers are advised to replace deprecated items with other options.

Midi would be enhanced by means other than a scripting language.

This isn't always the case. Deprecated means that it might continue to work, but isn't being developed or supported any more, and at some point may be removed. Although this can mean that is might be replaced by something new, this isn't always the case.
 
Noel posted something here: http://forum.cakewalk.com/tm.aspx?m=1886350&mpage=1  indicating CAL was deprecated as far back as 1999. 

Brian Walton
Never used CAL it any other scripting as it relates to creating music.

Very few musicians care about such things let alone how to use the tool.

I can see with you. It seems like the OP assumes everyone knows the scripting. I use MIDI. It is the purpose I use the DAW. I have even used some of the available CAL but have never tried to understand how they are built.
 
Then too, is the future development of the MIDI specifications, aka MIDI 2. CBB has to implement this first, after which some kind of 'Scriptures' can then fill in any weakness or imaginative concepts.

msmcleod
Noel posted something here: http://forum.cakewalk.com/tm.aspx?m=1886350&mpage=1  indicating CAL was deprecated as far back as 1999. 

Wow, last Noel's post about CAL is 2009... 
I just do not understand why they do not invest in a user-friendly script interface.
As I said, this is a practice that can unlock the queue of bakers' tasks, at the same time making the software evolve with the collaboration of all users.
That is, it is a win-win relationship.

Usually avoid this type of thread because it not something users can do anything about. Few facts, a lot of opinions/speculation (this post is no exception) and I do not believe in the unicorns and rainbows promised by the OP.
 
As someone who has cut their share of code, I can say it would be nice but...
 

rogeriodec
As I said, this is a practice that can unlock the queue of bakers' tasks, at the same time making the software evolve with the collaboration of all users.

Saying it does not make it so. Creating a new scripting system is not a simple task which given the limited development resources would impact other development. Once created it would be another piece of CbB that must be maintained placing a further drag on development not to mention QA and Support. It is not write once and done. CAL is proof of that. 
 
Is there any evidence that all users (your words not mine) would collaborate, use or even care about this? There are many more threads where users complain about having to perform computer tasks instead of being musicians. My take away from that is most users do not want to program their computer. They would rather have performances captured by the DAW and have tools to work with the data NOT create their own tools.
 
CAL and scripting do get mentioned in the forum but not that often. Sure, one could say it is because CAL development stopped around 2000 or the choice of language used as the basis of CAL is not very popular. There was a reason CAL was deprecated 18 years ago. My guess is for the same reasons there is little chance of a replacement: it was difficult to maintain, provided low return on investment, many of the commonly used scripts were replaced with built-in features and MFX plug-ins.
 
If I were looking for a programmatic solution to MIDI manipulation today, I would probably write my own tools around MIDICSV since I could use any spreadsheet as an event viewer.

Brian Walton
Never used CAL it any other scripting as it relates to creating music.

Very few musicians care about such things let alone how to use the tool.

That's entirely not true.
 
I have no idea about programming languages yet CAL scripts saved me loads of hours of MIDI editing so many times.
 
And I hope for more.