I'm trying to investigate scripting. I keep seeing a guide by Lawrence mentioned but the only thread I found with a link to it showed that the YouTube video has been taken down.
What I want to do is automate some of the tasks of importing aaf sessions from ProTools and getting them into my preferred layouts/colors/bus routing/etc....
I have figured out some stuff to make it simpler but I'm sure there's more I can be doing.
It's in kind of a "fuzzy zone" of sorts at the moment. They may or may not publish / publicly document it at some point in the future, no clue. Unless that happens it's a good bit of trial and error and a little detective work. It's certainly does allow doing some really useful things and the work / end result ratio is typically favorable.
Keep hope alive for a public release.at some point.
Thanks for that.
So where should I go to even begin to look at examples, how to get them into S1, etc? I know there is no "official" stance by PreSonus on this.
I can post a basic "Hello World" script or something on GitHub if you just want to see a basic working outline, but that may not get you anywhere close to what you want to do. A basic script package is just 3-4 files.... a class identifier, meta information, a JS code file, and if there's a GUI involved, a skin file.
There were some examples floating around the web until the Studio One X guy locked his package down. I'd posted a basic tutorial here about a year or so ago and later took it down as there didn't seem to be much interest and it wasn't all that well written to begin with.
OK well I don't want you to go through too much trouble just for me. I appreciate your insight into this. I can understand PreSonus not wanting to publish anything detailed about this... 3rd-party scripts running amuk on the web certainly has a potential to create some nightmarish scenarios for their support and QA teams.
Truth be told, the stuff I really want to address would mostly be accomplished with a more robust/complete "import song data" feature set and I've made official feature requests for them.
Thanks for taking the time to respond!
Sounds like a plan.
Anyway, I already had a basic Hello World script so I uploaded it: https://github.com/StudioOneScripts/Hello-World
Take care my friend.
I'm very interested in this as well. I've been scouring the internet trying to scrape up all the information I can. Seems like everything I find has Lawrence attached to it! haha
Thanks for posting the Hello World code, that's definitely very helpful.
Does there exist a list of all known classes and member functions anywhere? I saw in one of your previous posts you had listed some members of the event class. Any info at all you can share would be much appreciated! Thanks
Lawrence wroteSounds like a plan.
So for this example, in the ReadMe you say to "Zip up the files and put them in the Studio One application \scripts folder and restart Studio One." Can you elaborate on this or is it really just that simple? (I did try just adding the files in a .zip folder but no luck with that.)
All the files in the scripts directory are precompiled hex code with a .package extension. Could you walk me through the process of getting studio one to look at your custom scripts a bit more? Sorry for such a newbie question!
The core script packages / dependencies that install with Studio One are protected, for obvious reasons. A script written by a user can be unzipped and read to study the source code, unless the JS in it is obfuscated.
The first version of Studio One X was unprotected, you could just unzip it and see all of it's source code. He changed that later and made it a protected *.package like the Studio One script packages. I spent a good bit of time trying to figure out how he did that, what method he used to do that, with no luck.
But yes, any correctly written script that's in the \scripts folder will load when Studio One starts.
Does there exist a list of all known classes and member functions anywhere?
Nope. We just have to wait and see if they publish something at some point. Scripting in audio workstations is not exactly a widespread official feature in the industry. A couple of products did it later on, Tracktion, Ardour, but for most part Reaper is the only product other than Vegas (which it was initially based on) that did it somewhat early on.
Vegas was always a Windows platform only product and it used C# as one of it's scripting languages, which worked really well there, and Sony published the full API on the web. As far as I can tell, Sony Vegas was the first audio workstation to ever do anything like that.
P.S. Off topic: I can always hear some people thinking certain things when these scripting discussions come up so just to clarify some of it.
Some Inevitable Comments / Observations:
"I'm a musician and/or an audio engineer, not a developer. It's the developers job to make new features or functions. I couldn't care less about this. I'm not a code monkey. I make music, not code."
The above is a pretty common but somewhat narrow minded point of view. The benefit is to be able to simply go to a forum (or script archive) and ask...
"Hey, is there any way to do X? It really annoys me that I can't do X."
… and then some friendly "code monkey" like darrenporter1 gives you X the next day. Problem solved. In comparison to alternately making a feature request and waiting two years for X when the application developers have much more important priorities, doing things that only they can do.
That happens near daily on the Reaper forum. It's not just nerds doing nerdy stuff because they're nerds.
By sheer coincidence of design or not (no idea) Studio One is setup for that better than most.
Thanks so much Lawrence. Ok I was able to get the Hello World script installed and working. Well on my way to hacking the Matrix
Would you be willing to share the list of methods you know of currently? Not sure if that's something you've documented for yourself or not but if so that would be awesome.
I'm going to start picking away at it and running tests on various classes/methods to see what, if anything, they return and I'll share any of my findings here. I'm mainly interested in trying to get access to track related values and functions like getters and setters for faders, pan knobs, etc.
Lawrence wroteP.S. Off topic: I can always hear some people thinking certain things when these scripting discussions come up so just to clarify some of it.
I totally agree! The more information out there about this kind of stuff the better. That way people are free to decide for themselves whether they want to learn about it or not. Not sure if an API will ever come from Presonus but that would be very cool if it did.
colliderman wroteWould you be willing to share the list of methods you know of currently? Not sure if that's something you've documented for yourself or not but if so that would be awesome.
Some things, yeah. Some of my knowledge of the object model was acquired via means that don't allow publicly sharing but the method below for iterating tracks and addressing faders and pans doesn't really fall into that category.
Iterate tracks, and if a track has an audio channel, address it's properties. Not the only or even best way to do that, but it's easy to understand and extrapolate from. Obviously, if you wanted to set a fader to a specific dB value, you'd need to do the math to convert -10dB or similar to float.
darrenporter1 wrote3rd-party scripts running amuk on the web certainly has a potential to create some nightmarish scenarios for their support and QA teams.
Not really, but there are exceptions that lend some measure of truth to that idea.
Those things are somewhat isolated and for the most part they're offline functions that can't really inhibit or break the core operation of an application. In the worst case, a poorly written script will cause a crash or exception when you run it but there shouldn't be any confusion as to the cause. When sitting idle they don't do anything.
Having said that...
What the Studio One X guy - also - did on Windows is a different thing, hacking or replacing a *.dll. That's not scripting, that's hacking, and it actually did break MP3 functionality for some people later on.
Also, some people were using it and when it stopped working later when Studio One updated, they started replacing current application dependencies in Studio One with older versions of those same files to make it work again, which is not a good idea in general and can sometimes lead to unpredictable problems. That is to say, they (the users) may have tossed away something in that file that the latest version of the application needs to function properly.
But to your point, there certainly are people out there who will go grab something from the web, a crappy free third party plugin from Tasmania, a script, whatever, and when their daw starts crashing they'll just go make a support ticket instead of drawing the most obvious logical conclusion.
Lawrence wroteSounds like a plan.
Hi Lawrence, thanks for uploading the example! Unfortunately, I don't see any change after putting the zipped file ("Hello-World-master.package") in the script folder. I assume I should see a button "Hello world" somewhere in the Track menu, but there is nothing. Should the script still work?
Honestly, you probably shouldn't even bother with it at the moment. I mean, it's pretty easy to do once you know what to do but without any documentation or a tutor it's a bit of a guessing game and can lead to a good deal of frustration.
I'd just wait and see if they may publish some documentation at some point.
I wish there were some example scripts to get started with, but I will have a look at that context object and "this" for the global context....probabably can start to figure out a lot already just by looking at that. I tend to doubt PreSonus will ever release the API to us. They must be using this internally, which is very cool..also not something I would want to document if I were in their shoes.
I started a little bit, but not home yet. I want to scan tracks, layers and events - and find what is selected and rename those as preferred - in my case with a timestamp.
This would solve both for audio and music, as Presonus prefere to call it.
I started like this
a) rename a song file to zip
b) únzip and unpack into folders
c) look inside song.xml file.
There you can see structure like this roughly
<MediaTrack mediaType="Audio"> for audio tracks.
<MediaTrack mediaType="Music"> for midi tracks.
Each type has attribute layerCount="3 " activeLayer="2" as example.
next level within MediaTrack node.
This is the basic structure as saved, and I suspect internally the same broadly.
I removed some attributes and focused on basic navigation.
So navigation is probably collection of MediaTrack, and seing how many layers there are.
Then collection of List with type Layer, and addressing like an array in case above 0-2 offsets.
And you know the active layer is 2, so offset 2.
And on each layer a collection of Event that in turn hold a List collection of AudioEvent or MusicPart if midi.
This is where I am at right now and determined to crack this.
So scanning tracks, layers and all events on each layer I am to find out a property if event is selected or not. And this navigation would work all the way even through non-active layers if you want - and select an event and append a timestamp to that event name.
This is my goal right now.
Next step would be to make a command that takes a parameter like you can create named markers according to a parameter.
So a number of functions to be able to name an event or track or anything
$trackno() will return a track number.
$trackname() will return a track name.
$year() would give year from systemtime
$month() would give month from systemtime
$day() would give day from systemtime
$hour() would give hour from systemtime
$minute() would give minute from systemtime
$second() would give minute from systemtime
and more like this for layers etc.
So ability to setup a template to name as prefered with a quick key command to a macro is final goal.
You have one key command to rename a selected event and one to rename a layer and one to rename a track like this.
And can combine any way you like.
Let's say a command for a macro can look like this
RenSelEvent "Evt tr="+$trackno()+$hour()+$minute()
or similar. Maybe all in quotes, not sure of inner working for macros.
It would result in that selected event, even in a non-active layer to be named "Evt tr=2 10:25"
Completely free to get organized as you please.
I can only dream of Presonus bringing API into public.
But i am not holding my breath.
I think a DAW which gives the ability to extend it's functionality to your very own needs, by scripting,is really powerful.
(Nope, i am not gonna use the "R" word)
I am really happy with the extended midi functionality in S1 4.5.
But, I have dozens of midi related features in my mind, that would speed up midi related and compositional workflows in S1 (even more).
If S1 scripting API would be public and if scriptable at all, i would eat my Hat,
But i can totally understand why Presonus don't wanna make that move.
And i respect that, fully.
Yeah, It's all speculation at this point. They may or may not choose to do that at some point, we'll just have to wait and see.
Publishing (documenting) an API for public consumption is no small thing except for cases where there's not very many public objects, methods, and properties in it. Also, when do that you open another brand new feature request door, where some will be asking to extend it, expose more things, add new functions, etc.
I can't imagine it being an easy decision for them. Once you do it there's no turning back.
Users browsing this forum: No registered users and 2 guests