Re: using action numbers as identifiers for OSC control surface messages

[Banned]

(Split end from another thread, see here, there, and there)

Originally Posted by diversgens

[...] Warning: the midiaction will not fit your id depending on theme and action added. [...]

Wait, what? Are (midi)action numbers not reliable identifiers?

Originally Posted by diversgens

I really don't know Banned, i hope they are but because i have had some custom midi action i have not compare my id with the default id. [...]

Originally Posted by gofer

Just caught this by coincidence and am not sure whether it's resolved in this thread.

Action numbers (in any action list context) are only reliable identifiers across different installs for inbuilt stock Reaper actions. For both, custom actions and extension actions, you need to use the Custom Id string instead of the Cmd Id number, as the Cmd Id's are dynamically applied to them at Reaper startup.

Use the function NamedCommandLookup to translate Custom Id to the current Cmd Id.
In Reascript it would look like

Create_CClane =  RPR_NamedCommandLookup('_S&M_MECREATECCLANE')
RPR_Main_OnCommand(Create_CClane, 0)

[...]

Thanks gofer! Good thing you stumbled on it. Serendipity FTW.

In the context of OSC control surfaces, I don't see how to do such a thing, unfortunately.

So far, I have only relied on stock REAPER actions myself (and avoided them wherever OSC 'actions' are available because they support feedback, while actions don't). But this is definitely an issue that needs to be addressed in order to achieve (full) compatibility with custom actions and extension actions.

I still haven't played with ReaScript yet (it's on my seemingly *endless* to-do list ), but perhaps there's a way to combine ReaScripting with OSC control surface support to tackle such issues. Still, I think it would be preferable to deal with them without resorting to ReaScripting. I'm not sure until I actually try of course, and I have no objection to using ReaScript, but it just seems to me that the appropriate place to deal with this for OSC control surfaces is in the specification / configuration for OSC control surfaces themselves. Perhaps we should just think of an appropriate FR to extend OSC control surface support - I don't yet have any ideas on that. To anyone concerned, please chime in with your ideas and thoughts. Especially if you rely on custom / extension actions!

[gofer]

First off, I don't know whether all this is a problem for OSC action binding at all. Someone should put it to a test. I can only tell what I know about triggering actions from ReaScript. In case someone goes in and uses "Add shortcut" in the action list and binds to an OSC message it should work alright, but I can imagine there are problems when someone shares OSC layouts (is that the right term here?) which use custom and extension actions bound to OSC by using CMD Id.


A bit more about the ReaScript side, maybe something applies:
Using custom actions is actually not a good idea with ReaScript (if it's to be shared), as the Custom Id string Reaper generates when you create a custom action will not be the same for any two users creating the same custom action. I think the Custom Id string will be the same if user B imports a *.ReaperKeymap file with the custom action user A shared, but I am not even sure there. So while for extension actions the Custom ID is hand coded by the developers and reliably the same for all users this does not apply to custom actions.

The way to deal with custom actions in Reascript is straightforward: don't use them. You just let the script trigger the individual actions the macro would consist of. Basically rebuilding the custom action. I don't know whether this is possible with the OSC implementation (trigger multiple actions in a row with a single command) but would think so.

What the solution for extension actions would be in the OSC domain (if it's a problem), I don't know. If you can't do NamedCommandLookup(Custom ID string) to find out the Cmd ID of the action in the current install, the first thing I would try is trigger the extension action with the custom ID string. Maybe they implemented a sort of automatic NamedCommandLookup function (which I would like to see for ReaScript as well, then ).

[Banned]

I may have figured out a practical workaround for triggering a limited set of actions with unreliable action IDs in a more reliable manner: it involves making toolbar buttons for them, (selecting the toolbar and then) triggering the toolbar button using the dedicated actions for this purpose (which are native actions, and thus have reliable IDs). That way we can use the number of available toolbars multiplied by the number of toolbar buttons that can be triggered via an action. Unfortunately, only actions for the first 16 buttons are supported. It would be nice if this number could be raised a little bit (and not only as a workaround for this particular issue).

Of course, custom toolbar buttons can not be relied upon not to change between installs of different users and so on, and it needs some additional configuration, but at least it seems to take the unreliability of custom action IDs out of the equation.

[Banned]

More general discussion of this issue in this thread.

[EricM]

Hi,

I've just installed TouchOSC and researched the whole
OSC protocol implementation on both ends, and I still
cannot find a solution to reliably recall non-native
action using Custom ID via OSC.

Is there no way to call that string directly from the
remote control app or using some kind of a lookup function
or manual definition in the .ReaperOSC file?

Maybe a way to call a phyton script through OSC that
would perform the lookup, if OSC parameter can be
passed to the script?

It's seems completely unreasonable to not have static IDs
for non-native functions, as the dynamic IDs will ALWAYS
change by any update of reaper, extensions, or changes in
user actions.

Any new insight on the subject greatly appreciated.

e

[EricM]

OK nevermind, I found a simple solution:

I've set the OSC message to whatever I want, for example
'/loadtrack/slot/01' which I than learn to my custom macro
that loads track template at slot 01 (but also unarms all
tracks before doing so), this way the ID calling is not
needed, and mapping is always static.

e

[Banned]

Originally Posted by EricM

[...] I still
cannot find a solution to reliably recall non-native
action using Custom ID via OSC.

Is there no way to call that string directly from the
remote control app [...]

Hi Eric,

I'm not sure about TouchOSC specifically, but sending a string with a Custom ID should work, using this OSC 'action description' in the .ReaperOSC config file:

ACTION s/action/str

For example, if for some custom action, REAPER would have assigned Custom ID "_972d01de92474c04889cd9bbbdf8c8d5", to trigger the action I send a message like this:

/action/str [s] _972d01de92474c04889cd9bbbdf8c8d5

Originally Posted by EricM

It's seems completely unreasonable to not have static IDs
for non-native functions, as the dynamic IDs will ALWAYS
change by any update of reaper, extensions, or changes in
user actions.

Afaik, the 'Cmd ID' is 'dynamic' (i.e. subject to change between installs), but the 'Custom ID' is static.

Hope this helps...