[ossia-max] ossia.parameter @mode attribute doesn't seem to work

[maybites]

consider the following patch:

----------begin_max5_patcher----------
1087.3ocyXkzqaaCD9r8uBBc10gjZOmZQQPAJZOkbonHvfVhVlOHIJPQk9dI
H+2K2jWdwK5YK41KRTbaluuY3LC02lOyaM+YZqG38f+FLa12lOaloKcGybeO
yqh7bVIo0LMuJZaKof5svNlj9rz1OOmBZox9Ap6pX0kToYUXWmrbyb4qe5mB
NXh7NY+LQtdscIeogZUNOOvmcC0PjYaY0EqDzLocTLBuDt.fhizuBSzOwpt.
eVujuOet9whw.gECGg9SABCBLHLcRPnj1JADPIS8RtkHAsa4ck4f0T.qnlKn
4.dM329vmFJEfFSJvOFoQsOx2.dezjvAesLqjRDCFgnz9otgWKaYe0fEiNdi
PWuO0jJy.d+hfQJ8NOojXHCTngLBrN992HkrtSJ40mD4neD4X3d0RnTWIUrh
VSVWZT72H5WSpKtnwGEYNZivPCDC5edS.sl9OJDbBS+xBAuqYv19vS6diOqM
dw0bwMFPTpAjg2mC9Y.oBfRJfzzPqyAm2U2+Dv8Lgr8uHbGHjQwlWvIJvlRo
ZGrY0++zSzQnkg8F+.7C7.c7i77ryr6Ocml2vKyoBvuFG792UQyYj2U01bnk
cCI60P6h7S3axs3hAAX0xaz6vxaIN1K8tbOdXkADNE0Afgtx77mhvj71VFYo
fVwUQKqdYklL5mTFujKr5BbIBGFjtP0HNMBFmnakjFfPpVHsJMzronII3pip
BsQWQI++nrwRVMMi2UKOze4pWX.OpNQ3kwpvr9NuGnInqe3T3DsKbZueD3m0
ZIXpco7SllxS58lRuu5SHRoni0qh5u1cKqglwJZBtgkKrBJDdRzY1AiC7qt0
rYG08eLja4chrd46xxB1aCyUGcX0DISkld+bBOZNbgJOlAWmjkGSAqK84TRF
dWRNZ.RV6rBNmizPEjNOyUkDFMFRRsGnqIH3HInqZ0BFAAE7nLR8axEkjNX+
ADbEKugqJZxclKHVGsFm5x7GXBka97d0sGEIfGhm5X3n16DdYAENBRBE9nHO
TvCCSAC3bt4W.c+hxe3IFtOA0qtuU5yl5izz7Epn0MaiTT40exV8RxBymrZ6
mlaF4Ineg0O+HSODgJ4qTk4sSXu0yyQ1+sfI6unVUVfMcmBeJQ1Jeo70oa2e
gotbF+iRhrqc0eRq6rkDnP0FRWo7XtXcwFVY4tZslsajYd8UI3pDagq6ipKC
6JBCtzG4GiiLsTMBCOvIwsFT+hBT0xAw5oFDgiCBMsRv9g95VvWsL7dYAQoV
I.SSfA1VptPGUDnhKqKr2PGGC6uJpxYPva3hdapZoo6lemjWHH4Lps7aSpcq
I1R21e.fZTCsa3DGmVoHTV+ZNz0amw32IU7JxpsrBkmXwVIMeEWnzP5krJjr
LkzNfoM0UBWZnJnCtih58wO8W+wGbWz512kmLmznBH7ssU1yOlBf06Uai6+O
XpSd92m+uE013gA
-----------end_max5_patcher-----------

when pressing the bang, the list parameter is populated.

then change mode to GET.

according to the documentation, now it shouldn't be possible to set the value remotely (in this case via ossia.remote), but it obviously is.

...unless I misunderstand the docs.

[avilleret]

hum... actually you can't set a parameter with mode "GET" remotely i.e. from another software or patcher connected to yours with some protocol (OSCQuery for example)

we can also forbid to control those parameter from within a patcher, like you do in the test patcher you posted.
but I'm wondering if everybody agree (I do btw)
what @bltzr @jln- @jcelerier and co. think about it ?

[maybites]

I guess the term 'remotely' is a bit vague:

it could mean:

