This thread was created to provide a list of JS plugins that are currently using the regxx variables for master/slave operation in REAPER. The purpose of this list is to avoid any possible collisions when using multiple plugins with global variables.

ATTN: Programmers!
Use this list to determine which regxx variables you should use in your plugins. When you upload your plugins, please add them to this list. Thanks!

ATTN: Plugin users!
Use this list to determine whether or not you will encounter any problems while using multiple master/slave JS plugins in your projects.

Thanks!

*Dear Mods...... sticky me?
*edit*
Thank you!

Last edited by d.bop; 04-13-2011 at 08:45 PM.
Reason: I got stickied :)

:-) Come on Justin, You are one of the best programmers in the world! Of course it is possible for you. Features like globally linked, runtime compiling Jesusonic is what makes Reaper superior to the rest. There would need to be time stamped, properly synchronized delay buffers. Weather it is easy or a priority right now is another question.

I am almost done on a realtime chord and scale recognition system that sends from a master track the transpose, scale, the chord and dynamics to the many children transforming midi patterns that follow. Using synced global variables would be much more ideal than duplicating and changing master connected children tracks. But I understand fixing the basic like the solo mute issues of midi tracks are a priority right now.

:-) Come on Justin, You are one of the best programmers in the world! Of course it is possible for you. Features like globally linked, runtime compiling Jesusonic is what makes Reaper superior to the rest. There would need to be time stamped, properly synchronized delay buffers. Weather it is easy or a priority right now is another question.

I am almost done on a realtime chord and scale recognition system that sends from a master track the transpose, scale, the chord and dynamics to the many children transforming midi patterns that follow. Using synced global variables would be much more ideal than duplicating and changing master connected children tracks. But I understand fixing the basic like the solo mute issues of midi tracks are a priority right now.

You could disable anticipative FX rendering, and don't use PDC, and hope for the best (or probably code something that would adapt to the PDC)... but having "synced global variables" probably would end up defying causality logic in many cases.

You could disable anticipative FX rendering, and don't use PDC, and hope for the best (or probably code something that would adapt to the PDC)... but having "synced global variables" probably would end up defying causality logic in many cases.

Well, a track with a JS writing to a global variable is like giving that track a "Send" classification to tracks with JS's reading that global variable. In which case, these groups of dependant tracks all have to be synced and rendered as a bundle and all be capable of rendering ahead, or none at all.

So perhaps than, there needs not be time-stamped buffers (which would work in send situations serving both the future (render ahead) and the present, but would cause causality ambiguities in replies from the present JS's to the future, but 2 way communication is rarely used in JS communication).

Instead this design would check for virtual send connection treatment between JS's that write, and JS's that read detected global variables.

What are your thoughts, just for the puzzle of it...

My older design was working with disabled anticipative FX rendering on tracks that needed to hear the master (for special virtual instruments like piano and electric guitar sympathetically resonating and feeding back to themselves and to the drums, vocals and everything else around them). A simple transpose was also passed to all using globals, but unless all tracks using it were anticipative disabled, you could not change the transpose in the middle of a song musically in sync. This was not needed for most songs.

The new design is using MIDI controller messages sent to children receiving all their musical guidance from the master. If the master is on live input, they all get their chord and scale updates real time, otherwise they are free to happily render ahead.

There were some challenges solved, such as MIDI messages quantized and time-stamped on the same buffer offset coming in an unpredictable order, causing pattern notes to slice and dice to zero length as they updated from some of the chords unpredictably late. These were cleaned by keeping time-stamped note buffers in JS! Your amazing new updates to JS with functions was essential!

Functions aren't global but careful naming is a good idea if you're designing or using an import file. I think function names can belong to namespaces now, so myLib.myFunc() might be a good pattern to use for that kind of thing.

My JSFX alt-tuner uses regXX in blocks of 5. It defaults to reg0-reg4, but you can set it to any block of 5. Register block 1 = reg0-reg4, block 2 = reg5-reg9, etc.
I don't use _global because I want my JSFX to work in other DAWs besides Reaper, so I keep everything ReaJS-compatible.

Is it possible to pass globals from eel to JSFX, (maybe OSCii-bot, and WALTER(?is eel?)). I realize that that they are probably implementations of eel inside different programs, and if so that pretty well would sum up why not. but It would open up (I'm gonna call it routing )routing.

for instance say you want some way to make a dockable gui (stuck in JSFX) of dynamic midi sliders or controls(OSCII-bot,JSFX) to control Reascript sytle stuff(eel) and send the data back to the Gui.

or +walter... use osciibot or jsfx to take in my controls and pass them to an eel script actively updating variables in walter.