-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ossia-max] ossia.parameter @mode attribute doesn't seem to work #504
Comments
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. |
I guess the term 'remotely' is a bit vague: it could mean:
I interpret it as setting it not directly on the [ossia.parameter] or as a direct message via [ossia.device] (if thats even possible). |
I think I agree on this, too |
I agree |
for GET, I agree we shouldn't be able to set them remotely actually, when looking at that from a distance, my impression is that those GET/SET labels are more indicative than prescriptive
not sure this is 400% clear - is it ? |
I had another closer read of the docs:
there is no mention of remote, so it should be that simple:
@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. |
so, should we update the doc to follow the implementation or should we update the implementation to follow the doc ? that is the question... |
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
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. 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
BUT ALSO that
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:
I would say: let's update the doc to follow the implementation. One thing we could then add to
What do you folks think ?
What do you mean, exactly by
? |
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. |
OK, done! Is there anything else that requires keeping the issue open ? |
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] |
what do you think it should be ?
|
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 ?
|
well, I think this should be decided by those that have the practical experience. and understand the implications on the implementation.
I would agree on this. |
I think the definition explains the agreed behaviour:
this is @bltzr writing, and I am not sure why the clause
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? |
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 ? |
we should forbid
the exception is the request by @bltzr - as I understand it its helpful with using it with score. |
Agree with @maybites. |
consider the following patch:
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.
The text was updated successfully, but these errors were encountered: