|
|
|
09-15-2019, 04:08 PM
|
#1
|
Human being with feelings
Join Date: Dec 2011
Location: San Jose, CA, USA
Posts: 115
|
NamedCommandLookup() for a ReaScript Action doesn't work in __startup.lua on Mac Only
Sorry for the longish title.
Reaper v5.983/64 for Mac
I'm trying to launch a ReaScript at Reaper startup that uses defer() and rather than using dofile, which keeps the __startup.lua script running forever, I wanted to trigger an action.
The following code in __startup.lua shows an int for "val" on a Windows machine but on a Mac it always show '0':
Code:
val = reaper.NamedCommandLookup("_RSf8e4f6430c6d03c69b2d5f2519ef97465317e503")
reaper.ShowConsoleMsg(tostring(val))
Also, it does appear to work correctly for built-in actions such as "Transport: Play", just not actions associated to a ReaScript.
Code:
val = reaper.NamedCommandLookup("1007")
Please let me know what additional information is needed.
Thanks,
Ken
|
|
|
09-15-2019, 04:55 PM
|
#2
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,812
|
This seems to work as expected here, on a mac.
|
|
|
09-15-2019, 05:17 PM
|
#3
|
Human being with feelings
Join Date: Dec 2011
Location: San Jose, CA, USA
Posts: 115
|
Grrr. I forgot to mention that it works if Reaper is already up and running. It's only on a cold startup.
Also, I'm on MacOS 10.14.6 in case that matters.
I reproduced the problem on a completely "virgin" Mac so it's not something specific to one system.
Ken
|
|
|
09-15-2019, 05:44 PM
|
#4
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,812
|
The screenshot above is from a cold start, after which I opened the editor to show __startup.lua.
|
|
|
09-15-2019, 06:30 PM
|
#5
|
Human being with feelings
Join Date: Dec 2011
Location: San Jose, CA, USA
Posts: 115
|
I just knew it wasn't going to be THAT simple.
Let me put more work into narrowing it down and I'll post back.
Thanks,
Ken
|
|
|
09-16-2019, 09:27 AM
|
#6
|
Human being with feelings
Join Date: May 2017
Location: Leipzig
Posts: 6,628
|
Could you try older versions of Reaper as well?
|
|
|
09-16-2019, 03:45 PM
|
#7
|
Human being with feelings
Join Date: Dec 2011
Location: San Jose, CA, USA
Posts: 115
|
Sorry for the delay. A work emergency took priority this morning. Unfortunately, by the time I got back, there had been a power outage and both MBPs had gone to sleep. After waking them up the problem is no longer reproducible.
I'll keep an eye out and let you know if it comes back. Any pointers on what to capture if the problem does come back?
Thanks,
Ken
|
|
|
09-17-2019, 05:16 AM
|
#8
|
Human being with feelings
Join Date: May 2017
Location: Leipzig
Posts: 6,628
|
That's indeed weird.
The best thing you can do: when the problem occurs again, see what you've done/changed between the last time you've run Reaper without problems and this time, where Reaper has these problems.
Oh, and you could build in a check in your __startup.lua. Every time NamedCommandLookup returns 0, although it should return something else, pop up a message:
reaper.MB("Here we go again: The Bug has returned!", "A Bug's Life", 0)
This should give you an indicator to when the problem rearrives.
|
|
|
06-29-2020, 09:38 AM
|
#9
|
Human being with feelings
Join Date: May 2016
Location: out west
Posts: 301
|
"Bug" confirmed
Hi,
I can confirm this behavior in a slightly different context on Windows - I assume it applies to all Reaper versions and OSs:
I have written a C++ plugin and use NamedCommandLookup upon Reaper startup when the plugin gets registered.
NamedCommandLookup will return the proper integer ID for:
- native Reaper actions
- SWS actions
- but NOT for any other actions starting with _RS.......
:-(
Once Reaper is up and running NamedCommandLookup does work as intended.
EDIT: I understand if you argue that this is not a bug but a behavior resulting from reassigning _RS.. IDs to scripts every time on startup. My question then would be: How does my plugin know when Reaper is ready to report back the IDs?
Last edited by brummbear; 06-29-2020 at 09:45 AM.
|
|
|
06-29-2020, 10:04 AM
|
#10
|
Human being with feelings
Join Date: May 2015
Location: Québec, Canada
Posts: 4,964
|
Quote:
Originally Posted by brummbear
I have written a C++ plugin and use NamedCommandLookup upon Reaper startup when the plugin gets registered.
NamedCommandLookup will return the proper integer ID for:
- SWS actions
|
If you're running SWS actions straight from the plugin's entry point: there are no guarantees that SWS will always be loaded before your plugin. It's safer to defer running startup actions until REAPER has finished loading. This can be done using a single-shot timer (eg. using plugin_register).
|
|
|
06-29-2020, 10:53 AM
|
#11
|
Human being with feelings
Join Date: May 2016
Location: out west
Posts: 301
|
Hi, Christian - thanks for your reply! My plugin is reading from an .ini configuration file at startup to populate a list of action IDs which later can be triggered from a control surface.
Thus I only need to get the IDs, won't run any actions or scripts during the startup phase. This seems to work fine for everything but the ReaScript related IDs. Probably just too early in the startup process...
Now I am thinking to rewrite the plugin so that it will read the .ini file at the first time when the user actually enters my "actions menu", i.e. the list will be populated at runtime. This means there will be a tiny delay from a user perspective when entering this mode for the first time. Thereafter the list will persist in memory. No big deal, would have been a bit nicer (and "architecturally cleaner") if possible during startup when .ini files should be read....
Cheers!
|
|
|
06-29-2020, 12:12 PM
|
#12
|
Human being with feelings
Join Date: May 2015
Location: Québec, Canada
Posts: 4,964
|
Quote:
Originally Posted by brummbear
Thus I only need to get the IDs, won't run any actions or scripts during the startup phase. This seems to work fine for everything but the ReaScript related IDs. Probably just too early in the startup process...
|
Instead of "running SWS actions" I should have said "getting the ID of SWS actions". NamedCommandLookup only works if SWS has been loaded earlier. Plugins can be loaded in any order.
|
|
|
06-29-2020, 01:01 PM
|
#13
|
Human being with feelings
Join Date: May 2016
Location: out west
Posts: 301
|
Quote:
Originally Posted by cfillion
Plugins can be loaded in any order.
|
good to know -thx! Hence no activities during startup between plugins that depend on each other i guess. Seems reasonable to defer such things
|
|
|
06-29-2020, 02:48 PM
|
#14
|
Human being with feelings
Join Date: May 2017
Location: Leipzig
Posts: 6,628
|
Would it be possible to simply check time and again with NamedCommandLookup() until a number!=0 is returned?
Because in that case, you would be able to "wait" until SWS's actions are available.
|
|
|
06-29-2020, 03:19 PM
|
#15
|
Human being with feelings
Join Date: May 2015
Location: Québec, Canada
Posts: 4,964
|
Waiting one timer cycle (= until the main thread finishes its startup work) should be enough.
|
|
|
06-29-2020, 10:10 PM
|
#16
|
Human being with feelings
Join Date: May 2016
Location: out west
Posts: 301
|
Working as expected now. I moved the respective code section into the Run() function of my csurf plugin. Run() gets called at least once before the plugin tries to convert action IDs via NamedCommandLookup. By that time all extensions seem to be loaded and the names resolve fine.
Thanks again for your helpful input - much appreciated!
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 09:10 PM.
|