Jump to content

Scripter Feature Suggestions


Dewdman42

Recommended Posts

- Implementing a Scripter object in the Environment or create other means to connect Scripter and Environment. Currently this is done via External Instrument Plugin and IAC, which works reasonably well but is complicated to set up and maintain and does not translate well between rigs.

 

- Better ( or, at least, *any*) layout parameters (size, position, appearance) for GUI objects.

Link to comment
Share on other sites

In no particular order:

  1. LPX could assign duration attribute to NoteOn events when it is known(originating in region). Logic could handle NoteOff event automatically when such is the case. Able to assign duration to events for automatic NoteOff to happen, managed by LPX.
  2. Able to set Scripter's latency-reported-to-host (which can then influence PDC in desirable ways)
  3. Improved buffered tracing that does not bail out under load. Ensure that all trace messages are output, even if they are delayed a bit. Would be kind of ideal if the same logging interface as typically used in other javascript environments were used, (i.e., console.log() )
  4. Some built in functions/methods for converting beatPos values to other meaningful things like ms or midi ticks.
  5. Ability to get/set the midi port to use for an event so that once AU3 support is working fully, scripter can be used to recognize and assign events to a specific port of an AU3 instrument plugin.
  6. Ability to direct midi events directly to a midi device, including IAC.
  7. GUI facilities improved a bit, as mentioned by others, not only to include more ability to customize the GUI, but also a bit more separation between data and view, ensure that GUI operations happen during Idle cycles to stay out of the way of midi processing.
  8. Timers. Ability to set timers that will execute functions, including using beat position to fire the timer.
  9. Callback functions for when START or STOP of the transport occurs.
  10. Able to read JSON from a file for whatever purpose.
  11. Able to write JSON to a file, for whatever purpose.
  12. Able to register HandleMIDI() callback PER CHANNEL. (and eventually per port/channel), so that a separate callback function can be registered for each channel. This is useful when using a multi-timbral instrument and can have a separate HandleMIDI() function for each channel of that. This can be done programmatically now, but its messier code.
  13. Able to maintain a user library of javascript functions and objects that can be reused across different scripts.
  14. Improved event.trace() method that shows beat position and other attributes there might be currently missing
  15. Improve handling of MIDI.noteNames so that the note names in logging and in all functions of scripter match up with the LPX preference setting of C3 or C4 for middle C
  16. Some stuff related to midi clock
  17. Able to change tempo on the fly
  18. Able to detect and send sysex messages or any other low level midi message that is not currently supported by the existing Event object framework.
Link to comment
Share on other sites

Regarding #1... notes with fixed durations, how about using sendAfterMilliseconds?

 

if (event instanceof NoteOn) {
event.sendAfterMilliseconds( * slider value or fixed variable * );
}

 

Regarding #9, ability to handle MIDI per channel, what do you find messy about the current method of simply detecting for a specific MIDI channel? Seems to me the code could get grandly mo' messier if you had to have separate routines for each channel.

 

Regarding #14, improved event.trace() to show articulation ID, I see ID on every event that has one (that is, any event with articulation ID > 0). Curious to know what kind of improvement you'd be looking for?

Edited by ski
Link to comment
Share on other sites

I hope this thread will not turn into one if those internet threads where everyone picks apart everyone else’s desire for improvement, that is very unproductive. Ski perhaps you have some ideas about how it can improved?

 

I will respond to your comments when I get home, too hard on iPhone

Link to comment
Share on other sites

Regarding #1... notes with fixed durations, how about using sendAfterMilliseconds?

 

if (event instanceof NoteOn) {
event.sendAfterMilliseconds( * slider value or fixed variable * );
}

 

 

As noted before, I want to not have to worry about sending NoteOff, if I know the duration ahead of time. With live midi we don't know the duration ahead of time, so then we will have to either specify a duration, could be milliseconds or could be as beats, which is more relevant if you are scripting musically oriented things. Using AfterMilliseconds works great for the keyswitch NoteOff where we don't really care how long it is, we just want to make sure the note off actually happens. When people are doing things based more on actual music, then the duration has more musical relevance. So you can of course use SendAtBeat with a little math to calculate it. But I think it would be even better, easier and perhaps more reliable if we can just specify event.duration as an attribute of the Event object and let LPX handle it.

 

Even further to that, in many cases, LPX DOES know the duration of a note, because its coming from a region. And if that attribute was passed into Scripter with the duration included in the Event object, we could use that in Scripter to do any number of things we might think of where the duration is an interesting thing to consider. Right now, scripter is totally blind to duration until the NoteOff comes through.

 

Another interesting thing is when we transpose notes in scripter, then we have to make sure the script is on the lookout for the matching NoteOff to also transpose it. In simple transposing, that's not so hard, but situations can come up where you were changing the pitches of notes...possibly in some kind of dynamic manner where it might be difficult to know when the matching NoteOff comes in to make sure its transposed the same way its matching NoteOn was. It can be done, but can also especially throw beginning programmers into more complexity then they really want to deal with.

 

If LPX just manages it as much as possible, it would be better, easier and more reliable.

 

