What Types does Kyma send over OSC?

Question

I am experiencing an odd situation with a C++ program I am developing and OSC from Kyma.

Kyma will send happily to the port of an OSCulator listener , using the the NELSendOsc class.  OSCulator will forward it to the port of my app, with no format or timestamp changing ( as far as I can see)  - that works fine in my app and with the C++ framework  I am using.
But if I try to send the Kyma messages directly to the app , the messages  don't  trigger the message received callbacks.

So I am wondering if OSCulator is somehow comforming to the Kyma output in a different way than the OSCReceiver Class of the framework I am using.

Perhaps there is a specific type of float that Kyma sends out that I should be aware of in my program?

For reference, what are the types that Kyma sends over OSC at the moment?

 

Comments

Are OSC Bundles involved? You mention timestamps which implies OSC Bundles.

What OSC framework is this?

Generally speaking individual non-bundle OSC messages are parsed first by checking for an address pattern match, and then parsing the message arguments. If you have source code for the C++ OSC library you should be able to investigate what is causing the messages to not trigger the callbacks. It could be that there is a problem with argument parsing, and it does not happen when forwarding through OSCulator because OSCulator has a different argument parser implementation.

---

I'm not using bundles as far as I am aware of. The OSCulator message monitor seems to have a time stamp , but I think it isn't the OSC Bundle timestamp, just an internal reference actually , because its on every message monitored.

I'm using iPlug2. Its OSC implementation was based on the Cockos ( Reaper ) OSCII-BOT code

https://github.com/iPlug2/iPlug2/tree/master/IPlug/Extras/OSC

---

Doug, I think you are right , but I'm confused about *where* that argument parsing is getting mis-cast or mis-interpreted. Camille ( author of OSCulator ) has informed me his code is doing anything particularly with the arguments, it treats floats and doubles as interchangeable types, so you can use one or the other transparently. Perhaps its that Kyma sends doubles, but SSC documentation states that they are floats.

---

Does your NELSendOSC class send through the Pacarana?

I briefly scanned the IPlugOSC source. From what I gathered the implementation is fairly spartan and I do not believe it handles bundle parsing - perhaps it is expected that the receiving process takes care of those?

I mentioned OSC Bundles because I would expect OSCulator to have to unpack those and its forwarding mechanism would pass on the individual messages. Since it does not appear that IPlugOSC handles OSC Bundles for you that could explain what you are seeing. That said, I would still expect that your code would receive via the callback the reference to the entire bundle message, unless the library is treating the bundle message as an ill-formed message and discarding it completely. Some well placed breakpoints or debug log statements could help verify whether this is true.

One suggestion would be to employ some type of OSC test receiver utility to monitor what is actually coming over the pipe. I normally do this sort of investigating at a very low level using a packet capture utility but I am pretty sure there is a simpler way for just examining OSC messages.

Did you consider this library for your project: http://www.rossbencina.com/code/oscpack

---

NELSendOSC does send through Pacarana, it is a Kyma sound. It uses similar Smalltalk internally as the SSC OSC Tool.

Thanks for the tip about oscpack, I hadn't come across it. I was trying to get all this working 'under one roof' so to speak. I was aware of the spartan implementation ( nicely put ) , but was wary to go into a new library. If you recommend oscpack, then I go for it!

---

I don't really have an opinion one way or the other. OSCPack is a well regarding library and its author is also responsible for AudioMulch. I suggest studying the code and understanding it before making a switch. I also would not recommend switching as a way out of the current problem. Best to find out why your current code is not working as expected and only "changing horses" if it turns out to be insufficient for your specific requirements.

I edited my previous comment after your reply, but before seeing your reply. Be sure and see what I said about bringing some debugger muscle to the table ;-)

---

This has been great help, thanks.

I did some testing with oscpack, and it looks great.

The OSC dump there showed me that Kyma is sending float32

[/test1 float32:-0.247032]
[/test2 float32:-0.98663]
[/Auto/SrcPos/z/ float32:0.00122223]

Answer 1

The type of response that Kyma sends over OSC depends on the message it is responding to (blobs or lists of integers and/or floats). Here's a list of Kyma's responses.

As far as we know, OSCulator does not alter the OSC messages unless you ask it to. Can you double check that the port number you are sending to Kyma matches the receiving port number of your C++ framework is using for its OSC listener?

Comments

Breaking it down;

TEST 1
Kyma responds to --->    Mac IP:9090 ☑︎
MyApp listens        ---> localhost:9091 ☑︎
OSCulator listens ----> localhost:9090 ☑︎
OSCulator forwards -->localhost:9091 ☑︎
...messages received in MyApp ☑︎

• Change MyApp listener port to 9090.
• Quit OSCulator to free up 9090

TEST 2
Kyma responds to --->    Mac IP:9090 ☑︎
MyApp listens        ---> localhost:9090 ☑︎
...messages are not received in MyApp ☒

I've reached out to the author of the C++ framework I am using, but I suspect he will say his software is clearly working, because of the results of TEST 1.

Any other thoughts?

---

OSCulator probably logs out of the Pacarana by sending an /osc/respond_to,i with a port number of zero when it exits. If so, the Paca(rana) will no longer send replies to that port number.

The ideal thing would be for your application to send the /osc/respond_to,i message with its port number directly to the Pacarana (without using OSCulator as an intermediary). If that is not possible, perhaps you could try using OSCulator to send an /osc/respond_to,i with the port number of your application and leave OSCulator running.

---

this is exactly what I am trying to do, but I'm not getting a response from Pacarana when I send /osc/respond_to,i from my program, probably the same root cause issue. I'm going to try and move over to a new OSC library , and hope it is compatible with the iPlug framework build structure.

---

Unfortunately I think that your next step is to do some low level packet monitoring to determine what is going to the Pacarana, and what is coming from it. tcpdump is available from the macOS Terminal and can be used to capture all network activity on a given network interface. It is very low level, and your will see a lot of activity if the same interface is your overall network connection, so best to use it with a single cable direct to Pacarana set up. I also find that this app helps interpret the captured packet traces: https://apps.apple.com/us/app/cocoa-packet-analyzer/id418357707?mt=12. Another, very popular packet analyzer tool is WireShark.