2016/05/02 15:05:56
TheMaartian
No "COBET" (advice; advise = консультировать) here, just something funny I've posted before...but it fits with this convo.
 
 
THE PROGRAMMER'S QUICK GUIDE TO THE LANGUAGES
 
The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you're currently using. This handy reference is offered as a public service to help programmers who find themselves in such a dilemma.
 
 
TASK: Shoot yourself in the foot.
 
C: You shoot yourself in the foot.
 
C++: You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
 
FORTRAN: You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue with the attempts to shoot yourself anyways because you have no exception-handling capability.
 
Pascal: The compiler won't let you shoot yourself in the foot.
 
Ada: After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover you can't because your foot is of the wrong type.
 
COBOL: Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be re-tied.
 
LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...
 
FORTH: Foot in yourself shoot.
 
Prolog: You tell your program that you want to be shot in the foot. The program figures out how to do it, but the syntax doesn't permit it to explain it to you.
 
BASIC: Shoot yourself in the foot with a water pistol. On large systems, continue until entire lower body is waterlogged.
 
Visual Basic: You'll really only appear to have shot yourself in the foot, but you'll have had so much fun doing it that you won't care.
 
HyperTalk: Put the first bullet of gun into foot left of leg of you. Answer the result.
 
Motif: You spend days writing a UIL description of your foot, the bullet, its trajectory, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.
 
APL: You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.
 
SNOBOL: If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.
 
Unix:
 
 % ls
 foot.c foot.h foot.o toe.c toe.o
 % rm * .o
 rm:.o no such file or directory
 % ls
 %
 
Concurrent Euclid: You shoot yourself in somebody else's foot.
 
370 JCL: You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.
 
Paradox: Not only can you shoot yourself in the foot, your users can, too.
 
Access: You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.
 
Revelation: You're sure you're going to be able to shoot yourself in the foot, just as soon as you figure out what all these nifty little bullet-thingies are for.
 
Assembler: You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
 
Modula2: After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.
2016/05/02 15:37:58
azslow3
My personal favorites are:
 
TheMaartian
C: You shoot yourself in the foot.

Because that is logical...

Pascal: The compiler won't let you shoot yourself in the foot.

Because that is wise.
 

FORTH: Foot in yourself shoot.

Because in Russian language it is almost always possible to change the order of words without loosing the meaning


Assembler: You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.

Because I can have fun implementing even so stupid tasks
 
2016/05/02 17:39:24
azslow3

John Joseph [Cakewalk] gave a Thumbs Down (-1) to your post

John Joseph [Cakewalk]
Hehe, yeah that's fair. I just got irked by the casual dismissal of python as something for children. And unfortunately we live in a world of deadlines and bills to pay...

I pay your bills (I am your customer) and somehow do your job. And you just gave "a Thumbs Down". That does not sounds fair for me...
 
Please do not worry, I understand what you mean. That is just a black Russian humor
2016/05/18 17:56:56
thx1200
azslow3
MIDI manipulation scripting:  http://www.azslow.com/index.php/topic,286.0.html
It is Lua based because one user has promised at least test it, he did not.
 
Almost everything CS SDK allows, in interactive IDE form, with MIDI, TTS, Joystick and OSC: http://www.azslow.com/index.php/topic,7.0.html
 
Exists for quite some time, free to use. In practice used by ~2.5 man... At least I have managed to reduce the number of complains about not existing surface support and MIDI scripting. Once something exists, there is no more reason to continue complaining. Not that "authors" have ever try to use all that... prove me wrong
 




I don't know when I'll have time to play with this, but this project excites me.  It's not quite like being "inside" Sonar with an integrated scripting language, but there looks to be a lot of potentially useful applications here.  I'll need to learn LUA.
2016/05/18 18:03:20
thx1200
John Joseph [Cakewalk]
...
 
Furthermore, take a look at the Maya and Blender. Because those programs expose a well documented python API and a console directly into the program, users are able to script operations and even plugins. This has done wonders to grow the communities surrounding those programs while increasing their power and flexibility. I don't know what I'd do if I couldn't write Python scripts for Blender...
 
I'm actually very interested in this, and I have written a Python-C++ interface using template metaprogramming and the c standard library (albeit the very very modern iteration of it, I think you need c++14 to compile.) It's in a very infantile stage right now, but I hope to clean it up soon:
https://github.com/mynameisjohn/PyLiaison
 
With all that said, and putting back on my Cakewalk cap, I agree with Noel that this would be a gigantic change requiring years of plumbing the code so as to properly expose everything in a sane way. I'd love to see it but it would be no small feat. 



No small feat, certainly, but I think it would pay dividends with the rich communities and power features that users are able to code themselves and share with other users.  I also feel like a lot new DAWs are baking in scripting from the get-go so it may be seeing a resurgence as a requested feature from power users after a lot of years not being that way.  Hopefully that will help push scripting (of any kind, CAL, python, whatever!) up the priority list on Cake's product backlog for Sonar.
2016/05/19 05:24:06
azslow3
thx1200
azslow3
MIDI manipulation scripting:  http://www.azslow.com/index.php/topic,286.0.html
It is Lua based because one user has promised at least test it, he did not.
 
Almost everything CS SDK allows, in interactive IDE form, with MIDI, TTS, Joystick and OSC: http://www.azslow.com/index.php/topic,7.0.html
 