Regarding #9, ability to handle MIDI per channel, what do you find messy about the current method of simply detecting for a specific MIDI channel? Seems to me the code could get grandly mo' messier if you had to have separate routines for each channel.

 

Just another way to handle it that I think is cleaner in some cases. You can have ginormous HandleMIDI function with a bunch of if/then statements or you can have a more event driven situation where the actual event drives which function handler will get called. This is part of the basis of OOP programming, elimination of if/then statements all over the place is part of what drives OOP through polymorphism. LPX is not great about the fact that you have to funnel up to 16 midi tracks through a single Scripter instance in order to feed a 16 part multi-timbral instrument. I would like LPX even more if they provided us a matrix plugin or something so that we could isolate a stack of midi effects for each midi channel before it hits the instrument.....or something like that... so that we can easily process a stack of midi effects destined for a single channel within a multi-timbral instrument.

 

Anything we can do to be able to compartmentalize the code handler for each channel in that situation is better. What if you start out with your mondo script with 16 midi channels handled separately with an if/then statement to identify which channel to handle in the script. But then later we decide to rearrange what multi-timbral instrument is handling what. Then we would have to go in there and edit the if then statements and generally mess around with who knows what kind of complexity inside that singular HandleMIDI function. Conversely if there were multiple HandleMIDI callbacks, based on channel,, then all you have to do is cut and paste the function from one script window to the other and each channel funneling through will be entirely self contained in that function and easy to relocate, and in many cases will be easier code to understand. OOP programmers consider long winded if then statements like that to be very old school non-oop way to do it, and sometimes a PITA. There are different ways this could be handled, but the overall concept is simply that a different function will get called based on the midi channel, in order to isolate each part of a multi-timbral instrument midi flow more cleanly and elegantly.

 

 

Regarding #14, improved event.trace() to show articulation ID, I see ID on every event that has one (that is, any event with articulation ID > 0). Curious to know what kind of improvement you'd be looking for?

 

You're right I forgot art id is already there. However, beatpos is not already there, as I indicated, I could still see improvement in the trace, to show everything from Event object. I think the format of the event.tracer() method could be improved too. Of course we can always override that function as we desire, but I would prefer that their built in trace method is at least "complete" and showing us the whole event with all of its data.

Link to comment
Share on other sites

Here's an off-the-top-of-my-head Scripter wish list, some of which may mirror ideas you've already presented...

 

1) Get the Console/Logger to reflect the true MIDI output of the Scripter.

Case in point, vis a vis a slightly extreme example... A Script is programmed to pass Note Ons in real time, but it delays the corresponding Note Offs by 1 second. Now... play two staccato notes in very quick succession. The MIDI output shown in the console will be this:

 

Note On (1st note)

Note Off (1st note)

Note On (2nd note)

Note Off (2nd note)

 

The expected output, however, is:

 

Note On (1st note)

Note On (2ndnote)

Note Off (1st note, delayed)

Note Off (2nd note, delayed)

 

2) Allow Scripts to reference external text files.

 

3) Allow for Script "aliases" which reference a master.

Changes made to the master can be made to reflect in the aliases.

 

4) Have a Logic preference to allow Scripters to be displayed without the space-wasting "header".

1331765704_ScreenShot2019-01-04at5_46.14PM1.png.979b424279a05b62b8cfda8c43400069.png

5) Timing/Timers: Make it infinitely easier to program time-based functions. Having to get the date is way too unwieldy.

 

6) Menu Parameter

a) Remove the current behaviors for "menu" that result in either a menu, a checkbox, or radio buttons based on the number and content of valueStrings

b) Provide for parameter type "radio" so we can explicitly define a radio button parameter style

c) Provide for said radio buttons to have more than just two possible choices.

 

I'm sure there are more on my wish list, but that's enuf for now... :)

Link to comment
Share on other sites

I like the list.

 

Per your #1, maybe it would be good for Scipter to basically have its own built in Midi monitor, and rather then using trace to monitor that kind of activity, just be able to hit a button and see a midi monitor to the side or below the editor window as a separate pane, with a nicely formatted and fully feature midi monitor that shows exactly what is coming in, or out or both.

 

The problem with the current "trace" paradigm is that the message is logged at the time the trace() function is called, not at the time the event is scheduled for. So trace is good to understand what order your code is being executed. But as you pointed out, could get confusing when you trace those function calls in a different order then they will actually happen on the midi queue. A built in midi monitor would basically show the midi events, irrespective the order you call send()

Link to comment
Share on other sites

  • 4 weeks later...
In no particular order:

 

  1. LPX could assign duration attribute to NoteOn events when it is known(originating in region). Logic could handle NoteOff event automatically when such is the case. Able to assign duration to events for automatic NoteOff to happen, managed by LPX.
     
    ...

 

This x1000. The sendAfterMilliseconds is very finicky and often the cause of hung notes in scripter imo. I have avoided using it at all in my later scripts and instead made manual timer objects with getDate, a super clunky workaround but infinitely more reliable.

 

* Other than this referencing/importing external .js to avoid having to have the same code over and over again

* Much more flexible GUI, I am looking to AHK as an example of simple but still totally customize-able gui for similar type home-grown coding environment.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...