Logic Pro Help

Friends, we can't deny that the pandemic is giving many of us a lot of personal space, so here's the result of some misspent studio time recently...

https://github.com/objectkit/scriptex

It is a pre-release project, so there are chores left to do before v1.0.0 is hit, but I think its ready for eyeballing.

If you want to jump right in:

1. Download this release asset here:
com.objectkit.scriptex-runtime.js

2. ...follow the "Edit-In-Place" workflow instructions
edit-in-place-workflow

3. ...and take a look at the very basic docs here to get a sense of what it does
docs

Of course Scriptex does not fix Scripter or remove its quirks, but at least we can now have OOP, separation of concerns, IDE workflows and semantic clarity if we want it.
Have fun (and leave feedback here if thats ok by the moderators!)

All the best,

David

EDITS:
Corrected links to external sources

Very cool, I'll check it out. why does it require Catalina?

Nseruame wrote:

OOP, separation of concerns, IDE workflows and semantic clarity

That sounds highly interesting. Apart from the last thing I have no idea what any of this means. So what does it do ?

@Dewdman42 Cheers! As a safeguard only at the moment... am hoping that earlier macOS editions (e.g. El Capitan) will work, but have developed on Catalina only. The only reason why macOS is present as a requirement is due to the JavaScriptCore component of the OS that Scripter uses under the hood. Am hoping feedback will help identify the minimal Logic Pro X / macOS combination as the project continues...

@fuzzfilth Man, this is tricky! If I write memos for programmers only, I exclude music producers without programming experience, and if I write for general users only I exclude some of the fine detail of benefit to experienced programmers who are also music producers. Also I need to sleep and put all that together at 2am and its a pre-rlease! I'd say, just mess around with code and have some fun for now

You mean just push these nicely coloured buttons on the spaceship bridge and see what happens ? Yeah, been there, done that. Now how do I get back to earth ?

@fuzzfilth Ha ha ha. Precisely! Earths not that great these days with the crazy hairless hind legged species out of control. so I'd say, press the brightest button and keep exploring the galaxy! Or just try to crash the spaceshift safely and see if you can get an insurance boon

Seriously though, the assumption for this pre-release is that its open to all to just try it as it is, warts and oll. Pointing out these valid things such as RTFM? is helpful as it will help me tune the release documentation, so sincerely many thanks. Let me know how it works out if you have some free time

Well I tried the example microtune script. I copied that as well as the compressed engine script into script editor. Scripter complains that it can’t find GenericPlugin.

Not sure if I followed the right steps. On Mojave.

@Dewdman42 Ah... that's right. I clean forgot to point out that for this present version, replace

with

and it should work....

That particular build asset is presently an IIFE that uses the scriptex namespace, and that is subject to change in the final release. Thanks for pointing it out. Let me know how that goes andr feel free to PM me anytime

Makes sense. Will try it later today

Much appreciated. Looking forward to your findings.

Works in Mojave. Nice to see some use case of ES6 classes.

Great stuff, many thanks. Mojave support noted. Any joy with MIDI event interception via onNoteOn, onNoteOff.... onProgramChange etc?

I didn't really try to do anything of my own, I just tested out your microtune class and it works as expected.

Most likely I will prefer to just use HandleMIDI myself in my scripts rather then hiding it inside a helper class like this. Though I confess I have been avoiding ES6 class approach, using prototypes instead...and there may be some cases where I want to look back at that some more...

I just typically do it more or less like this, if and when the task is complicated enough to warrant it.

Code: Select all

Event.prototype.handle = function() {
    this.send();
};
Note.prototype.handle = function() {
   // note specific stuff
   this.send();
};
ControlChange.prototype.handle = function() {
    // cc specific stuff
    this.send();
};

function HandleMIDI(e) {
    e.handle();
}

Main advantage of Event polymorphism is eliminate complicated nested if/then blocks. That has always been one of the most compelling reasons for OOP. Your class definitely provides a way to do that with the even type handlers, though internally I guess you're using instanceof anyway.

In this case we are working with objects that LogicPro is creating internally...and is not providing the EventTypes.js javascript wrappers from them anymore. So proper javascript OOP inheritance from the Event objects is kind of muddy.

But anyway, I will sometimes use the above approach if and when I'm needing to handle lots of different event types in different ways and I want to reduce the if/then complexity for every event. more or less that is what your scriptex is providing with the On handlers.

