tool becomes unresponsive

Renoise Tool Development
1

Hi

I’m working on a tool that allows an external application to talk to renoise over OSC, things like loading a song, sending back all track names, sending back all instrument names, sending the bpm.

All is working fine for a while. Then suddenly my tool stops responding to incomming OSC. However, since I don’t get the crash dialog, I’m not even sure the tool crashed.

Any ideas how to approach the problem? Any idea what could be the problem?

The code is on bitbucket…

2

First: remove the tablelength function. Instead of tablelength(t) you can simply use ```
#t

Also you seem to do some things double, with a big add_action method you don't use (and add_global_action, and sleep!) - you are already describing the complete behaviour for the server in the server:run clause; you don't need to use methods from GlobalOscActions and the Osc snippets together. If you place something in a tool, I believe it will always get somewhat reloaded/reinitialised when switching songs. So watch out for that and that your tool doesn't stuck. It might be the sockets are not closed in time.  
I'm not sure about what you are trying to make (controlling from the outside?), but it might be the solution to place your ideas over in the GlobalOscActions.lua instead of a tool.
3

Ok, thanks. Agreed I need to clear this up quite a bit. It’s a small part of a bigger whole, and mostly I’m just happy when it works (which it apparently doesn’t all the time)…

The tool doesn’t get unresponsive on load, but during heafty OSC communication right after load. That’s where 99% of the communication is taking place anyhow.

Regarding GlobalOscActions.lua, that would be hard to maintain, like when (if :rolleyes: ) a new version of renoise comes out, if I wish to move it somewhere else or throw it in git, right?

4

I’m having a very similar issue here I think… The OSC server just stops responding after a while… I’ve tried numerous different things.

Here’s my source:https://gist.github.com/triss/4875cd2eb5d4d83d1832

5

@Cas: shutting down, opening sockets should not be a problem in itself. I have extensively tested Duplex with a number of osc devices (hard and software) on mac, linux and windows platforms.

But don’t rule out that the problem might be outside Renoise, or a combination of circumstances?

I’ve found that the serialosc service (software driver for themonome range of controllers) will eventually stop functioning when running on windows, whereas the older monomeserial one will keep running just fine. This had me puzzled for a while…especially since serialosc works fine with most other software.

If we can reproduce a scenario in which OSC messages are generated “from somewhere else” but Renoise fails to receive them, then there is something to go hunting for. Until then, I’d be careful to set my sights only on Renoise…

6

hi, i’m the developer of serialosc.

it would be very helpful to have some instructions for reproducing this issue of messages no longer being received, or at least to have an idea of how long it takes for the messages to stop arriving. it would be super interested to see e.g. a packet capture to see if the OSC messages are somehow getting mis-routed.

7

here’s a tool with a really minimalistic OSC server… It does nothing but filter out OSC bundles and print the messages it receives.

5268 uk.tristanstrange.simpleosc.xrnx

To reproduce the problem I’ve been experiencing:

  1. start renoise with --scripting-dev flag which enables the Scripting Terminal which you’ll need to run to see the logging the tool does.
  2. Go to the Tools menu and start the Scripting Terminal.
  3. install the tool by dragging and dropping it on to Renoise.
  4. point your monome at 9997 (or edit Tools/uk.tristan.strange.simpleosc/main.lua and change the OSC port…)
  5. press buttons until the tool stops printing results

I see no error message but stop seeing any logging in the terminal.

This note on is the final packet renoise receives and prints:

02:12:15.652661 IP localhost.9998 > localhost.9997: UDP, length 40
        0x0000: 4500 0044 65e8 4000 4011 d6be 7f00 0001 E..De.@.@.......
        0x0010: 7f00 0001 270e 270d 0030 fe43 2f6d 6f6e ....'.'..0.C/mon
        0x0020: 6f6d 652f 6772 6964 2f6b 6579 0000 0000 ome/grid/key....
        0x0030: 2c69 6969 0000 0000 0000 0000 0000 0004 ,iii............
        0x0040: 0000 0001 ....

This is the first one renoise fails to print:

02:12:15.876494 IP localhost.9998 > localhost.9997: UDP, length 40
        0x0000: 4500 0044 65e9 4000 4011 d6bd 7f00 0001 E..De.@.@.......
        0x0010: 7f00 0001 270e 270d 0030 fe43 2f6d 6f6e ....'.'..0.C/mon
        0x0020: 6f6d 652f 6772 6964 2f6b 6579 0000 0000 ome/grid/key....
        0x0030: 2c69 6969 0000 0000 0000 0000 0000 0004 ,iii............
        0x0040: 0000 0000

If you need anymore I’m happy to send you a full log.

Renoise 3.0 on Ubuntu 14.04.

Thanks for looking in to this!

8

I mentioned that serialosc on windows was problematic, but I was not very specific - I’ve mostly encountered the problem on win xp.
Right now, I’m using win 7 (x64) and the m128 is happily spitting out tilt sensor messages, and has being doing so for several hours.

Will of course report here if anything unexpected happens.

9

here’s a tool with a really minimalistic OSC server

Great, I will try this out next week. I don’t have a monome, but will try sending from chuck and/or pure data.

I mentioned that serialosc on windows was problematic,

My problems were/are un linux (debian stable) + renoise 3.0…

10

ok this is interesting… looks like a problem with renoise/lua’s osc server not serialosc.

I’ve just sent a load of osc messages to my test tool via SuperCollider.

My renoise tool always stops responding after 311 test messages no matter what speed I send them in at.

Here’s the code I use to send stuff to renoise from SuperCollider:

// set up renoise as a destination
r = NetAddr("127.0.0.1", 9997)

(
    // repeatedly send a message to renoise via OSC
    // i is a counter
    t = {
        inf.do { |i|
            r.sendMsg("/test", i);
            0.0125.wait;
        }
    }.fork
)

Is some buffer in Renoise or Lua getting filled up or something?

11

Is some buffer in Renoise or Lua getting filled up or something?

Sounds like the socket is getting garbage collected.

I’m assuming you’re using the code you shared above?

In that case, try removing the “local” declaration, making it into a global variable.

local server, socket_error = renoise.Socket.create_server(
"localhost", 9997, renoise.Socket.PROTOCOL_UDP
)
12

Sounds like the socket is getting garbage collected.

Indeed it was. Setting the variable as global does seem to have fixed things!

Perhaps we should get the example in the OSC snippets updated?

Thanks very much danoise!

13

Indeed it was. Setting the variable as global does seem to have fixed things!

Perhaps we should get the example in the OSC snippets updated?

Thanks very much danoise!

Ok, so let me get this straight:

One should NOT use (as copied from GlobalOscActions.lua):

local server, socket_error = renoise.Socket.create_server(
  "localhost", 8007, renoise.Socket.PROTOCOL_UDP)

…but instead drop the “local” making the correct lua:

server, socket_error = renoise.Socket.create_server(
  "localhost", 8007, renoise.Socket.PROTOCOL_UDP)

Will test out the difference ASAP

So I’m with tris, here. We both seem to have copied flawed code from GlobalOscActions.lua, this should really get updated, better sooner than later!

14

Updated

15

Updated

Thnx!