Are concreteEventIDs "stable" across power cycling all the hardware?

Question

The problem

I've been having trouble getting "/osc/notify/vcs/... 1" to consistently give me feedback with the number of widgets. "/osc/respond_to 8000" has been pretty good, but the notify will fail again and again, and then, mysteriously work.

When I do get the number of widgets from the notify, I just continue asking until I get "number of widgets" unique widgets.  In other words, if I get back "/vcs/notify/vcs/... 42" I have a nested loop that contines to request widgets 0-41 until it actually ends up with 42 unique JSON responses, converted to Python lists, stored.

However, since I cannot reliably determine the number of widgets every time, wthout the notify response, I cannot determine if I've catalogged them all.

My question

If I've previously managed to get all the way through and have saved the label -> concreteEventID mappings, and I shut down and restart Paca and the computer, will the mappings stay the same (provided I don't edit the Sound)?

Related question

Is there some way to force /osc/notify/vcs to respond with the number of widgets? Some sort of reset? (I've also tried setting "/ocs/respond_to_default 8000" in case that would encourage better behavior, but thus far, nay. I think I've gotten "luckiest" after starting my code and then closing the sound, recycling the memory, opening the sound and doing a compile-load-start. But that is a really awkward way to fix the problem and doesn't always seem to work.) Or should I just cycle through until I start getting responses with empty strings?

 

Comments

A couple of questions:

1. Is your Python code communicating directly with the Pacarana, or is it passing through KymaConnect or some other proxy?

2. Does your OSC library's OSC_SEND command allow you to specify the port it uses to send messages?

---

1. Directly with the Paca. (We have the lesser non-rana.)
2. Yep. Well, not per message. It sets up a UDP client on the port of my choice and then works with that from then on.

At the moment, the code appears to work every OTHER run. But I don't know if that's coincidental, or actually useful info.

---

Your answer to my second question suggests that you believe that the OSC_SEND command is using the same socket that your OSC_LISTEN is using. That is something you should verify, which may entail diving into the library source. It may turn out that send and receive do not share a common socket. In fact this is what I would expect.

The question of OSC transmit port is very important to try to determine what is really happening here. The Paca uses the port of the sender to determine where to send the response. When a "respond_to" message is sent to the Paca the transmit port embedded in the message is remembered. When the Paca receives a request to send information, or a request for notifications, it examines the transmit IP address and port of the request message. It searches if it has a respond_to already set up for that pair, and if it does, it uses that to direct its responses.

So for this to work the transmit port your software uses to send the "respond_to" message must be the same as the one used by subsequent messages such as the "/osc/notify/vcs/... 1". If they are different the Paca will either not know where to send the response, or it may direct the response to a port previously registered from a previous run of your application. (The Paca has a long memory of these pairings that is only cleared with a power cycle).

So getting to the bottom of this requires some knowledge of exactly how your OSC library manages both its socket(s). The receive socket that is used to listen for incoming OSC messages is usually one that you explicitly assign. The port is either something you specify, like "8000", or you just let the OS assign one from its "dynamic port" pool. Regardless of how the port is obtained it remain constant as long as you are listening for messages on that socket.

Transmit though works a bit differently. Transmitting UDP messages also requires a socket but there is no need for it to be the same socket as the one used for listening. There is also no need for the transmit socket to remain open when it is not actively in use. So you sometimes see the following sequence used:

1. open socket
2. send a message
3. close socket

When the transmit socket is opened there is usually an option to specify the port. Typically though for transmit sockets this is left unspecified so that the OS allocates one from its dynamic pool.

So to get to the bottom of this you need to understand how your OSC library is really managing the OSC_SEND command and what transmit socket it is using, and what is the lifetime of that socket.

The Paca(rana)'s "respond_to_default" command is precisely for this type of situation where there are potentially many different senders but you want all responses to go to the same port. Its original purpose, I believe, was for the situation where multiple separate processes (applications) on the same client were communicating with the same Paca(rana). It should also work in the situation where a single process is using multiple transmit sockets, or constantly changing transmit sockets. It is though a "dangerous" command because it is dictating policy for every possible application running on your computer. A second application running in parallel with your application would probably no longer be able to properly communicate with the Paca(rana). So, for example, your application would prevent OSCulator or KymaConnect from working properly if you used the "respond_to_default" variant.

---

I've been burning the midnight (and AM) oil. So I will ponder this when awake. Probably next week, since I only get to use the Paca on Tuesdays and Fridays usually. (Yesterday into today was an exception.)

However, I can tell you that I'm explicitly setting up a listener (a threading OSC UDP server) listening on all IP's (0.0.0.0) port 8000, opening send socket on the Zeroconf (Bonjour) address of the Paca, also port 8000 and then telling it /osc/respond_to 8000.

---

Thanks, Doug, for the excellent suggestions and explanations!

Kevin, in answer to your question: Concrete event ids are created anew each time you play a Sound. They are not remembered across plays (or power cycles).  The only exceptions are those that describe external hardware resources, as listed in this table: http://www.symbolicsound.com/Learn/OpenSoundControlImplementation#About_Hardware_EventIDs.

---

Kevin, are you playing the Sound(s) before or after you send the respond_to message?  The expected order is:
1. send respond_to with your receiving port number
2. play Sounds (not necessary to re-send the respond_to message)
3. Just before exiting your program, send respond_to with 0 (to tell Paca to stop sending messages)

---

@kevin: Unfortunately what you mention about setting up the listener, etc.  does not inform what socket (port) your code is using to send to the Paca(rana). As I mentioned there is no assurance that the listening socket and the transmit socket are the same. Typically they are in fact different. So it depends how the OSC library was design and implemented.

If you are explicitly opening a send socket using Bonjour information then that is almost assuredly a different socket then the one used for listening. To reuse the listen socket you would not have created a separate send socket, and the send command would somehow need the receive socket passed as an argument (or the command invoked as a method on the socket object).

If indeed there are two sockets here, one for listening, and one for sending, then the remaining question is whether the send socket is maintained throughout the lifetime of the application. If it is, and that socket is always used to send to the Paca(rana), then the standard "respond_to" set up should work.