MylesBorins/node-osc

OSC Spec 1.1 `legacy optional types`

Opened this issue · 6 comments

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?

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!

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 😓

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

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.

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.

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