You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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
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
{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.
The text was updated successfully, but these errors were encountered: