Skip to content

OSCMethod: Disallow wildcard dispatching #13

@sammysmallman

Description

@sammysmallman

Counter to "A received OSC Message must be dispatched to every OSC method in the current OSC Address Space whose OSC Address matches the OSC Message’s OSC Address Pattern." There are occasions when an address space has been set up with addresses that are mutually exclusive or a developer does not want to provide such a wide level of control over a large set of parameters configurable via OSC. Arguably the mutually exclusivity issues arising are due to a poor address space design. Never the less, it is noted that application developers prefer to use the address space to explicitly state actions...

Example 1:

An Address Space:

  • /record/start
  • /record/stop

Receiving the address pattern /record/* or /record/{start,stop} would invoke both methods with a unknown order and leave the application in an unknown state. Is it recording or not?

Example 2

  • /cue/1/fire
  • /cue/2/fire
  • /cue/3/fire

Receiving the address pattern /cue/*/fire,/cue/{1,2,3}/fire or /cue/?/fire would invoke both methods with a unknown order and leave the application in an unknown state. What cue is playing back?

Example 3

  • /settings/1, arguments: T, F or {number}
  • /settings/2, arguments: T, F or {number}
  • /settings/3, arguments: T, F or {number}

{number} is interpreted as a boolean; 0 equals false, any other number equals true. If no number is given return state.

Receiving the address pattern /settings/*,/settings/? or /settings/{1,2,3} would invoke all methods.
In this example it would be nice to invoke all three method that would return state from all 3 settings from a single address pattern.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions