So... the Logic Pro X and Effects manuals are now online. Maybe I missed them before, but anyway... I noticed that with the release of Logic 10.3.2. that there is now a new momentary parameter in Scripter. I gave it a quick go, but I'm a bit puzzled. Could anyone reproduce and report back their results or opinions?

To break it down, from what I've seen so far, the "momentary" button has only 1 state, and that is the release state. When you press the button, nothing happens, When you release the button, then ParameterChanged reports it as having a value of 1. Note that its not mentioned in console when the script is first run. Until now, all parameter states were reported at evaluation time (correction: except for labels!). It seems momentary is an exception. For example, when I run the above, I get a trace saying this:

I would really like to know if this is reproducible, or is it just my setup. I mean... why can't the button have at least a minimum of two states, such as 'Press' (e.g. 0) and 'Release" (e.g.1 as it is). That way you could activate a randomiser for the duration of the button press... I would have thought that to be natural. I'm a little baffled! Anyone else?

@Jordi - thanks for the feedback. Almost relieved that you also find it weird. Haven't put too much thought into use cases.

Moving on... as always, fascinated by the language that never works. So, let me get this straight - the const keyword is an ES5 keyword AFAIK, so not too surprised by that one... but template literals ARE supported by the JavaScriptCore on OS X Yosemite 10.11.6?

Curiosity is big, but investigating various Logic Pro X / JavaScriptCore and OS variations without access to those configurations myself would probably not be a good idea. All I can really suggest is that hacking or attempting to update or bypass the os framework:

/System/Library/Frameworks/JavaScriptCore.framework

is most likely a more tricky and non-recommendable path that updating the OS, yet the effects of updating the OS has very real and annoying issues in a music production context on Apple products (for me to date, at least). I see that you have the latest stable release of Yosemite, right? When was that released? I wonder if that shipped with a more recent JavaScriptCore.

Thinking out loud, I wonder if a poll involving ES5/6 support on JavaSctiptCore in Scripter would be useful to anyone?

DISCLOSURE :It is my assumption through testing and upgrade experiences, but without any concrete proof, the Logic Pro X uses the system JavaScriptCore. I think its a rational assumption but am open to suggestion. Also, apart from just outright curiosity, I have to disclose some personal interest in a poll like that as I'm writing an ES6 Scripter library at the moment and I would like to be sure of which platform combinations would suit it. I'm pretty confident that I could keep it ES6 based and have it transpile to an ES5 output during the build process if there was any need.

Nope, let and const declarations are both Ecmascript 2015 (AKA ES6). Template literals (also ES6) work fine in Scripter.My question was specifically about arrow functions. You have them in your code example but arrow functions don't work for me in Scripter:

@Jordi - my bad - I could have sworn I used const in an ES5 context in the past, but then again, I avoided ES5 like the plague. You are right - the formal specification for const arrived with ES6! Anyhow - more awake now. I hear you with regard to arrow functions and see the conundrum - it would seem that whatever version of JavaScriprCore you have seems to have mixed support for both language editions. Madness! If you can pick out that level of detail, you know that you could refactor the function declaration... but man, that type of thing (Scripter and JavaScript idiosyncracies) has driven me mad, thus the library concept. I don't know how to fix that rather than update to Sierra, but that's pretty drastic. Thanks for the insight. Will investigate feasibility of transpiling build from ES6 to ES5/4. Bloody annoying state of affairs!

Back at a computer. As far as I can tell the reason for this (other than cosmetically nice button) is to not have it fire (as opposed to a checkbox) when the script initialises (*explanation below)*When using a chechbox for a button, I usually go SetParameter(p,0) in callback instantly to mimic a button. This makes the callback fire straight away on running script.

I just used it in a custom script for a client. Before "momentary" I had to put in a "firstRun" variable to avoid PluginParameter callbacks firing on initialise.In the script I am making right now, without momentary or a "firstRun" variable, the script would fire a fade of a CC value instantly upon running which would kill the whole purpose.

I think the purpose of this UI element is simple, its a button, nothing more. It doesn't keep state or anything. Its just something you can click on the UI and when you do, ParameterChanged() will be called showing a value of 1 that it was clicked on (and released). Do whatever you want with that.

Could be useful as a panic button, for example, stuff like that where you just hit it and specifically DON'T want any kind of state to change.

But one thing that is annoying is that the label for the button and the text on the actual button is the same... which is kind of redundant, unless there is some way to make the text on the button different then the name of UI control.

I think the purpose of this UI element is simple, its a button, nothing more. It doesn't keep state or anything. Its just something you can click on the UI and when you do, ParameterChanged() will be called showing a value of 1 that it was clicked on (and released). Do whatever you want with that.

Yeah, that's basically what I was saying. Earlier you had to jump through some hoops to make the checkbox stand in as a button. For any sort of commercial programming this Parameter is useless because nobody has the latest update ever and you can forget about MainStage users.