In a more general sense, since we can't include libraries with Scripter I have more or less decided after much experimentation that most of the time the work and effort required to use OOP doesn't pay for itself in most of the scripts I have done. There are rarely a few instances where it is elegant to do, but the notion of reusable classes, is almost nil anyway, other then copy and paste. But you usually end up with a lot more code that way. I have pondered putting reusable classes inside the MIDI.js file and that would work for me, but then my scripts would not be sharable with others. I have also considered that the vast majority of LogicPro users, by a long shot, are not up for understanding even 1% of OOP programming approach.

At some point if a script is becoming so complex as to benefit from OOP, I find that I am more interested in moving to C++ instead of scripting. There are a few exceptions because Scripter gives us access to AU3 ports and articulationID, and C++ AU does not. I have one rather large and complicated script...called "articulator" that I am working on and will share it eventually and I expect almost nobody to understand the code...with or without the use of OOP inside. But its possible that *I* might like the code better by using ES6 class for some of it. Not all of it.

But in any case, I am impressed that you figured out a way to abstract the entire Scripter engine (more or less) into a class, that was no easy feat and my hats off to you for figuring out a solution that makes it possible to use an entirely OOP approach to writing a script rather then implementing the callback functions directly. There is definitely some clever stuff going on there!

Yeah. What Dewdman42 said. I guess.

Another situation I could see something like scriptex becoming useful is in setting up debug environments with nodejs. You could theoretically plop in a debug version of scriptex, and use a different engine to essentially do what LogicPro normally does when it calls the callbacks.

I'm not sure whether that would be clear or easier then writing replacement functions for HandleMIDI, but maybe there could be something that makes it easier when setting up a nice debug environment outside of Scripter.

@Fuzzfilth, @Dewedman42 thanks for the good words, I had to take a very lateral approach. It was developed on Node if you check the source, the intention being that for complex "apps", build-test cycles can be undertaken with the comfort of an IDE and Node tooling without even going near Logic/Mainstage bar for sake of integration tests. But for simple scripts, yes, the Scripter global API is still functional and I realise that many people still like that approach which is fine. Personally, I just don't like its untestablitiy, unreusablity, code sprawl, and context splitting with global variables which I think impedes just how far one can actually go with MIDI processing, Scripter or not. As for the approach, the GenericPlugin class is not the library, its a shim; essentially just a MIDI filter and a ModelView intended for quick experimentation, but its base class, Plugin is designed to use any kind of mapping that programmer wants. If one prefers a personal API or an emulation of the Scripter API, this is what one could do:



The library really has to be documented better to explain the benefits, so thanks for the feedback and for the beta test in the blind so to speak. I think I've now identified the blind spots looming before the 1.0.0 release, and most of that is communication and explanation on my part. I could extrapolate more here right now as there is quite a bit, but, I think its best to focus on putting that energy into the docs, which is not nice, but is necessary.

The plan now is to tighten up the remaining loose screws, provide use cases and examples for the two supported development cycles (in-place editing within Scripter and IDE based agile), then announce properly, with the features much better declared. Hopefully as the docs improve the features will become more obvious and more useful for those interested, and if there is uptake, interested parties could have their own plugins hosted at a dedicated scriptex-plugin repo, not for my personal benefit, but for us to make a group effort to really push MIDI processing on this platform and to share our collective hacks and solutions to make it easier for others for everyones benefit. Cheers for the feedback lads, more feedback also welcomed from other brave souls. Many thanks!

Nice.

If this is, or becomes, a platform upon which midi scripts can be developed and tested in an external IDE, out of the box...with a collection of reusable classes that represent a library of higher level functionality....whereby you can develop an advanced midi script, ultimately using less code in some cases; and being able to easily test it entirely in a real external debugger, etc.. followed by an easy copy and paste into the Scripter window when its all done to have a "compiled" working script... Than I applaud it and will become very interested in using it also. I will look forward to learning more. Feel free to PM me about it anytime.

Thanks for the sales pitch! Yes, those are the design principles at the heart of it. Am glad to say that the very same workflow been tried and tested informally here from the get go, so no technical problems per se, but the trick is to KISS this into shape, so I'm going to pause this for a short period (2 weeks or less) in order to take care of some other work, but will most definitely PM you in the near future when we are closer to the finishing line.

BUMP: v1.0.0-rc.6 ireleased

With PM's yet to be issued, feedback requested on the thin advisories and links added to the "Code Editor Workflow" and "IDE Workflow" sections of the README

TLDR- Other developers should now be able to:
+ add the `@objectkit/scriptex` package to node projects
+ independently download contents of the Scriptex preset

Notes
+ release of 1.0.0 will coincide with release of a template project
+ 1.0.0 is a bare bones library, with more classes planned as the project develops

Have fun and let me know how it works or does not work, all the best, David