Support for sending multiple parameters via OSC

[IcedQuinn]

Hello! I am writing from an issue in another project which has OSC adapters. This project supports OSC endpoints however it uses bundles to send the parameters. So rather than something like /foo/volume you have to send /foo with a string and integer parameter. I'm already in talks with the other project to perhaps have a more traditional OSC interface added. But came over here to open a discussion about supporting bundled parameters as well.

[jcelerier]

hi!
yes actually it's not the only software which has this kind of OSC API... I have a long-term plan of enabling custom scripting for OSC devices to define exactly how the address that shows up within ossia is mapped to the outside parameter, kepping you posted

[IcedQuinn]

actually it's not the only software which has this kind of OSC API

i have taken to calling it "RPC style" because it reflects how remote procedure calls and HTTP work more than traditional OSC. maybe it would be more appropriate to call it REST? not sure. would love to know if there is a proper name for this.

I have a long-term plan of enabling custom scripting for OSC devices to define exactly how the address that shows up within ossia is mapped to the outside parameter,

i might be around to brainstorm some interfaces. what other software is doing this? i might go take a look.

[IcedQuinn]

Hello, Just waking this up to note that I'm still tracking the issue.

[jcelerier]

hello! yes, sorry, not forgetting this - there's just a lot of small bugfixes to come before

[IcedQuinn]

hello! it looks like there is still no way (outside of writing a fully custom device?) to interact with software that has multiple parameters? ex. /scene/item/move int int

[jcelerier]

I've made progress on this recently through the implementation of Bitfocus companion modules.
While doing it, it seems that the most meaningful way to do this would be to have a way to specify that a parent node's children are actually parameters.

e.g. given

/scene/item/move
/scene/item/move/index 1
/scene/item/move/position 3.5

then sending an impulse to /scene/item/move would send /scene/item/move 1 3.5

One thing that is not too clear to me:

• For some addresses you'd want any change to any parameter to trigger an OSC message.
  e.g. most likely if you have an automation on /scene/item/move/position we want this to send messages every time

• For some other addresses you really want all the parameters to be set before sending the message, e.g. something like

/filesystem/copy_file <from> <to>

you want both from and to to be set before sending the message.

Maybe there could be thus two attributes on nodes:

• One to say: "children of this node are the parameters of this OSC message"
• One to say: "changing this value will trigger a network message"

What do you think ?