1. setting the parameter via [ossia.remote]
2. or/and setting the parameter via OSCQuery or Minuit or OSC.

I interpret it as setting it not directly on the [ossia.parameter] or as a direct message via [ossia.device] (if thats even possible).

[jln-]

hum... actually you can't set a parameter with mode "GET" remotely i.e. from another software or patcher connected to yours with some protocol (OSCQuery for example)

we can also forbid to control those parameter from within a patcher, like you do in the test patcher you posted.
but I'm wondering if everybody agree (I do btw)
what @bltzr @jln- @jcelerier and co. think about it ?

I think I agree on this, too

[avilleret]

I guess the term 'remotely' is a bit vague

I agree

[bltzr]

hum... actually you can't set a parameter with mode "GET" remotely i.e. from another software or patcher connected to yours with some protocol (OSCQuery for example)

we can also forbid to control those parameter from within a patcher, like you do in the test patcher you posted.
but I'm wondering if everybody agree (I do btw)
what @bltzr @jln- @jcelerier and co. think about it ?

for GET, I agree we shouldn't be able to set them remotely
for SET, there were cases when it was useful to retrieve them remotely

actually, when looking at that from a distance, my impression is that those GET/SET labels are more indicative than prescriptive
also, the one actual case where the SET label was useful (re: discussion on gitter team chat) was to discriminate between "normal" parameters and meta-control - i.e. some message (in Jamoma parlance) controlling a bunch of parameters, like a macro, somehow...) in order not to include them in cues/states in a systematic way
-> this is what score currently does:

• if a tree of nodes is dropped into the editor, only BI/RW parameters are queried and store in the create/updated state
• to include SET messages, they need to be explicitly dropped to be included

not sure this is 400% clear - is it ?

[maybites]

I had another closer read of the docs:

Defines the way the value of ossia.parameter will be accessible : when set at GET, the value can only be retrieved, when at SET, it can only be set, not retrieved, and when at BI, it can be both set and retrieved.

there is no mention of remote, so it should be that simple:

• you always can set and get the parameter directly at the [ossia.parameter] object (or via its parent objects, i.e. load/save presets).

• on GET:
  you can only get the parameter from wherever

• on SET:
  you can only set the parameter from wherever

not sure this is 400% clear - is it ?

@bltzr I am afraid it is 400% unclear and looks as if the attribute was misused from its intended purpose. though I can't see an objection to the way score treats the SET messages. since this is not violating the docs - as long as it is unable to show the value of the parameter, that is.

but this all is the opinion of an outsider that tries to make sense to the way ossia is intended to work. it is complicated enough and this is highly confusing.

[avilleret]

so, should we update the doc to follow the implementation or should we update the implementation to follow the doc ? that is the question...

[bltzr]

I am afraid it is 400% unclear and looks as if the attribute was misused from its intended purpose.

OK, I guess we need to have a little storytime now:

Way way back in the good ol' days of Jamoma (on the specs of which ossia is almost completely based), we didn't have a @mode attribute, but instead had 3 separate objects: j.parameter, j.message and j.return
Those would resp. embody:

• a permanent value of one parameter of the system for j.parameter, hence settable and gettable
• a "volatile", stateless message, to be sent to a system without any kind of guaranty that the sent value to j.message would correspond to anything real after emission - hence mainly settable (more on that later)
• an "output" value from the system for j.return without any guaranty of permanence - think mouse position, e.g. - this was hence only gettable

When we did the specs of ossia-max (and libossia, more generally) based on those specs, we tried to make things more generic and straightforward, hence we thought it was probably better to just have one object (ossia.parameter) instead of 3, with one attribute to discriminate between the 3 behaviors.
We could have chosen parameter, message and return for possible values for @mode but we thought (maybe mistakenly) that GET, SET and BI (or, alternatively, R, W and RW) would be simpler.

The thing is that, down the road of actually using Jamoma in real-world projects, we found that it was sometimes useful to be able to retrieve the last value received by j.message.
To illustrate, this, here's one example that I have been confronted too personally (several times):
On a setup with a large number of parameters (an array of 32 intensities, in my case), which I declared with as many individual ossia.parameter objects. Thing is, when wanting to play with all those intensities in a gestural/intuitive way, it was more expressive to design (in Max, i.e. remotely) a higher-level algorithm to control those 32 j/ossia.parameters with just a few j.messages/ossia.parameter @mode set (pan, spread and intensity, in my case).
Then, when using score (or any other cue system, for that matter, since I had the similar use case when using j.cueManager) it was nice that:

