when publishing in OSC Query, UNIT and CLIPMODE fields should hold an array, not single values

[bltzr]

as defined in the specs @ https://github.com/Vidvox/OSCQueryProposal/blame/master/README.md#L93

UNIT If provided, the value stored with this string is always an array- this array contains one string per value returned (or expected) by this OSC method (this attribute is supposed to describe the unit of the expected values, so there needs to be one unit per value)

(also implicitly mentioned in https://github.com/Vidvox/OSCQueryProposal/blame/master/README.md#L77 )

This is how we're doing it:

"UNIT" : "position.cart2D"

And this is how @mrRay does it:

"UNIT" : [
            "RGBA"
          ]

So, one of both has to be wrong - I'm afraid it's us

[jcelerier]

hmmm, for me, the unit field is for the whole object, like the description field. Else it would mean that for instance, if you have a ossia.parameter of type list in max, you would have to set one unit per value - I'm pretty sure that this is not what you want. Consider for instance a ossia.parameter @type list @unit pos.cart3D. The osc type of this parameter is fff. But there's a single unit.

[bltzr]

well, what I want is one thing, and what is agreed upon collectively in protocol specifications is another thing

so, concerning multi-dimensional units, this had already been addressed from there on: https://github.com/Vidvox/OSCQueryProposal/issues/14#issuecomment-62827040 I'm not sure a conclusion was reached... but decisions were taken, and those include having arrays for UNIT (and also for CLIPMODE, see https://github.com/Vidvox/OSCQueryProposal/blame/master/README.md#L111 -> so I'm updating this issue's title)

Anyway Ray made a point that those are more datatypes than units, strictly speaking.

So, if we follow his (valid, IMHO) reasoning), for instance, for an aed parameter, UNITs would be radian, meters and meters for each of the VALUEs.

So, now about your example in Max, a couple of comments:

• we discussed tuples a while ago (https://github.com/OSSIA/libossia/issues/403), that would be different from curent lists in that they would have different types for each member, and hence different units for each of them
• anyway, even for simple lists, this could be the case (even though that would pose other problems, such as UI design for that, that we won't have the time to get into until a long time, if ever)
• somehow, position.aed could be broken down into

  "UNIT": [
            position.aed.a.radian,
            position.aed.y.meters,
            position.aed.z.meters,
            ]

  if we wanted to get this straight.

I'm also wondering if, somehow, our multidimensional "units" are not more like "extended types" than proper units, even though I guess that would be a huge shitload of work to refactor all this !

So, for now, what we could do, in order to just be compliant with OSCQuery specs, would be to repeat the UNIT for each VALUE, (also with CLIPMODE) and put the whole thing into square brackets. And then, later, we'll see what we do with the rest...

What do you think ?

[jcelerier]

Well, the discussion there was not finished, maybe it should move here ? https://github.com/Vidvox/OSCQueryProposal/issues/38

In any case, this was there in the beginning for the Jamoma compatibility of ossia. If we move towards what you propose (or anything else), that will certainly be lost. Is it a problem ? Can we git rm minuit.{hpp,cpp} ? :p

In any case, libossia is not able to have addresses with objects that have more than one unit - and that would be a fairly big change (and maybe a small performance hit since units would have to be dynamically allocated too).

[bltzr]

yep, maybe, thanks for pointing towards this!

[jcelerier]

we discussed tuples a while ago (#403), that would be different from curent lists in that they would have different types for each member, and hence different units for each of them

I don't remember tuples ever being about this. Tuples are exactly like other parameters but it's not possible to, say, push a list of 5 elements and then another list of 7 elements.

[jcelerier]

(it's already perfectly possible for lists today to have diffreent types, e.g. [1, "foo", 'c', [2, 3, "blah"]])

[bltzr]

I don't remember tuples ever being about this.

no, sure, that's just my interpretation of what it could (mis-)used for... :-)

[bltzr]

If we move towards what you propose (or anything else), that will certainly be lost. Is it a problem ? Can we git rm minuit.{hpp,cpp} ? :p

Well, sometimes, you have to let go with old stuff ! I could always use v1 for going on using my good ol' Jamoma patchers...

[bltzr]

In any case, libossia is not able to have addresses with objects that have more than one unit - and that would be a fairly big change (and maybe a small performance hit since units would have to be dynamically allocated too).

At least, for now, what I'm asking for is that we comply with the OSCQuery specs. As I said above:

So, for now, what we could do, in order to just be compliant with OSCQuery specs, would be to repeat the UNIT for each VALUE, (also with CLIPMODE) and put the whole thing into square brackets. And then, later, we'll see what we do with the rest...

[bltzr]

(it's already perfectly possible for lists today to have diffreent types, e.g. [1, "foo", 'c', [2, 3, "blah"]])

yeah, but it's not really possible to define specific ranges and other attributes for each in score, yet

[bltzr]

In any case, libossia is not able to have addresses with objects that have more than one unit - and that would be a fairly big change (and maybe a small performance hit since units would have to be dynamically allocated too).

Depending on the outcome of the discussions on the OSCQuery repo, I'm not sure we need to refactor the whole internals of libossia, we could just change the way are published/parsed to/from OSCQuery JSON from.

In any case, and without consideration about actual implementation, I think that the specifications of OSCQuery are actually better thought out than those of Jamoma. Actually, apart from the unit/multi-dimensional type debate, I find that the set of OSCQuery fields that require arrays (ie. one attribute per value) are quite right. Our mistake (which was basically just following Jamoma's unperfect specification/implementation on that) was to attach some attributes to the node while they have been to the value. Among those are obviously unit and bounding_mode, and also stepSize. I reviewed them all, and I don't see others. If I understand well the implementation, the trick that we have is that, when this attribute can be passed as a value (including a list, which is a std::vector) then it's easy to have it attached to a value, but for other kinds of "types" (string for units, enum for bounding_mode) I guess it's more complicated. (For stepSize, I guess it wouldn't be too hard to change that to use a value instead of a double... that would even be more consistent, but that's not the most important attribute). Did I get this right ?

Well, I'm not sure we have to act on that right now (maybe not our topmost priority), but at least we should try to make sure we're OSCQuery-compliant (when the debates will be settled there) for now.

[jcelerier]

so, since the following text was added to the spec:

If all of the elements of one of these optional attribute share the same value, it's acceptable to only list a single value (which clients will assume corresponds to all of the elements) for the sake of brevity.

I guess that we can close it for now ? since clipmode / unit / etc are currently the same for all values

[bltzr]

that would be something to think about for a v2 or something, but yeah, since Ray changed that, that's perfectly fine the way it is should we close or apply a v2 label or something ? (or both ?)

[jcelerier]

let's close it and open another issue to think about the general redesign needed for this.