Receiving OSC bundle messages is cumbersome

[korfuri]

Hi, I'm trying to use OSC to receive messages in Sonic Pi. Specifically I'm sending these messages from VCV Rack using the Trowasoft modules in a way described here. I'm facing a small issue that make the experience slightly annoying. I'm not sure whether the issue lies with Sonic Pi, Trowasoft's implementation of OSC, or a mix of both.

I'm running a 3.2.0-dev build from commit ab31ae0 built with the ubuntu-18.04 script on Linux Mint (based on Ubuntu bionic). Receiving remote OSC messages is enabled.

Trowasoft's implementation sends all OSC messages as bundles. I don't know if that's bad, from my reading of the OSC docs it sounds like recipients should understand it just fine. But Sonic Pi shows the received messages as /osc:127.0.0.1:35042/#bundle [] in the cues list, and indeed trying to unpack the values using sync gives me an empty array ([]). From this it seems that Sonic Pi is just treating the bundle as an opaque blob and doesn't unpack the values inside. This means that all I can get is a cue that a bundle was received, without added info, and without a way to distinguish what path(s) the bundle contains.

Example code I'm using:

live_loop :receive do
  use_real_time
  use_osc_logging true
  voltage = sync "/osc:*/#bundle"
  print voltage   ## always prints `[]`
end

I've tried syncing on /osc:*/*, /osc:*/ch/1 (the path I'm sending to from VCV Rack), and variants of that to no avail.

I think ideally the bundle should be expanded (recursively if needed, as the spec says a bundle can contain other bundles) and each OSC message in the bundle should be processed as an incoming message from the same source as the parent bundle.

[llloret]

Hi, Uriel, I am Luis, the author of the software that Sonic Pi is using to work with OSC and MIDI messages, "osmid". The library that I am using to decode the OSC messages, oscpack, should be decoding the bundles, so I need to look at this. Would you mind opening an issue here: https://github.com/llloret/osmid/issues. In there, it would be great if you could post the contents of the bundle, and I will have a look at it to see why it is not working. To be honest, we did not think of using Bundles, so did not do any tests on it, but I think it would be nice feature to support. Luis

…

On Mon, 10 Jun 2019 at 08:46, Uriel Corfa ***@***.***> wrote: Hi, I'm trying to use OSC to receive messages in Sonic Pi. Specifically I'm sending these messages from VCV Rack <https://vcvrack.com> using the Trowasoft modules <https://github.com/j4s0n-c/trowaSoft-VCV> in a way described here <https://in-thread.sonic-pi.net/t/sonic-pi-with-vcv-rack/2394/11?u=korfuri>. I'm facing a small issue that make the experience slightly annoying. I'm not sure whether the issue lies with Sonic Pi, Trowasoft's implementation of OSC, or a mix of both. I'm running a 3.2.0-dev build from commit ab31ae0 <ab31ae0> built with the ubuntu-18.04 script on Linux Mint (based on Ubuntu bionic). Receiving remote OSC messages is enabled. Trowasoft's implementation sends all OSC messages as bundles. I don't know if that's bad, from my reading of the OSC docs it sounds like recipients should understand it just fine. But Sonic Pi shows the received messages as /osc:127.0.0.1:35042/#bundle [] in the cues list, and indeed trying to unpack the values using sync gives me an empty array ([]). From this it seems that Sonic Pi is just treating the bundle as an opaque blob and doesn't unpack the values inside. This means that all I can get is a cue that a bundle was received, without added info, and without a way to distinguish what path(s) the bundle contains. Example code I'm using: live_loop :receive do use_real_time use_osc_logging true voltage = sync "/osc:*/#bundle" print voltage ## always prints `[]` end I've tried syncing on /osc:*/*, /osc:*/ch/1 (the path I'm sending to from VCV Rack), and variants of that to no avail. I think ideally the bundle should be expanded (recursively if needed, as the spec says a bundle can contain other bundles) and each OSC message in the bundle should be processed as an incoming message from the same source as the parent bundle. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2085>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJOL45D6JY5XZSDJRFNRZTPZYBHHANCNFSM4HWRFXKQ> .

[korfuri]

Thanks! I was under the impression that the OSC decoding was done in app/server/ruby/lib/sonicpi/osc/oscdecode.rb (which definitely has no bundle support). I've opened llloret/osmid#54 to track the issue on the osmid side, with a pcap.

[ethancrawford]

