API: Access to "ReaScript: Run reaScript (EEL, lua, or python)..."

[Lokasenna]

Since some tasks are better suited for one scripting language over another (Lua for ease of writing and better GUI capabilities, EEL for audio processing, etc), it would be really handy if scripts of different languages could call each other just like a user clicking ReaScript: Run reaScript (EEL, lua, or python)... on their own.

At a basic level, it could look like:

--Lua script

reaper.SetExtState("my_script", "vars", "1,5,a")
reaper.RunReaScript("Scripts/my_other_script.eel")


-- EEL script (written as Lua because I suck at EEL)

vars = reaper.GetExtState("my_script", "vars")
retvals = do_some_complicated_audio_processing_using(vars)
reaper.SetExtState("my_script", "retvals", retvals)


--Lua script

reaper.defer(keep_checking_for_ExtState_retvals)
reaper.ShowConsoleMsg("Got the following retvals: " .. retvals)

Or, if some kind, generous, and sexy developer felt like it, passing arguments back and forth to avoid all the ExtState business:

--Lua script

local retvals = reaper.RunReaScript("my_other_script.eel", arg1, arg2, etc)

Cheers.

[lb0]

Originally Posted by Lokasenna

Or, if some kind, generous, and sexy developer felt like it, passing arguments back and forth to avoid all the ExtState business:

--Lua script

local retvals = reaper.RunReaScript("my_other_script.eel", arg1, arg2, etc)

This would be amazing!!

[X-Raym]

+1. !!

[amagalma]

Yes please!!

[Meo-Ada Mespotine]

+1000
Especially the parameter/avoiding extstate-stuff

@lokasenna
Regarding your first FR, do you mean, mixture of several programming languages in one script, so ReaScript would treat the individual parts of the code as individual scripts during execution?

[Lokasenna]

Originally Posted by mespotine

+1000
Especially the parameter/avoiding extstate-stuff

@lokasenna
Regarding your first FR, do you mean, mixture of several programming languages in one script, so ReaScript would treat the individual parts of the code as individual scripts during execution?

Sort of - being able to call an EEL script from a Lua script. They would be completely separate processes, which we can already do manually:

- Run the Lua script
- Have it store some variables
- Use the action list to run the EEL script
- Have it load the variables and do stuff
- Have it save the returned value
- Have the Lua script waiting with a defer loop until it sees the returned value as an ExtState

At the moment we can do this via Main_OnCommand if the EEL script is registered as an action, whereas being able to call them directly would mean only your "main" script needs to show up. If a script had several different audio processing features written in EEL with a Lua frontend, direct access would be much simpler.

[tXShooter]

Originally Posted by Lokasenna

At the moment we can do this via Main_OnCommand if the ... script is registered as an action...

What's the difference between an Action ID and a Command ID?

How does one register a script as an action, and can that action be called from outside of Reaper, ... saaayyy Autohotkey, perhaps?

[cfillion]

Originally Posted by tXShooter

What's the difference between an Action ID and a Command ID?

A script is registered as an action when it's loaded in the Action List. Command is a synonym for action. But to answer your question: there are two kinds of command IDs. The built-in actions have a fixed numeric ID which can be directly used. Extension plugin, custom and script actions are identified by a "named command ID" (for scripts it's a hash derived from the path). These actions also have an underlying numeric ID but, because it's determined at runtime, it's not guaranteed to always be the same.

A named command ID must be converted to its current underlying numeric ID using NamedCommandLookup before being able to run the script using Main_OnCommand or an external program like AutoHotkey posting a WM_COMMAND message.

[tXShooter]

Originally Posted by cfillion

A named command ID must be converted to its current underlying numeric ID using NamedCommandLookup before being able to run the script using Main_OnCommand or an external program like AutoHotkey posting a WM_COMMAND message.

I'm guessing that when you say, "... because it's determined at runtime, it's not guaranteed to always be the same", that these Command ID's aren't dependable from one Reaper Session to the next?

In theory then, could one create a small script to output the list of Command ID's (via NamedCommandLoopkup to either console, clipboard, or file), and register that script to a hotkey, then have that hotkey activated by AHK? Then AHK could receive that information, and from that point any 'registered' scripts could be used externally and dependably (during that Reaper session only, of course).

Does that make sense and sound about right?

[cfillion]

Originally Posted by tXShooter

Does that make sense and sound about right?

That would work. Alternatively, if AHK supports making HTTP requests, you could use REAPER's web interface feature. It allows running actions from the main section directly using their named command IDs: /_/command-id-or-named-command-id-here.

[Buy One]

Bump........

[Dex]

+1