OK, build updated once again. I fixed midi_logger, hopefully it will fix arp0 too (the optimizer was correctly optimizing out some functions that I had forgotten to mark as "non-const", oops)! Also the watch display is improved (variables now disappear on recompile if they are no longer used, and it shows you a reference count -- note that a reference count of 1 usually means a variable is either mistyped or unused).

[probably going a bit OT, sorry! ] ... and showing their folder name *after* their name, in parentheses or otherwise consistent with other plugin types (it's similar enough to plugin developer/publisher/manufacturer/whatever it means for VST(i), isn't it?). The AU plugin name formatting should also still be cleaned up as nicely has has been done for VST already recently (i.e. also not developer name first, but plugin name first). We now have slashes for JS, parentheses for VST, and colons for AU. Almost as complicated as JS syntax.

Is getting the JS plugins listed in the folder tree with subfolders instead of heaps of forward slashes really that hard? Also, renaming from FX browser? This way on each and ever Reaper update I need to check if there were any changes in all of JS effects, then substitute the filenames according to the names that I changed for those plugins, then replace. Or, alternatively, just delete the "Effects" folder altogether and use the current folder that I have (which forefeits any possible fixes to JS plugins for me in that case). It's a chore, and it would all be easier if the original file was left with the original filename, and we could simply alias it, like we can with VST plugins...

another nit i thought of that would be nice to have fixed if it's easy to do now: on macos Js doesn't seem to respect the dimensions specified in "@gfx width height". mac Js fx don't resize up or down, and always open in some smallish default size when floated. iirc, winfolk report that this works ok.

another nit i thought of that would be nice to have fixed if it's easy to do now: on macos Js doesn't seem to respect the dimensions specified in "@gfx width height". mac Js fx don't resize up or down, and always open in some smallish default size when floated. iirc, winfolk report that this works ok.

include/import support for functions (probably with .inc files in the same path as the js, and make REAPER ignore *.inc when scanning).

any rough eta on these Justin? and any chance for that precedence list? and... ReaJS? i am committed to keeping arp!0 ReaJS compatable, at least for 1.0. so all the lovely Js fixes and enhancements aren't an option unless ReaJS gets an update to include them. without them arp!0 development is pretty much at a standstill. arp!0 is close enough to 1.0 that this is only a little sad right now.

one more thing... :^) this just came up in the arp!0 thread: because automation and presets share the same @slider input code, it is not possible to have specialized automation login. from Js you can't tell the difference between loading a preset and receiving automation. this has blocked a couple of nice automation features for arp!0. not sure what a good solution for this is though. maybe it's a JS2 thing. :^) enjoy! /dan

any rough eta on these Justin? and any chance for that precedence list? and... ReaJS? i am committed to keeping arp!0 ReaJS compatable, at least for 1.0. so all the lovely Js fixes and enhancements aren't an option unless ReaJS gets an update to include them. without them arp!0 development is pretty much at a standstill. arp!0 is close enough to 1.0 that this is only a little sad right now.

I think the problem with that is that it makes everything inherently unsafe.

I would have thought the most likely problem would be the dynamic nature of deciding which function to call. I wouldn't have thought it was necessarily unsafe as long as the code parser is smart enough to call foul if you try to assign a function to a variable or vice versa.

Anyway, it would be a useful feature if it's feasible but I don't really know what I'm asking for in real terms. I won't be upset if it doesn't happen. Just wishing out loud.

OK, more bleeding edge updates are now available (different from what's in 4.23preX):

New parser, which mostly tries to duplicate the ancient JS parser. Hopefully no FX will be broken, but this needs to be tested extensively (hence it might not get into 4.23, but the feedback we get here will help determine that).

EEL user functions can now take more than 3 parameters (up to 40 for now, we can increase if necessary but that's probably overkill).

Some silly old, and probably rarely encountered precedence strangenesses have been corrected: for example, with 4.23pre6, "a=(1+5;8);" sets a to 9. The new parser evaluates it as 8.

You can now specify hex constants using 0x12345 etc, or the old $x12345.

We now can update the parser to add more new advanced features more easily.

New parser, which mostly tries to duplicate the ancient JS parser. Hopefully no FX will be broken, but this needs to be tested extensively (hence it might not get into 4.23, but the feedback we get here will help determine that).

Just out of curiosity: Is the new parser proprietary code? If not, what are you using?

The parser is made using flex/bison. We'll be posting the updates in WDL eventually.

The current (old) eel2 in WDL has two main parts: a hand written preprocessor, which handles much of the eel2 syntax (a[b], &&, ||, ?:, ; etc), and a lex/yacc based parser (for whichwhich processes basic arithmetic operations (*/+-&|), and function calls (symbol(parm)) into code. The reason for the preprocessor is that at a certain point we had the lex/yacc parser but not the source for it, and it had been modified extensively by hand.

The eel2 in this build has a new parser ([f]lex/[yacc|bison]), which re-implements the old parser, fixing a few little things in the process. All of the previous updates were much larger work, separating the parser's code generation calls from the actual machine code generation.. anyway...