Nseruame Posted September 24, 2020 Share Posted September 24, 2020 (edited) 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 Edited September 27, 2020 by Nseruame Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 Very cool, I'll check it out. why does it require Catalina? Quote Link to comment Share on other sites More sharing options...
fuzzfilth Posted September 24, 2020 Share Posted September 24, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 24, 2020 Author Share Posted September 24, 2020 @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 Quote Link to comment Share on other sites More sharing options...
fuzzfilth Posted September 24, 2020 Share Posted September 24, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 24, 2020 Author Share Posted September 24, 2020 @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 Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 24, 2020 Author Share Posted September 24, 2020 (edited) @Dewdman42 Ah... that's right. I clean forgot to point out that for this present version, replace class Microtone extends GenericPlugin with class Microtone extends scriptex.GenericPlugin 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 Edited September 24, 2020 by Nseruame Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 Makes sense. Will try it later today Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 24, 2020 Author Share Posted September 24, 2020 Much appreciated. Looking forward to your findings. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 Works in Mojave. Nice to see some use case of ES6 classes. Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 24, 2020 Author Share Posted September 24, 2020 Great stuff, many thanks. Mojave support noted. Any joy with MIDI event interception via onNoteOn, onNoteOff.... onProgramChange etc? Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 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. 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! Quote Link to comment Share on other sites More sharing options...
fuzzfilth Posted September 24, 2020 Share Posted September 24, 2020 Yeah. What Dewdman42 said. I guess. 1 Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 24, 2020 Share Posted September 24, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 25, 2020 Author Share Posted September 25, 2020 @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: /** @abstract */ class Microscripter extends Plugin { /** @override */ static get API () { return [ [ `HandleMIDI`, `handleMidi`[ , [ `ProcessMIDI`, `processMidi`] , [ `ParameterChanged`, `parameterChanged`] , [ `Idle`, `idle`] , [ `Reset`, `reset`] , [ `NeedsTimingInfo`, `needsTimingInfo`] , [ `ResetParameterDefaults`, `resetParameterDefaults`] . [ `PluginParameters`, `pluginParameters` ] ] } } // in a separate project/file... /* concrete implementation from subclass */ class MidiHandler extends Microscripter { get needsTimingInfo () { return true } handleMIDI (event) { event.trace(event.beatPos) } } MIDIHandler.deploy() 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! Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted September 26, 2020 Share Posted September 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nseruame Posted September 29, 2020 Author Share Posted September 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nseruame Posted October 5, 2020 Author Share Posted October 5, 2020 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.