I'm not fully across all the details, so this may not be thoroughly relevant, but are the following comments about fast_osc's capabilities related? https://github.com/samaaron/sonic-pi/blob/master/app/server/ruby/vendor/fast_osc-0.0.12/README.md#usage

[llloret]

Hi, yes, perhaps I am confused at what you are trying to do. If you are sending OSC directly to Sonic Pi, then it is not going through osmid at all.

…

On Mon, 10 Jun 2019 at 10:01, Uriel Corfa ***@***.***> wrote: Thanks! I was under the impression that the OSC decoding was done in app/server/ruby/lib/sonicpi/osc/oscdecode.rb (which definitely has no bundle support). I've opened llloret/osmid#54 <llloret/osmid#54> to track the issue on the osmid side, with a pcap. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2085>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJOL47KIRHQZMQUPAJ5XJTPZYJ7XANCNFSM4HWRFXKQ> .

[llloret]

@ethancrawford, yes, I think you are right. This is being processed in Sonic Pi, osmid has nothing to do with it.
Apologies for the confusion.

[korfuri]

I'm sending OSC over UDP to Sonic Pi from another application running on the same machine. There's no MIDI involved, so I agree with you that this doesn't look like it's going through osmid. Thanks for looking into it anyway :)

@ethancrawford thanks for the pointer. The doc is about encoding, not decoding, but it looks like a promising place to look. That the bundles I'm interested in have a single message inside of them (at least for now, I don't know if the source I'm using is able to send bundles with more than one message). Here's a pcap of such a bundle: https://packettotal.com/app/analysis?id=82ea8bf5e82110cde3d832f05976f76e

It looks like the file I found is a copy of fast_osc's decoder, which does not support bundles for decoding (and per the doc above, only has partial support for encoding). However I don't know Ruby well at all so I may be missing something.

[samaaron]

Yes, unfortunately we don't currently support receiving OSC bundles at this stage. Were you using them in an attempt to schedule events for the future or attempting to have multiple messages be executed simultaneously?

[korfuri]

The latter: this is all real-time, and my sender is packaging everything in bundles (even when it's sending a single value). I have no need for future-time bundles.

I've opened j4s0n-c/trowaSoft-VCV#35 to see if they can remove the unnecessary bundling but I think the more proper fix would be to support bundles in Sonic Pi since they're part of the OSC spec.

[samaaron]

@korfuri

Agreed, it would be lovely to support OSC bundles natively in Sonic Pi. However, it's not a majorly high priority for me right now (as it's not a trivial fix). Instead, I'm working on getting 3.2 out of the door which still has a lot of work left - especially with the Windows building process.

Happy to consider pull requests though!

[korfuri]

Thanks, I did try my ruby-fu against that problem. I managed to get what looks to me like a reasonable patch in #2086 for the Ruby implementation of fastosc. I have not looked into porting the change to the C version yet either, because I'm in very unfamiliar territory here so I figured I'd request some feedback before continuing:

• Does this approach look good to you? The main issue I see is that I'm changing fastosc's API.
• Where should I send fastosc contributions? I assume they should go to fastosc's repo directly but I don't know where that is.

If I should proceed I'll take a stab at fixing and adding relevant tests, and at changing the C extension.

Thanks!

[ethancrawford]

@korfuri - fast_osc comes from https://github.com/xavriley/fast_osc 🙂
(Edit - ahaha. Just saw your comments on your related PR - you were guessing correctly).
/cc @xavriley

[llloret]

Hi, I am working on @xavriley's code to provide this as part of the FastOsc library in C. If you can wait a couple of days I think it should be ready by then. I will do a Pull Request on Xavier's repo when done. It is looking good, but need to do some more tests. Luis

…

On Tue, 11 Jun 2019 at 07:04, ethancrawford ***@***.***> wrote: @korfuri <https://github.com/korfuri> - fast_osc comes from https://github.com/xavriley/fast_osc 🙂 /cc @xavriley <https://github.com/xavriley> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2085>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJOL453QZKBGTUVRQCT2QTPZ455LANCNFSM4HWRFXKQ> .

[korfuri]

@llloret - wonderful, thank you! I have no issues waiting, in the meantime I can just run my own fork and force it to use the Ruby version :)

I'm closing the PR now, I assume you'll merge that same code directly into @xavriley 's repo with your C changes.

[xavriley]

Luis' PR is in xavriley/fast_osc#3

@korfuri For the pure ruby version (#2086) I'm happy to look at patches into fast_osc directly but I'd rather create a new method like FastOsc.decode_bundle and also FastOsc.bundle? than change the existing API if possible.