Exists for quite some time, free to use. In practice used by ~2.5 man... At least I have managed to reduce the number of complains about not existing surface support and MIDI scripting. Once something exists, there is no more reason to continue complaining. Not that "authors" have ever try to use all that... prove me wrong

I don't know when I'll have time to play with this, but this project excites me.  It's not quite like being "inside" Sonar with an integrated scripting language, but there looks to be a lot of potentially useful applications here.  I'll need to learn LUA.

"Potentially useful" will never justify investments for commercial company (AZ Lua $5-10k, AZ Controller $200-300k, full proper scripting for the whole DAW probably $1000k+)
2016/05/19 18:05:35
thx1200
azslow3
"Potentially useful" will never justify investments for commercial company (AZ Lua $5-10k, AZ Controller $200-300k, full proper scripting for the whole DAW probably $1000k+)



I don't understand...?
2016/05/19 20:01:46
azslow3
thx1200
azslow3
"Potentially useful" will never justify investments for commercial company (AZ Lua $5-10k, AZ Controller $200-300k, full proper scripting for the whole DAW probably $1000k+)

I don't understand...?



DXi/MFX and CS API was published long time ago, CAL exists probably longer. Back in time I see more activity in this forum from power users, but still:
* CS API was known to be used by 3 persons (old BCR2000 plug-in, mod for MackieControl and my AZ Controller)
* MFX was used also by 3 persons (midi-plugins, TenCrazy and my)
* CAL scripts are developed by may be 10-20 users of this forum (used by more, but I do not think the number has many zeroes).
 
I mean you probably overestimate the number of potential "power users" and underestimate the costs to increase this number.
 
As you can see in this thread, CW (and I) are in general with both hands for such features. But commercial reality is different...
2016/06/01 13:26:58
thx1200
I don't know that's necessarily the case.  Not everybody who uses a feature jumps on the forums.  Also, CAL, as a language, is pretty out there.  Not many people really understand software engineering in general, let alone a language like LISP.  And, really, CAL was partially broken just one or two versions after its inception.  I remember scripts barely working in Pro Audio 9, let alone Sonar Platinum.
 
The other two cases were SDKs that also had a high barrier to entry for development.  If the scripting language was robust and well-known (think Javascript, just as an example, not that I'm advocating for it), I think you would see more people developing for it and a lot more people using it.  Also CAL had little to no UI component other than simple dialogs, so a lot of ideas just could never come to fruition.
 
Many of the new "cool kid" DAWs have a scripting component baked right in from the get-go.  Maybe it will fizzle out the way CAL did.  But maybe not?  Maybe it is worth the development. 
 
I work in a software shop for my day job so I understand project planning and development costs.  It's definitely not a cheap easy thing to bring scripting back as a first class citizen.  But the potential is massive.  If you took the hooks for CAL that are already there and maybe tied in some MFX and Control Surface hooks, then used an existing language (just so you aren't writing your own parsers and such, like with CAL), costs can be controlled.  It doesn't have to do everything on day one.  If it just did what we have now, but better, and in an easier to learn, low barrier to entry language, you might be surprised on the uptake.

ETA: I'm actually right now baking in PowerShell integration into a piece of software I write on the side and other than the interop wrapper functions for the automation functionality, it was really pretty easy to add.  I don't necessarily think PowerShell is the best way to go for Sonar (although I personally would love it), particularly now that they are targeting Macs, but I just wanted to point out that I have a little experience with this.
2016/06/01 15:29:32
SuperG
thx1200
I don't know that's necessarily the case.  Not everybody who uses a feature jumps on the forums.  Also, CAL, as a language, is pretty out there.  Not many people really understand software engineering in general, let alone a language like LISP.  And, really, CAL was partially broken just one or two versions after its inception.  I remember scripts barely working in Pro Audio 9, let alone Sonar Platinum.
 
The other two cases were SDKs that also had a high barrier to entry for development.  If the scripting language was robust and well-known (think Javascript, just as an example, not that I'm advocating for it), I think you would see more people developing for it and a lot more people using it.  Also CAL had little to no UI component other than simple dialogs, so a lot of ideas just could never come to fruition.
 
Many of the new "cool kid" DAWs have a scripting component baked right in from the get-go.  Maybe it will fizzle out the way CAL did.  But maybe not?  Maybe it is worth the development. 
 
I work in a software shop for my day job so I understand project planning and development costs.  It's definitely not a cheap easy thing to bring scripting back as a first class citizen.  But the potential is massive.  If you took the hooks for CAL that are already there and maybe tied in some MFX and Control Surface hooks, then used an existing language (just so you aren't writing your own parsers and such, like with CAL), costs can be controlled.  It doesn't have to do everything on day one.  If it just did what we have now, but better, and in an easier to learn, low barrier to entry language, you might be surprised on the uptake.

ETA: I'm actually right now baking in PowerShell integration into a piece of software I write on the side and other than the interop wrapper functions for the automation functionality, it was really pretty easy to add.  I don't necessarily think PowerShell is the best way to go for Sonar (although I personally would love it), particularly now that they are targeting Macs, but I just wanted to point out that I have a little experience with this.




You're barking up the .NET tree. This is something that would be language agnostic.
 
I've done an application scripting interface based on the Sony Vegas model myself.
 
But the issue is, as Noel pointed out earlier in this thread, this problem is having a congruent 'doc/object' model.  Get those particular ducks in a row first, then adding a scripting interface is straightforward.
 
 
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account