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

maybites commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

it could mean:

setting the parameter via [ossia.remote]
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- commented 5 years ago

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 commented 5 years ago

I guess the term 'remotely' is a bit vague

I agree

bltzr commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

OK, done! https://github.com/OSSIA/libossia/commit/da048bb2407d7c600336ac958e0d7f239f11946d

Is there anything else that requires keeping the issue open ?

maybites commented 5 years ago

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 commented 5 years ago

what do you think it should be ?

bltzr commented 5 years ago

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 commented 5 years ago

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 commented 3 years ago

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

maybites commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Agree with @maybites.

ossia / libossia

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