• one be able to record the values remotely, even though they were theoretically "write-only", both
  • in cues for individual values, by just drag'n'dropping the node(s) to the editor
  • as automations, in a continuous way, when performing e.g. one's algorithm's dedicated UI

BUT ALSO that

• one also be able to avoid having both the messages and the parameters automatically stored (which would cause conflicts in all cases when messages are not used) when making some cue/state at a "higher-level", of which both the messages and the parameters would be more or less distant children.

So, that's the reason. Is that any clearer ?

And I find it important that we keep this feature, because it's not only crucial to me, but was also to others, for similar reasons (though sometimes in different use cases), so I guess it's not completely lacking sense and necessity.

Now, I reckon that things are not as clear as could be in the way they are currently documented, but maybe then, faced with @avilleret 's question:

so, should we update the doc to follow the implementation or should we update the implementation to follow the doc ? that is the question...

I would say: let's update the doc to follow the implementation.

One thing we could then add to @mode set's doc is maybe, e.g.:

Defines the way the value of ossia.parameter will be accessible : when set at GET, the value can only be retrieved, when at SET, it can only be set, and when at BI, it can be both set and retrieved.
However, when `@mode` is set as SET, it is possible to retrieve the last value it has received, without any guarantee this will reflect the system's current/actual state.

What do you folks think ?

though I can't see an objection to the way score treats the SET messages. since this is not violating the docs - as long as it is unable to show the value of the parameter, that is.

What do you mean, exactly by

as long as it is unable to show the value of the parameter, that is.

?

[maybites]

One thing we could then add to @mode set's doc is maybe, e.g.:

Defines the way the value of ossia.parameter will be accessible : when set at GET, the value can only be retrieved, when at SET, it can only be set, and when at BI, it can be both set and retrieved.
However, when `@mode` is set as SET, it is possible to retrieve the last value it has received, without any guarantee this will reflect the system's current/actual state.

What do you folks think ?

I guess you just showed how ideals and the realworld can clash and how hard it is to create tools that can deal with all circumstances. I am all for it, since this has merits based on realworld experience, and I think the docs would be clear.

[bltzr]

OK, done!
da048bb

Is there anything else that requires keeping the issue open ?

[maybites]

the topic of 'remoteness' is not resolved.

does it apply only to remote apps that communicate via protocols like OSC, OSCQuery or Minuit.

or

does it also apply to 'local' instances like [ossia.view] rsp. [ossia.remote]

[bltzr]

what do you think it should be ?

[bltzr]

I’m not 100% sure, but my gut feeling is that it shouldn’t be different, since a [ossia.remote] can be under an [ossia.client], which would then communicate through OSCquery to the remote [ossia.parameter] as if it were in the same patcher. So I would say it applies to both and that there’s no functional differences to both But I might be overlooking some aspects, I don’t know opinions, @avilleret @jcelerier ?

[maybites]

well, I think this should be decided by those that have the practical experience. and understand the implications on the implementation.

So I would say it applies to both and that there’s no functional differences to both

I would agree on this.

[avilleret]

could someone sum up this issue and tell me what I have to do ? @bltzr @maybites

[maybites]

I think the definition explains the agreed behaviour:

Defines the way the value of ossia.parameter will be accessible : 
when set at GET, the value can only be retrieved, 
when at SET, it can only be set, and 
when at BI, it can be both set and retrieved.

However, when `@mode` is set as SET, it is possible to 
retrieve the last value it has received, without any guarantee 
this will reflect the system's current/actual state.

this is @bltzr writing, and I am not sure why the clause

without any guarantee this will reflect the system's current/actual state

is important.

this applies for remote applications connected via OSCQuery (or Minuit) AND the [ossia.remote] object.

@bltzr does this sum it up for you, too?

[avilleret]

so if I understood correctly we should forbid to modify a parameter's value with mode 'get' from ossia.remote and getting a parameter's value with mode 'set' from ossia.remote

is that right ? should I implement this behaviour ?

[maybites]

we should forbid

• to modify a parameter's value with mode 'get' from ossia.remote
• to receive a parameter's value with mode 'set' from ossia.remote, except on creation time of ossia.remote.

the exception is the request by @bltzr - as I understand it its helpful with using it with score.

[evanmtp]

Agree with @maybites.