Writing a script for Studio One?

[Eric]

ChatGPT seems to think you can write a script in javascript and use it in Studio One. Is this really true, or a hallucination? Thanks.

 

[Crossinger]

It's kinda possible, but not intended for the end user. It's more of a "hack".

https://www.kvraudio.com/forum/viewtopic.php?t=506195&hilit=Studio+One+JavaScript

Since the link to the thread is quite old, the videos are seemingly no longer available.

 

[Eric]

Thanks for the link. With the videos not there, I can't quite figure out what they're suggesting.

Let me put it another way: if I have a simple javascript script, how do I get Studio One 6 Pro to read it? Thanks.

 

[Lukas]

Yes, it's true, some editing functionality in Studio One is written in JavaScript/TypeScript, and there's also a JS layer for controller integration (e.g. Nektar controller keyboards, PreSonus ATOM, M-Audio controllers). Parts of this code can be explored... for example, the controller scripts found in the devices folder within the app directory. The editing area, however, is - at least officially - not accessible to users. Injecting custom scripts is indeed considered a hack, as it can break functionality and impact stability.

 

[Eric]

Thanks for the response. I hear (I think) the implications of "at least officially." I both understand that policy, and also understand why it could be very helpful for users to have this capability. I'll see if I can find a workaround.

 

[lokeyfly]

Thanks for the response. I hear (I think) the implications of "at least officially." I both understand that policy, and also understand why it could be very helpful for users to have this capability. I'll see if I can find a workaround.

Could you be anymore vague? What script tools, or enhancement were you looking to incorporate? In the past, I've heard the same as Lukas quite correctly mentioned. However, being a little clearer about what it was you were attempting, might enable you to find such a "workaround".
Thx ahead for those details.

 

[Chris R]

Here's a start: https://github.com/CSources/Studio-Pro-Scripting-API-Reference

If anyone is willing to contribute please do. It needs plenty of correction and updates, but it's a start.

 

[Gray Wolf]

Interesting. Where / how did find all of that information?

Studio Pro only loads the first ScriptClass entry in classfactory.xml. Additional entries are silently ignored. Each script must be its own .package file.

That's incorrect.

 

[Chris R]

Scraping all available sources we have, API discovery dumps, manual skin probing to see what elements, attributes and options render from the skin.xml

At this point in time I can only get one script loading per package. There is no working method documented for multiple scripts per package, it's listed as a Known Gap in 15.3 until someone figures it out and updates the documentation.

 

[Lukas]

Studio Pro only loads the first ScriptClass entry in classfactory.xml. Additional entries are silently ignored. Each script must be its own .package file.

That’s indeed incorrect. Even in the macro toolbar code alone, you can see that it uses several ScriptClasses with different entry points. If this doesn’t work, then you have a mistake in the declaration, such as an incorrect sourceFile, a non-existent functionName (although Studio Pro throws an error at startup in that case) or duplicate classIDs.

 

[Chris R]

Updated documentation with a working multi-script package example and source. Thank you for the insight.

 

[Gray Wolf]

Hi Chris,

Is there a reason you use prototypes in the functions?

I'm just curious why you did it that way...

function ScriptATask() {
  this.interfaces = [Host.Interfaces.IEditTask];
}

ScriptATask.prototype.prepareEdit = function(context) {
  this.ShowMessage = context.parameters.addInteger(0, 1, "ShowMessage");
  this.ShowMessage.value = 1;
  context.restore();
  return context.runDialog("ScriptADialog", "com.chris.multi-script-demo");
};

ScriptATask.prototype.performEdit = function(context) {
  if (this.ShowMessage && this.ShowMessage.value === 1) {
    Host.GUI.alert("Script A ran successfully.");
  }
  return Host.Results.kResultOk;
};

As opposed to...

function ScriptATask() {
  this.interfaces = [Host.Interfaces.IEditTask];

this.prepareEdit = function(context) {
  this.ShowMessage = context.parameters.addInteger(0, 1, "ShowMessage");
  this.ShowMessage.value = 1;
  context.restore();
  return context.runDialog("ScriptADialog", "com.chris.multi-script-demo");
};

this.performEdit = function(context) {
  if (this.ShowMessage && this.ShowMessage.value === 1) {
    Host.GUI.alert("Script A ran successfully.");
}
return Host.Results.kResultOk;
};

 

[Chris R]

That's generated code, I don't know any programming languages at all. This is all speculative. If there's something that needs correcting, we depend on people like yourself to point it out. I myself will learn as I go.

If you see anything out of place, please don't hesitate to correct it so we can continue building proper documentation. If you have suggestions on my approach, let me know.

 

[Lukas]

That's generated code, I don't know any programming languages at all. This is all speculative.

What does that mean? Did you use AI to extract all this information from the code you collected and create this documentation?

 

[Chris R]

What does that mean? Did you use AI to extract all this information from the code you collected and create this documentation?

Yes, and it generated the discovery packages used to inspect runtime classes that exist, their exposed properties, callable methods, returned values, etc. For skin.xml elements, it generated packages with a bunch of potential elements so I can see what renders in the UI, same with options and attributes, then I test their behavior.

 

[Vocalpoint]

Yes, and it generated the discovery packages used to inspect runtime classes that exist, their exposed properties, callable methods, returned values, etc. For skin.xml elements, it generated packages with a bunch of potential elements so I can see what renders in the UI, same with options and attributes, then I test their behavior.

So basically - you stole it? Since when is any proprietary software - fair game for reverse engineering - and now publishing on Github?

If you have suggestions on my approach, let me know.

My suggestion? You might need to lawyer up if you are not careful.

VP

 

[Chris R]

This isn't decompiling Studio Pro source code. It's just interacting with the API that's exposed for scripts and documenting it.

 

[Vocalpoint]

This isn't decompiling Studio Pro source code. It's just interacting with the API that's exposed for scripts and documenting it.

Exposed? How exactly? By using Ai tools to probe a running copy of the Studio Pro.exe?

It's my understanding that the Presonus/Fender API has never been exposed, documented, discussed and especially released in any way - to the general public.

And regardless of what you believe "source code" is (or isn't) - this is source code.

Pretty sure this API (in any form) is proprietary, copyrighted and protected by law.

VP

 

[Chris R]

The probes are Studio Pro scripts that run inside the scripting environment and inspect the objects and UI elements available there.

There is already partial documentation from other users, published years ago.

I’m not interested in debating the legalities. If Fender doesn’t want this publicly documented for users creating scripts, they can request that it be removed.

 

[Vocalpoint]

I’m not interested in debating the legalities. If Fender doesn’t want this publicly documented for users creating scripts, they can request that it be removed.

If Fender wanted users to be able to create scripts (in any way) - they would publish (and support) a full (documented) API.

@BobF

Possible to move this to the Lounge as this discussion certainly does not fit into a standard "support" issue/item that any general Studio Pro user would ever come across in their travels.

VP