Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Sync OSC UI Controls #2

Open
swissmanu opened this Issue Mar 22, 2012 · 8 comments

Comments

Projects
None yet
3 participants
Contributor

swissmanu commented Mar 22, 2012

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?

cheers,
manu

Owner

neophob commented 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...

Contributor

swissmanu commented 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.

Owner

neophob commented 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)

Contributor

swissmanu commented 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.

Owner

neophob commented Mar 23, 2012

ok thanks. so i'll wait on your feedback.

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:

"oninit" : function() { 
    for(var i = 0; i < Control.widgets.length; i++) {
        var w = Control.widgets[i];
        w.output();
    }
}

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

Owner

neophob commented 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

Hmmm... not sure how this is different than just setting the values via the standard methodology. Wouldn't you just do something like this?

  1. Android - press connect
  2. Server - start
  3. 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:

http://charlie-roberts.com/Control/?page_id=136

Let me know if I'm misunderstanding something. - Charlie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment