Touch Arc Emulator
(check the comments, I’m posting updates down there)
Touch Arc is a Monome Arc emulator for development purposes. It is very much not intended to be “nice” to use or a competitor to the hardware, so please don’t complain about that aspect (if you want a useable and ergonomic interface that’s a joy to use, buy an Arc).
Touch Arc comprises two parts, a TouchOSC template and a Max patch that works as the middle ware and converts the Arc OSC your app is transmitting into a format the touchosc template can interpret, and vica versa it takes the touchosc template interface input and converts it into fake Arc OSC format that your app can handle.
This way developers can work on proof of concept, sound in the knowledge that once the arc hardware is released their applications will function.
The touchOSC template initially replicates all the in and out points of the Arc 2 (I’ll do an Arc 4 one later if there is a demand).
This means there are two duplicated UI’s for each encoder, these are made up of:
- 64 slider ui elements, which can handle values of 0 – 15 (these are the LED’s)
- 4 momentary buttons, that output every 100ms either -2, -1, +1, +2 (these are the encoder turns).
- 1 momentary button that registers as an encoder press event.
For the LED side of things, due to the limitations in the TouchOSC interface, the LED UI is made up of 4 multisliders each made up of 16 subsliders. We could have used 64 single sliders, but they can’t go narrow enough to get 64 of them in a row, even in landscape mode, this means the LED handling middleware needs to do a fair amount of math converting 0-64 into 0-3 + 0-15 coordinates. For this reason (and mainly due to hitting a brick wall with the range wrapping round at 64, I used Javascript as the main math function handling.
The interaction conversion side of things is a much easier straight translation, so I handled that with just Max. The encoder rotation interface is faked by firing a value every 100ms for as long as one of the valued buttons is pressed in the UI. I could replace these with a slider the more you slide it from the center the faster it fires the +1 or -1 values, but i figured for ease and simplicity this approach worked.
Source code is available on google projects, so you can download it and try it out http://code.google.com/p/touch-arc/source/browse/#svn%2Ftrunk. If you can find bugs or better ways of approaching the problem, I’m very happy to update the code, or please feel free to use SVN and update the code or post other examples directly to the project.
I have spoken to Brian at Monome and he’s very happy for me to make this available, if it makes developers lives a little easier pre launch, hopefully that will be of benefit to everyone.
Update:
I’m working on a native Max UI, to see if that renders better without so many hicups. It could also be used in app patches where you’d like an onscreen representation of the Arc UI. Should be ready for testing very soon.
[...] This post was mentioned on Twitter by Made By Robot, Benjamin Dauer. Benjamin Dauer said: RT @madebyrobot: http://t.co/wP8pGO6 I've released my open source Arc developer emulator in case anyone wants to try out app ideas prior … [...]
Quick update, I’m going to work on a native max UI for the ins/outs as well. Testing this out with “real” apps and I’m finding the TouchOSC Ui gets confused very quickly, especially on actions that update a lot of the LED’s fast, like panning a range.
Only way I can test if it’s touchOSC’s fault is to build a max native UI and see how that handles it.
So for now, don’t be surprised if you get stray full on LED bars that won’t go away.
About your problems, if you are sending a lot of updates to TouchOSC, be sure to bundle the OSC messages. Lots of single messages are bound to be unreliable and some will be dropped. Also there’s not much TouchOSC can do about that, it’s UDP’s nature to not guarantee delivery in exchange for lightning fast reponse. Can’t have it all.
Also: there’s a mass-update format to update all faders in a MultiFader control which is more efficient. Instead of sending “/multifader index value” you can send as many float parameters as the control has faders and they will all be updated.
I do not have Max so excuse my ignorance not actually looking at your code myself.
Good luck and keep up the good work!
rob.
Hey Rob, many thanks for posting. Please don’t take my comments as me disparaging touchosc, I’m a huge fan I just couldn’t work out where the log jam was.
I’m also VERY happy you posted about the mass update with multislider.
All the code that fires the OSC that updates touchosc actually lives in the JS file…
http://code.google.com/p/touch-arc/source/browse/trunk/arcOscTranslator.js
As you can see on arcRingAll(), I’m looping through all the sliders and firing a singular OSC for each one. I’ll update all of the updating functions to use the mass-update.
Do you happen to have an example of how it would work? Sounds very much like the src arc map implementation, where you just do something like…
pattern: /prefix/ring/map n d[32]
desc: set leds of ring n to array d
args:
n = ring number
d[32] = 64 states, 4 bit values, in 32 consecutive bytes
d[0] (0:3) value 0
d[0] (4:7) value 1
d[1] (0:3) value 2
or is it much simpler and just…
/1/arc1led2/2,3,4,7,15,0,0,0
No worries, it’s all good.
Example for the mass update: Let’s say you have a MultiFader with 5 faders you could update it like this:
/1/multifader 1 1 1 1 1
which will set all 5 faders to 1.
So it’s not actually one number with ranges of bytes representing the separate values, but multiple parameters to one OSC message. If the number of parameters matches the number of faders they will all be updated in one go. Hope that’s clear, otherwise let me know. Not enough time right now to look at the code. Will see if I can check it tomorrow.
Also the next update will raise the number of possible faders in a MultiFader control. I am guessing the current limit is the reason you had to split it up into seperate controls.
I guess this is my vote for an arc 4 emulator.