This forum is for Tips and Tricks. Please do not post any questions in this forum. It is only for information.
57 postsPage 2 of 3
1, 2, 3
I see, thank you for your input Lawrence !

Macbook Air M1 2020, 8 gig RAM, 256 gig SSD | OSX Ventura -latest Beta | Presonus Studio 24C audio interface.
User avatar
by Dewdman42 on Sun May 26, 2019 7:31 am
Yes it opens a huge can of worms to support something like that rolling forward.

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Lawrence on Sun May 26, 2019 8:22 am
Dewdman42 wroteYes it opens a huge can of worms to support something like that rolling forward.


Yes, it could if it results in a deluge of feature request for it or forum complaints and whinging about what some may view as missing objects or functions or whatever.. Of course, they could also just publish it with an unequivocal caveat...

"It is what it is and that's what it will always be, period, so just be thankful and stfu." :mrgreen:
User avatar
by Dewdman42 on Sun May 26, 2019 8:29 am
Just the mere cost of documenting it now and as it changes over time would be cost prohibitive. If they change it radically and break user scripts, imagine the outcry. It’s a very big can of worms. It’s one thing to use it internally in a controlled fashion. It’s a whole nother level to document and support it. Additionally they have a revenue model that involves selling addons, why would they want to make it easily customer-extensible? Just something to think about there.

I will be very surprised if they document the API ever. The user community would be better off to join forces and reverse engineer it as much as possible. But don’t be shocked if someday presonus changes it substantially and breaks everyone’s scripts or even blocks them entirely at some point.

Don’t get me wrong I will be experimenting with this also but I think Presonus has much bigger fish to fry on other features and we should just feel lucky that there is anything hackable like this at all for the time being

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by vanhaze on Sun May 26, 2019 8:46 am
Waveform DAW has a public JS API, you can make javascripts in Waveform.
You can even see for every macro how it is build from javascript.
Or am i now comparing Apples and Peers ?

Macbook Air M1 2020, 8 gig RAM, 256 gig SSD | OSX Ventura -latest Beta | Presonus Studio 24C audio interface.
User avatar
by Lawrence on Sun May 26, 2019 8:57 am
Cool, I knew it has some scripting capability but I've not seen the API. Post a link to it if you have it.

Edit: I found it in the demo. It's obviously very similar being JS, but they appear to access common properties via functions ...

Code: Select all
var name = Tracktion.getName(tracks[I]);
... as opposed to properties being exposed directly in Studio One …

Code: Select all
var name = tracks[I].name;
There may be some disadvantage to that first method. If an object has 15 properties, I suppose you'd need a get() function for each one, compared to the latter where all properties are always visible from the object.

But Studio One objects also do have lots of things that you'd think should be properties that can't be accessed directly either, you need to use findParameter(). I suppose in those cases it's more a parameter than a literal object property.
User avatar
by Dewdman42 on Sun May 26, 2019 6:42 pm
at approximately which version of S1, did PreSonus start encrypting the package files?

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Nip on Mon May 27, 2019 3:37 am
Dewdman42 wroteYes it opens a huge can of worms to support something like that rolling forward.


If to open API fully - yes - but that need not be the way.

Way to go and not open fully the internals to everyone to abuse - would be to make an extensive scripting wizard in addition to macro organizer.

Macro organizer is really nice - but is is lacking commands for a lot of things to even use it fully.

I'm thinking of
pause <arg> where arg is milliseconds as one.

Just adding this would extend macros in huge proportions - since anything that open dialogs and do things that take time - will consume the pipelined macros before that is accomplished.

Example open a dialog and move to a field and enter text of some sort - not doable now. Various parts take time and while that happends next comand is eaten.

So adding a range of commands for macro only use. This was just one example.

