Supporting Wildcards in OSC Addresses

[freadZdead]

Hi there,

Would you be able to easily support Wildcards in this module?

In fact, this might actually not be the OSC module that needs it, but the Companion app itself;

I am trying to use Latched buttons, but that if I press any, it releases all other buttons first, so basically

/press/bank/1/* 0

so that it releases ALL buttons in one OSC message. At the moment, this does not seem to work.

Cheers, freadZdead

[estilles]

In fact, this might actually not be the OSC module that needs it, but the Companion app itself;

You're right. This module already supports sending these types of messages. It is up to the OSC server receiving these messages to perform the appropriate OSC address pattern matching/dispatching.

I'm transferring this issue to the Companion core repo.

[freadZdead]

Thanks estilles,

Although I don't know if I would call it "Enhancement" to implement a standard ;P :

https://opensoundcontrol.stanford.edu/spec-1_0.html#osc-message-dispatching-and-pattern-matching

On a serious note, thank you and your peers to develop this amazing application!

Cheers,

Freddy

[estilles]

Although I don't know if I would call it "Enhancement" to implement a standard ;P :

Hahaha. Good point! However, I would argue OSC is not so much a standard but more of a specification. And, when implementing a spec one should consider not just the extent of the spec, but also the practicality, usability, ease of implementation, etc.

I'm considering this an enhancement since it would add and OSC feature that is currently not supported.

On a serious note, thank you and your peers to develop this amazing application!

Thanks! I'm relatively new to the team, but I echo your sentiment. The Companion core team has done a fantastic job.

---

Now ... back to your request ... I can see how it could be useful to trigger/latch/unlatch a group of buttons simultaneously. But thinking about it just raised more questions.

• Should we provide for an optional delay between each trigger/latch/unlatch?
• In what order should they be invoked? (The specification doesn't "specify".)
• How much of the pattern matching spec should we implement:
  • the wild card (*) pattern match only on the last segment of the address path (as in your example /press/bank/1/*) or on any segment (e.g. /press/bank/*/1)? Not sure how useful it would be to trigger every first button of every page, for example?
  • the single character (?) pattern math (e.g. /press/bank/1/1?)?
  • the group/range ([...]) pattern match (e.g. /press/bank/1/1[1-5])?
  • the list ({foo,bar}) pattern match (e.g. /press/bank/{20,21}/{1,3,5})?

I figured, if we're going to go through all the trouble to implement one pattern, might as well implement them all. :-)

[freadZdead]

I love the detail :)!

• good point re: the delay between wild carded actions... but I wouldn't expect needing it, as at least you are only one message that is (hopefully) implemented as fast as possible across all affected parties within the companion app... it is actually more critical at the moment, where you would need multiple messages.
• My use case: In my case, I want to use the latched status of a button (the yellow top) to indicate a current status amongst mutually exclusive states - when x is pressed, I want to see that it is latched, but whenever x is pressed, no other button can be latched, because only a single state at a time is valid - think radio buttons.
• Good question re: order. instantaneous ;P. Does the comms between companion and the surface allow for a handling of a set of things as a combined state change?
• I agree - if pattern matching, all would be ace :).

At the moment, I am actually using the internal state release button command, just to avoid all the network traffic - so while this might sit better in another issue, I would also love to see "ALL" in all page and bank inputs, across the board - this would make for a much quicker implementation of functionality when editing. What do you think?

[estilles]

Thanks for all the input @freadZdead. I like this feature request. We'll definitely consider adding it.

[KzBoy]

Does OSC feedback have any support?

Would be nice to be able to have interfaces stay in sync with each other. (Eg a mute/cue showing active on Companion when the equipment activated it)

[Julusian]

/press/bank/1/* 0

One thing to think about here, is that this will also unlatch the button that was just pressed, which doesnt sound like what you are after.

This should be checked, but I suspect that the current osc implementation will also execute the up actions for a button which is triggered like this, which also may not be desirable.

Good question re: order. instantaneous ;P. Does the comms between companion and the surface allow for a handling of a set of things as a combined state change? Well, internally companion has to work through everything in some order. In most cases everything will be done within the same millisecond (or some tiny amount of time), but even then order does matter.

Im not opposed to adding some wildcard support, but I do wonder how useful it will be. Another option to achieve similar things would be to add a new endpoint /press/banks/press 1.1 2.2 1.3 99.4 that allows for pressing multiple buttons by having a variable number of parameters in the packet. I dont know if that is a good idea or endpoint layout, but its an option.

[Julusian]

@KzBoy

The best way to achieve this is to implement a module instead of using the generic osc one. It cant currently be done with the generic osc one, but it probably could be implemented if someone spends the time to figure out how to make it generic enough