renoise.tool() is a nil value

Renoise Tool Development
1

I’m trying to add an app idle notifier in GlobalOscActions.lua.

I believe the syntax is this:

renoise.tool().app_idle_observable:add_notifier( send_current_line)

However this just gives me an error:

attempt to call field 'tool' (a nil value)

How can call ‘app_idle_observable:add_notifier’ in GlobalOscActions.lua?

Ideally I want to do this inside a custom OSC handler, like this:

  
add_global_action {   
 pattern = "/jgb/currentLineNotifier",   
 description = "JGB: Set up a current line notifier for idle obsr,",  
  
 arguments = { },  
 handler = function()  
 log:error("********************************* /jgb/currentLineNotifier **************************************")  
 renoise.tool().app_idle_observable:add_notifier( send_current_line)  
 end,  
}

This almost works except for the error that comes up when calling ‘renoise.tool()’.

(‘send_current_line’ is a previously defined function.)

Any ideas?

Thanks!

2

I suspect the tool api environment is not yet life when the global oscactions is being called.
Perhaps it is not being called in the active Lua thread at all…
I’m not sure the line notifier will help you in exact manners as the lua scripts are still running in the graphics thread.

3

Sadness.

I was afraid this might be the case.

4

I found renoise.tool does not work when trying to use the TestPad and thus you can’t run checks on it without actually creating a real Tool and running it. Not sure if that has been me always doing something wrong, or if you are already using it in a full tool and not just the testpad/terminal, but maybe the pointer is of some use…

That being the case I can also image it being not active for the call of GlobalOscActions.lua…

5

That may be the issue in a nutshell. I’m not using it in a tool, I’m trying to have GlobalOscAction instantiate it’s own OSC client and have it send out messages indicating the current song line number. My understanding was that I could use the app idle notification callback, but that may be a GUI-only thing.

6

You can always create a tool that is started automatically in the background as long as you take care that you poll for an existing song prior to firing up any song-API call including notifiers to Song api related calls.

7

As a work around I added a track for the sole purpose of sending MIDI notes to indicate song location. I’d prefer to not have to recreate this for every song where I want to get tracking messages, but if I cannot output this info via OSC then maybe my next best choice is to write a tool that automatically appends a timing message track.

The upside is that the MIDI messages are going to be more accurate than the OSC send using app idle. The downside is that I have to have something running that will convert that MIDI to OSC. (I’ve already solved that.)

8

Yes, renoise.tool() is only valid, well, in a XRNX tool. The testpad.lua or terminal is not running in a tool, neither is the GlobalOscMessages.lua script.

You can create your own OSC server in a tool too, so you don’t have to modify GlobalOscActions.lua.

See GitHub - renoise/xrnx: The official Renoise Lua Scripting repository for more info.

9

I’ve added a number of custom OSC handlers, some which send back info. Can a custom tool add OSC handlers as well (that are handled by the default Renoise OSC server), or does that have to happen in GlobalOscActions?

It would be easier to manage if I could avid munging the global file. It’s not a big deal (since updates are relatively infrequent), but it would make it way easier to distribute useful new OSC handlers that added to what was already in Renoise.

10

You could also embed a small client function that connects to Renoise its OSC server, so all the messages you receive on your own server are ported directly to the OSC server. And if a notifier action happens, you can send back the remote client connected to your server, a specific event. I think that this OSC proxy is the easiest solution where you can intervene in certain events.

11

No, they can’t. But this indeed would make sense.

Depending on how complex the tasks are, you probably could also use:

  
/renoise/evaluate(string)  
Evaluate a custom Lua expression (e.g. renoise.song().transport.bpm = 234).