About nonstandard OSC Type Tag "T", "F" and "N"

[cleemy-desu-wayo]

osc-ruby seems like support nonstandard Type Tag "d".
#8

It would be even more useful if it also supported "T", "F" and "N".

Adding support for these seems relatively easy, because "No bytes are allocated in the argument data".

I have tried writing a monkey patch, but this is not yet well tested.
https://gitlab.com/cleemy-desu-wayo/outvoke/-/snippets/4875923

[aberant]

I'll be able to look at this next week

[cleemy-desu-wayo]

I have no reason to rush. I thank your interest in this proposal

[cleemy-desu-wayo]

Regarding PR #24, I think that if we don't solve this argument issue first, Type Tag "N" may not work properly

[cleemy-desu-wayo]

Just to be sure, here are some simple steps to confirm why it is better to resolve PR #24 in good time. These steps are just a quick hack to avoid defining new classes.

Step 1: add the following line to Message#initialize in lib/osc-ruby/message.rb

        when NilClass; obj = Object.new; obj.define_singleton_method(:val) { nil } ; obj.define_singleton_method(:tag) { "N" } ; @args << obj

Step 2: add the following line to OSCPacket#initialize in lib/osc-ruby/osc_packet.rb (and probably add a comma to the previous line)

       "N" => lambda{nil}

For now, this change will enable the server side (OSC receiver side) to handle OSC Type Tag "N". However, it should behave as if there is an extra nil at the beginning of the received OSC message.

The extra nil seems to be caused by an extra nil being passed to Message.new (Message#initialize).

[aberant]

do you know of any free software or library that supports the "T", "F", "N" OSC tags? I'd like to test this against a working system

[cleemy-desu-wayo]

if you're okay with Python, there's python-osc:
https://github.com/attwad/python-osc

I wrote some simple samples for testing "T", "F", and "N" with python-osc:
https://gist.github.com/cleemy-desu-wayo/590a22d5fb4e3f813b06dcc2fef9ae77

Although they're proprietary software, the VRChat client and the Resonite client do use "T" and "F".

From the VRChat client, "T" and "F" are sent to /avatar/parameters/Grounded at the moment the avatar leaves the ground (e.g., when jumping) and at the moment it lands.

For the VRChat client receiving data, the 2nd arg of /chatbox/input is either "T" or "F".
https://docs.vrchat.com/docs/osc-as-input-controller

We can try these out using just the VRChat client; no need to create anything in Unity or elsewhere.

Resonite offers a great deal of flexibility, but it's a bit complicated. Here's a video explaining how to receive OSC in Resonite:
https://www.youtube.com/watch?v=gvbZV_x9cak

[cleemy-desu-wayo]

In the case of Pure Data, it appears that OSC Type Tags "T", "F", and "N" can be sent using sendtyped.
https://gist.github.com/cleemy-desu-wayo/9d314e448b9f0edffcb2ffa503c3e824

i know absolutely nothing about Max/MSP...

[cleemy-desu-wayo]

I tried out SuperCollider 3.13.0. When receiving OSC, simply using OSCdef seems to handle the "T", "F", and "N".
https://gist.github.com/cleemy-desu-wayo/ed47772c4e26841bb6ad17810c1953c1

When sending OSC, I don't know if there is an easy way like sendtyped in Pure Data.

[cleemy-desu-wayo]

I tried out Processing 4.4.7 (from snap) and oscP5 0.9.9.
https://gist.github.com/cleemy-desu-wayo/e966a18706530e3af61867b2b3808d24

For both sending and receiving, oscP5 seems to handle "T", "F", and "N" well.

[aberant]

wow, thanks a ton. this is very helpful. I think for integration testing python-osc is my best bet, but the Pure Data support is also interesting.

sorry i have been traveling a lot this month and haven't had much a chance to work on this. i'm back now with no trips for a while so i should have some time soon.

[aberant]

would you be able to test out the branch I'm working on and see if it meets your needs?

If you use bundler, use something like this in your project:

gem 'osc-ruby', :git => 'https://github.com/aberant/osc-ruby.git', :branch => 'add-types-t-f-n'

[cleemy-desu-wayo]

to be honest, I've never used bundler before, but it seems perfect for this kind of testing, so I will try your dev branch via bundler

[cleemy-desu-wayo]

in the use case I have in mind, the dev branch actually works fine