Or a proper macro wizard with loads of nesting and conditional options, like in Cubase but avoid that clumpsy way that only transform, select or delete something. And far too few options. And you had no pause there either - so if you selected a bunch of clips the pipelined commands already had executed before the action you intended. And they did not add new Logical Editor abilities as new versions was released - so remained half bakes on could say.

So a clever selection of macro only commands(not able to key commands alone) - can open up basically the full api - but keep protecting that not abused in a harmful way.

If you with every release, at least minor or major version - extended with such requested commands - user are being able to customize much more.

Let's say you want to open up certain properties like SetColor, or SetName, or SetPosition with a parameter.

You have a rename event command - but that open a dialog. So one such command in thinking this is unattended and do a parameter. And then open up with functions similar to the list I did before - $trackno() and similar to combine into generating text according system properties. so you can make a template what full text will be.

And a general command to ask user for a text - that can be used as parameter to various commands to follow. So that pops a dialog. In Sonar CAL language that was an Ask() script command as I recall.

And for more complicated things like a wizard with conditionals can do - you generate a script for those options entered - but script itself is just run and not available to user. This way you can extend possibilities without jeapardize the system as such.

So a wizard generating a script that their engine can run - but not edited further by user. This is pretty safe.

So I think this is more likely and better for all parties.
a) extend with macro only key commands useful to control flow and ask for parameters and such.
b) build a full script generating wizard.

*** Windows 7 Pro * i7-860 2.8 Ghz 16 GB ram * RME HDSP 9632+AI4S+Audient ASP 800 * GT730 ***
User avatar
by Lawrence on Mon May 27, 2019 7:19 am
True. If all you want or need is access to track and channel arrays and other similar common things, I can do that for you in a functions.js file. You can then just always #include that it in your scripts..

getSelectedTracks(), getSelectedChannels(), getSelAudioTracks, getInstrumentTracks(), etc, etc, anything reasonable really.

I can do that, but as expressed previously, some of my knowledge of the object model was acquired by means that don't allow sharing the source code so that functions.js file would be obfuscated, but it would work.

Example Use Case: var tracks = getTracksByName("voc", 1); would return an array of all tracks with "voc" in the name and the boolean argument would be case sensitive matching, yes or no. You can then apply any other common JS code as you iterate that array, like maybe using another function like muteTrack(tracks[x]); or soloTrack{tracks[x]);. etc, and make an action out of it to put in the action list.
;
In that regard, the functions.js file would only need basic documenting, for what does what and how. In that light, we can kind of make our own mini / limited API.

** I'll move this thread to Tips and Tricks at some point to not clutter up he support board with unofficial stuff like this. **
User avatar
by Nip on Mon May 27, 2019 8:20 am
Lawrence wroteTrue. If all you want or need is access to track and channel arrays and other similar common things, I can do that for you in a functions.js file. You can then just always #include that it in your scripts..

getSelectedTracks(), getSelectedChannels(), getSelAudioTracks, getInstrumentTracks(), etc, etc, anything reasonable really.

I can do that, but as expressed previously, some of my knowledge of the object model was acquired by means that don't allow sharing the source code so that functions.js file would be obfuscated, but it would work.

Example Use Case: var tracks = getTracksByName("voc", 1); would return an array of all tracks with "voc" in the name and the boolean argument would be case sensitive matching, yes or no. You can then apply any other common JS code as you iterate that array, like maybe using another function like muteTrack(tracks[x]); or soloTrack{tracks[x]);. etc, and make an action out of it to put in the action list.
;
In that regard, the functions.js file would only need basic documenting, for what does what and how. In that light, we can kind of make our own mini / limited API.

** I'll move this thread to Tips and Tricks at some point to not clutter up he support board with unofficial stuff like this. **


That sounds lovely, thank you.

"var tracks = getTracksByName("voc", 1);"

This could be made into command for macro manager that can take one string paramter, like InsertNamed Marker or what it is called.

We can continue to build an macro api, kind of, like this .- that extend what you can do with ease for macros.

