OSC Spec 1.1 legacy optional types

[elliott-liu]

I need to send MIDI via OSC.

As per the OSC Spec 1.0 (see second table "nonstandard argument types") we should be able to use a OSC Tag Type of m (4 byte MIDI message. Bytes from MSB to LSB are: port id, status byte, data1, data2).

In my code I'd like to do something like this (I'm using TypeScript):

client.send({ address: "/midi", args: [{ type: "m", value: midiMessageBytes as Buffer }] });

I've tested this and I believe the type is being inferred automatically, as my type m is not being received from the device on the receiving end of this message.

Looking into the osc-min package which implements the OSC Spec 1.1, it appears that the legacy optional types have not been implemented (see 3.5.3).

I was wondering if there's a way of circumventing this in node-osc?

[elliott-liu]

I saw that @MylesBorins opened an issue in 2021 for a similar feature.

I'd also be willing to implement these features either in node-osc or osc-min, but just wanted to discuss the possibility before going ahead!

[MylesBorins]

FYI this is on my radar but haven't had time to dig in too much yet. I am considering doing a bigger rewrite and removing osc-min, but that isn't going to be a light lift 😓

[elliott-liu]

I'm about 90% through a re-write of osc-min using TypeScript. I'm finalising migrating the existing tests. You can take a look here if you've got time. My thought was to either:

1. Do a PR into osc-min, then add the functionality of the OSC 1.0 spec; or
2. Check if you'd be up for integrating it into node-osc

[elliott-liu]

I wanted to make sure the rewrite worked as expected with existing functionality before adding additional features.

Extending the spec should be relatively simple, and should just be a case of extending the type codes (src/osc-utilities/oscTypeCodes.ts ) along with a few types.

[MylesBorins]

What we need, more-or-less, in node-osc is an implementation of toBuffer and fromBuffer... encoding and decoding an OSC buffer accurately / efficiently.

My preference would be to lose the dependency, in which case we could potentially change the interface a bit and do a semver-major... but I'm not looking to introduce TypeScript and it's toolchain into this repo.

I would be open to switching to a fork of osc-min that you maintain to get the functionality as well, but would want to ensure we keep the level of stability we've historically had.

[russellmcc]

FYI these should be handled by osc-min 2.0.0 which I just published. I'm happy to help if you have any trouble porting to the new version