Jump to content

Nseruame

Member
  • Posts

    75
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Nseruame's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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
  2. 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.
  3. @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!
  4. Great stuff, many thanks. Mojave support noted. Any joy with MIDI event interception via onNoteOn, onNoteOff.... onProgramChange etc?
  5. Much appreciated. Looking forward to your findings.
  6. @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
  7. @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
  8. @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
  9. 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
  10. Also bottom of the list here! Still, as I have some outboard gear that I already have icons for, it would be nice for them to match the production colour scheme on the fly. Meanwhile, in the actual world... (plugs in radio to sample long wave)
  11. I have run into a bit of brick wall that I hope someone could clarify for me. I have three external instruments and I want to create Channel Strip patches for three corresponding audio tracks that will do the following: - set the channel strips input channel number(s) - set the channel strips output channel number(s) - set the channel strips pan mode - set the busses and send levels - set the fader to a specified value (e.g. -12dB) The intention is to quickly load different configurations enabled by patch merging, but no matter what I seem to do, the settings above are not applied. According to this article at MacProVideo However, when I load the patch, it completely disregards those settings: input, output, pan, bus and fader values are not applied. I'd really appreciate some knowledge here, even to confirm that this is possible would be great. Many thanks! P.S. I do understand how to setup and use a template with these preconfigured tracks, but the intention is to work quickly and easily when inspiration hits by using patches - hope that makes sense!
  12. The new 2D icons in use by Logic can be found in this folder: /Applications/Logic Pro X.app/Contents/Frameworks/MAResources.framework/Versions/A/Resources The 2D icons are tiff files and the naming convention is that they all start with "e_", such as "e_guitar_1.tiff" and "e_bleep1.tiff" and so on. Still working on trying to interpret how the transparency works, and will post back if I do.
  13. Ha ha ha. A liccle box that denies the existence of adult human beings making electronic music with hardware in the 21st century? That does seem possible. Determined to solve this problem as it’s interfering with production. Hoping to try again with a clear mind during the week. Will report back any success if it arises.
  14. Dammit. Sorry to hear that Mike. Like, really. Wish I was back in home studio to rip out the last of my eyelashes (thanks technology for autospelling “eyelids”) in frustration (and making a weird joke much weirder - sorry!). Mixed rig - 5 synths, 1 tape delay, 1 sampler. It takes long enough to setup and manage a rig. It’s difficult to get quality time. Fiddling with settings is a total creativity killer. Why can’t we save a track stack and load it instantly? I don’t think it impossible for a DAW to auto create missing sends, even if it does not apply channel patches. I think I’ve looked at all the possibilities that I can think of. Right now I would consider this a serious bug. Would you agree?
  15. Thanks for the update Mike. I totally agree that expected workflow doesn’t work for me either. I won’t have the opportunity to try this for a few days, but I’m looking forward to trying this tutorial out - It looks promising... Logic Pro X Tutorial: Creating Instrument Patches with Track Stacks
×
×
  • Create New...