Best practices for bool/toggle values

[bltzr]

all to my survey of OSCQuery implementations, I have noticed several ways to implement boolean/toggle values/parameters: 1/ in VDMX and Mitti, those are declared as int values, with a range of [0 1], which allows them to be detected by OSCQuery Browser as toggles (and get the corresponding UI widget) 2/ in ossia, they are declared as T or F (based on their current value), which are argument-less types. This is somehow closer to the targeted type, even though I find it quite strange that an address changes its type dynamically when changing values. Also this shows up with buttons in OSCQuery Browser, which is not very useful. 3/ in MadMapper, they are declared as "b" (with VALUE being "true" or "false"), which is, I guess a confusion on the TYPE TAG ("b" are for blobs), right @mattbeghin ?

Shouldn't we choose something for this, and make recommandations in the specs ?

Personally I would vote for following the most common convention yet (aka 1/) which also seems the most sensible IMHO. What do you think, guys ?

[dlublin]

I mentioned item 3/ to Matt a little while ago over email and at the time he agreed that 1/ was probably the best route to go.

[jcelerier]

even though I find it quite strange that an address changes its type dynamically when changing values

well, thank the osc spec for this ;p

and get the corresponding UI widget

that's a fairly important part, I'm opening another issue to have a more general reflection about this.

[bltzr]

well, thank the osc spec for this ;p

sure, that sucks!

but... since it's probably late to change this, shouldn't we adopt this de facto convention (storing bools as integers (which is actually what most programming languages seem to do, right ?) as part of the specs ?

That might prevent other future discrepancies across implementations like those I mentioned, wouldn't it ?

[jcelerier]

but... since it's probably late to change this, shouldn't we adopt this de facto convention (storing bools as integers (which is actually what most programming languages seem to do, right ?) as part of the specs ?

well, that could maybe be a guideline, but I don't think that the protocol should remove support for bool since there are certainly a loooot of OSC apps out there that uses them. I don't know of a programming language that don't have a proper boolean type except C89.

[bltzr]

yup, we could give this (bool as int) as the recommended guideline, and also recommend trying to support using T and F type tags

On Tue, Aug 7, 2018 at 5:14 PM Jean-Michaël Celerier < notifications@github.com> wrote:

but... since it's probably late to change this, shouldn't we adopt this de facto convention (storing bools as integers (which is actually what most programming languages seem to do, right ?) as part of the specs ?

well, that could maybe be a guideline, but I don't think that the protocol should remove support for bool since there are certainly a loooot of OSC apps out there that uses them

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Vidvox/OSCQueryProposal/issues/48#issuecomment-411092920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG9PmEpLuPgW1VGQ2SbHQsClD6N8AZDks5uOa7ogaJpZM4VyQs6 .

[mrRay]

i'm closing this issue because i think (i hope!) all the concerns here have been addressed. if i'm mistaken or there's something else to add, please feel free to re-open this issue or create another one!

[mattbeghin]

in MadMapper, they are declared as "b" (with VALUE being "true" or "false"), which is, I guess a confusion on the TYPE TAG ("b" are for blobs)

Yes that was a mistake. It has been solved like in VDMX/Mitti (integer range 0-1) in MadMapper 3.5.0