You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
when opening an OSC ui, the user interface is not aware of the current values present on the controller.
i'm thinking about a way how to solve that.
at the moment, i see two possibilities:
a simple sync button which makes the firmware sending its current values
if touchosc or the other tools would have a layout loaded event, we could trigger the sync process automatically
i don't really like the extra-button-thing, but see the problem of the missing event in touchosc. do you have any other ideas how this could be solved?
the unidirectional communication (OSC device to stripinvaders) make the communication simple. What exactly do you mean with "not aware of the current values"? RGB values?
An idea would be a time based "broadcast" from stripinvders, I stripinvaders receive the first OSC paket send out the RGB value... now do not send anything for X OSC pakets, then resend it...
i guess its not a question of the communication, more of how we can trigger the communication, isn't it? :-)
with values i mean the rgb values, but also the delay and maybe with some changes of the ui the current effect mode (thinking about a osc's multitoggle control of)
you're right, with the broadcast we have a third possibility.
in the meantime, i tweeted to the touchosc' developer... maybe there is an event as described.
considering the possibilities, i'd prefer an on request solution since this would save some work for the arduino controller. i don't feel really comfortable with doing a proforma broadcast every now an then which is actually not predictable.
i'll try to implement a first proof of concept by using a sync button to make the controller sending its current values.
while waiting for hexlers reply, i'll get in contact with charlie roberts from control. since his app is open source, he may be interested in such an extension of his product.
Hi, this is not currently built into Control, but it's not hard to add to an interface. All widgets have an output method that can be called. In the development version of Control there's an oninit method for the interface; you would simply tell each widget to output inside of that method. Something like this:
In the master branch (what is currently available in the App Store and the Android Market) you would just add the above oninit method to the last widget in the interface.
thanks for your reply. I guess we would need a "onconnect" function not an oninit. here is a use case to show our need:
ANDROID: press connect - nothing happens because the osc server is not started
OSCSERVER: start
ANDROID: press connect, connected to OSC server. now the onconnect function gets called. we update our OSC client with the current server values.
Hmmm... not sure how this is different than just setting the values via the standard methodology. Wouldn't you just do something like this?
Android - press connect
Server - start
Server - for each widget, set the appropriate value in the remote interface via standard /widgetOSCAddress newValue calls.
If that's not flexible enough, Control lets you define your own custom OSC namespace so that you can process any OSC command with scripting calls. You can see an example here:
Activity
neophob commentedon Mar 22, 2012
the unidirectional communication (OSC device to stripinvaders) make the communication simple. What exactly do you mean with "not aware of the current values"? RGB values?
An idea would be a time based "broadcast" from stripinvders, I stripinvaders receive the first OSC paket send out the RGB value... now do not send anything for X OSC pakets, then resend it...
swissmanu commentedon Mar 22, 2012
i guess its not a question of the communication, more of how we can trigger the communication, isn't it? :-)
with values i mean the rgb values, but also the delay and maybe with some changes of the ui the current effect mode (thinking about a osc's multitoggle control of)
you're right, with the broadcast we have a third possibility.
in the meantime, i tweeted to the touchosc' developer... maybe there is an event as described.
neophob commentedon Mar 22, 2012
btw: a touchosc solution only is not the best idea, there are other clients around.
anyway, stripinvaders need to send a osc message to the osc client.. and you need to send an update for each new client (_oscAddress)
swissmanu commentedon Mar 23, 2012
considering the possibilities, i'd prefer an on request solution since this would save some work for the arduino controller. i don't feel really comfortable with doing a proforma broadcast every now an then which is actually not predictable.
i'll try to implement a first proof of concept by using a sync button to make the controller sending its current values.
while waiting for hexlers reply, i'll get in contact with charlie roberts from control. since his app is open source, he may be interested in such an extension of his product.
neophob commentedon Mar 23, 2012
ok thanks. so i'll wait on your feedback.
charlieroberts commentedon Mar 25, 2012
Hi, this is not currently built into Control, but it's not hard to add to an interface. All widgets have an output method that can be called. In the development version of Control there's an oninit method for the interface; you would simply tell each widget to output inside of that method. Something like this:
In the master branch (what is currently available in the App Store and the Android Market) you would just add the above oninit method to the last widget in the interface.
Hope this helps. - Charlie
neophob commentedon Mar 26, 2012
hey charlie
thanks for your reply. I guess we would need a "onconnect" function not an oninit. here is a use case to show our need:
ANDROID: press connect - nothing happens because the osc server is not started
OSCSERVER: start
ANDROID: press connect, connected to OSC server. now the onconnect function gets called. we update our OSC client with the current server values.
cheers
michu
charlieroberts commentedon Mar 26, 2012
Hmmm... not sure how this is different than just setting the values via the standard methodology. Wouldn't you just do something like this?
/widgetOSCAddress newValuecalls.If that's not flexible enough, Control lets you define your own custom OSC namespace so that you can process any OSC command with scripting calls. You can see an example here:
http://charlie-roberts.com/Control/?page_id=136
Let me know if I'm misunderstanding something. - Charlie