Skip to content
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-pd] send a message through [ossia.device] right outlet when a parameter's value changed #505

Open
avilleret opened this issue Jun 17, 2019 · 1 comment

Comments

@avilleret
Copy link
Contributor

commented Jun 17, 2019

Thus we can monitor which parameter is changing even if we don't have an associated [ossia.remote] somewhere.

I think we should register to some parameter (with or without pattern matching) instead of outputing every changes by default.

see http://forum.ossia.io/t/indication-of-parameter-change/154

@maybites

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

I had a quick look at the [pattrstorage] object:

it has the
@notifymode
and
@ouputmode

at the moment the [ossia.device] will notify if a new parameter is added. though I think it would be nice if you could switch this on/off via a @notifymode attribute.

the @outputmode attribute is quite sophisticated:

0 = disabled
1 = output all changes to client objects
2 = output all non-repeated changes to client objects (see changemode)
3 = output all changes to client objects not initiated by a message to the pattrstorage object
4 = output all non-repeated changes to client objects not initiated by a message to the pattrstorage object (see changemode)
5 = output all changes to client objects not initiated by a message to any pattr-system object (pattr, pattrhub, pattrforward, pattrstorage).
6 = output all non-repeated changes to client objects not initiated by a message to any pattr-system object (see changemode)

this only as an inspiration.

being able to choose the output through pattern matching would be cool. but maybe the above solution would already be enough?

some ideas:

  1. would it be an idea to add a dump-outlet for these infos?
  2. could we differentiate the dump-output with messages? i.e.

register {adding / removing parameters}
data {changing parameters}

this way we can use a simple [route] object to differentiate.

obviously: all the above naming are only suggestions, maybe you have better ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.