I think this is what you share before.

Code: Select all
let trackList = context.mainTrackList;
for (i = 0; i < trackList.numTracks; i++)
{
    var track = trackList.getTrack(i);
    if (track.channel != undefined) 
    {
        // get
        Host.GUI.alert
        (
            "Volume: " + track.channel.volume.toString() + "\n\r" +
            "Pan: " + track.channel.pan.toString()
        )

        // set
        // track.channel.volume = 0.56;
        // track.channel.pan  = 0.5;
    }   
}


Since I found that xml structure of a song have an attribute layerCount and activeLayer - from that loop above you should be able to read those values - I suspect.

And then continue with two levels more of scanning list with layers and then events on each layer. And knowing which layer is active like mentioned you can also navigate those takes/layers.

And if there are attribute/property like "selected" or similar, so you can decide - this is the event I want - then even better.

I saw one property ShowSelected - don't know if that is related. If it tells to show the track/layer/event as selected or something.

If you navigate like this, many things are possible.

If there is a way to use just fractions of info like this - that cause no harm - and we can share scripts like that - it is my first choice. If the full community can do it.

I'm thinking javascript then all the way. And your package files are not-encrypted, just zipped - so anything is open and not sharable. Presonus ones are encrypted.

Are there ways to send a package file to Presonus and have them look and encrypt and we can share it?
Some sort of validation, approval or something?
And people signing some NDA get full documentation if they stick to this procedure - not publishing non-encrypted packages.


It could be a way forward. There were some talk years ago about Presonus Exchange or something - never saw much there, really.

But if we get some extensions on commands for macros that increase usability that is fine too. That package files encrypted and approved are added it can be improved quite a bit, I think.

*** Windows 7 Pro * i7-860 2.8 Ghz 16 GB ram * RME HDSP 9632+AI4S+Audient ASP 800 * GT730 ***
User avatar
by Dewdman42 on Mon May 27, 2019 11:08 am
Lawrence wroteTrue. If all you want or need is access to track and channel arrays and other similar common things, I can do that for you in a functions.js file. You can then just always #include that it in your scripts..

great idea

I can do that, but as expressed previously, some of my knowledge of the object model was acquired by means that don't allow sharing the source code

By what means was that?

In that regard, the functions.js file would only need basic documenting, for what does what and how. In that light, we can kind of make our own mini / limited API.


Its a nice idea!

This cloak and dagger stuff though, is a little discouraging.

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Lawrence on Tue May 28, 2019 6:14 am
User avatar
by Dewdman42 on Tue May 28, 2019 11:00 am
Very nice, thanks. is there any way with those existing functions to set the midi channel and port assignment of a track?

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Dewdman42 on Tue May 28, 2019 11:37 am
for
Code: Select all
Host.GUI.Commands.interpretCommand("category","action");
where might we find some information about available categories and actions?

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Lawrence on Tue May 28, 2019 12:15 pm
In the action / keyboard shortcut list or menus like "Edit", "Select All"
User avatar
by Dewdman42 on Tue May 28, 2019 12:17 pm
Right, so you could use that to essentially do the same things you could do with a macro, right? Except in javascript?

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Dewdman42 on Tue May 28, 2019 1:34 pm
poking around a little bit, I can see that this is a huge task to try to reverse engineer, something I don't have time for. What I can see is that many of the objects referenced in your examples are native objects, so they are just thin pointers to C++ objects and there is no way to query through javascript to find out the properties, none that I can find anyway. I don't know how you guys figured out as much as you did, but anyway...

Its also clear that S1 is using some observer and other design patterns, which is all good, but really hard to reverse engineer how it integrates with Javascript with all the references to certain named native objects.

clearly its possible to also add GUI elements, but what is CCL:ParamList, for example and what all can we do with it, etc, etc, etc..

In short, I really do not think PreSonus is ever going to expose this completely to us, this is very deep stuff they have done, I can understand the flexibility that they have built for themselves by hooking into underlying objects via Javascript, but advanced knowledge of the apps internal code and structure is really needed to be able to make much use of it, which they are never going to divulge.

And frankly, it would be too complicated for most aspiring scripter/musicians.

So the next thing would be to try to build a much simpler API and document it well. Something that just kind of extends the macro facility a little bit is probably what most people would like and make use of.

If I were PreSonus I would want to provide a much higher level hook into the app, if at all, for javascript access, I would never provide a direct access to so many internal objects. They ought to just extend the macro facility to use javascript directly right in the macro organizer, with some set of user definable callbacks or something. Would not be hard.

I'd put javascript wrapper classes and methods around every single built in action, as you pointed out is possible with one function call now, but putting them into classes and methods would provide a lot of cool functionality and could be extended to do the kinds of things like you are doing in your functions.js. Then just make those available from the macro organizer and be done with it. I think that would provide a lot of additional capability from user defined macros without having to hack around anything. But somehow I think this kind of extension would be very low on the priority list for PreSonus honestly. Clearly this javascript backend is more for their own purposes then for customers to mess with....

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by Lawrence on Wed May 29, 2019 6:30 am
We can speculate all day about what they may or may not do in the future, or what we want them to do or how we want them to do it, and the current reality will still be the same ...

"We'll just have to wait and see."

In the interim use functions.js to address some common things like tracks and channels. If there's something specific you want to do, let me know and I'll maybe add another function to that file that will help. But yes, for some other things you'll need an API from them.

The IObserver interface is not hard to implement but my understanding of this discussion was not really related to that, more just bringing some level of logic to some common actions, so no observer or paramList is necessary unless you need to use a GUI for a script for some reason.
User avatar
by Dewdman42 on Wed May 29, 2019 9:00 am
Yes that is all we can do speculate. What is there I don’t see as being all that useful. We need more. I personally need access to midi note data to get more interested.

Ok here is an idea, maybe we could start with some simple examples as a sample of how to use your functions.js library.

let's say I wanted to write a script that would tidy up all my track heights, and this could be somewhat complex where it might make some of them taller then others, or fold certain folders, etc.. A one click way to get my track view neat and tidy again.

So... With your mini API, how can we adjust the track height in the GUI one track at a time?

I also have a need to setup an orchestral template with lots of port and midi assignments...and its very tedious to do it manually. I would much rather type it into a javascript file and execute once. So how would I use functions.js to set the midi output device, channel and port on a track by track basis?

Some other examples, would be applying some common FX chain or even two-track midi plugin routing, across 100 tracks with one button press too.

Even if some of the above is possible with a macro, can we talk about javascript right now? I'd actually probably prefer to write it in javascript even if I am just calling the built in actions as would be the case from a macro.

One thing I am extremely interested in is articulation support. So I would like to write some scripts for inserting key switches or other pseudo expression map concepts; adjusting legato overlap and other things like that..I realize again, some could be done with macros, but I'd like to talk about how to accomplish in Javascript.

5,1 MacPro 3.46ghzx12 128gb ram, OSX 10.14, S1, LogicPro, Cubase10, DP9, Reaper, VEP7, VSL, too many plugins to list
User avatar
by rogerbucks on Sat Jun 01, 2019 8:06 pm
With some of the enhancements I'm thinking of to get better controller integration, it would be great if there was an open source repository to add in scripts/integrations for shared benefit.

Not sure how well that would fly with the SO4 T&Cs though.

SPECS:Win 10 64-bit, 4 Core i7: 24Gb DDR4 ram, Panasonic 4K TV, Focusrite Scarlett 2i4, Panorama P6 + NX-P&NP-2 + Maschine Jam, Studio One Pro 4.5.1.52729

57 postsPage 2 of 3
1, 2, 3

Who is online

Users browsing this forum: No registered users and 25 guests