Arc alternatives?

  • I was looking at apps like grainstorm and wondering if these could be accessed without an arc or if they will only be usable for those with an arc? For example, could I use my MPK-61 which has 8 endless encoders, or my iPad, with lemur or TouchOSC and a simple template, and still be able to use something like grainstorm or tml. I am currently using both an APC20 and my iPad as a monome while I await a possible arduinome purchase and build (as well as a hopefully soon chronome group buy). It would be really nice to be able to use any encoder based controller (including the open source midi encoder controller I just ordered from bjorn/st8) to act as an arc, even if it won't have the same resolution. If this isn't doable now, could it be implemented in the current apps through relatively simple changes, or would the apps have to be completely rewritten with an open midi/osc platform in mind? Thoughts?

  • Start here and read the rest of the thread:
    http://post.monome.org/comments.php?DiscussionID=11551&page=3#Item_28

    Short version: it's doable, but you'd have to do it.

  • arc kits in the future possibly? ;)

  • @shimoda:

    i reckon someone could quite readily alter the firmware of the eight controller to speak monome osc protocol.

    that person ain't me though...

  • Okay, so looking at the basic input model of the arc on serialosc, which I assume would have to somehow be routed, how is the encoder amount determined that is sent?

    /enc/delta n d -> this is what is listed in the protocol. n is the encoder (0-3) and d(signed) is the amount sent. How much, say, does d represent for a 1/4 turn. or a full turn of the arc? This would be important to know even for building an arc clone.

  • the arc uses rotary encoders which output something like gray code at a very high resolution, which are then converted into a + or - int value which is also dependent on the speed of the turn.

    so basically, it's all relative. there isn't a value for a 1/4 turn per se.

    i do know the encoders in the 8 board are of a way lower resolution though.

    in fact, (correct me if i'm wrong) i don't think there is an app that makes full use of the resolution of the arc as of yet...

    ie i think most of the apps already out there would work perfectly well and be very usable with a simple midi knob instead of an arc knob...

  • So I thought I had seen somewhere the firmware for the arc. It wouldn't be of much use to me since I don't understand hex, but it might be a place to start. I believe I've read that the Bourns encoders with 24 point.... are able to achieve that level of precision from reading the gray code on before/during/after, so it seems as though the firmware is pretty darn important for reading with the resolution the arc achieves. Certainly that should be able to be mimicked via an iPad app (I would think, but I might be thinking above my pay grade here). I'm sure the encoders for the 8enc controller might be programmable for more resolution. Even at lower resolution (more turns needed) it'd be nice to have them adapt someway to mimic, roughly, an arc.

    On a side note, I'd imagine those encoders 'screens' (the black led wheels) could be laser cut through ponoko or sorts. But sticking to this thread and not the other clone thread, I am wondering how difficult it would be to link a lemur or touchosc template to serialosc.

  • hex is just the compiled firmware for the device. you'd have to start from the osc protocol and work backwards.

    actually though, i don't really know what i'm talking about :)

  • more info here: http://post.monome.org/comments.php?DiscussionID=11087&page=1

    arc encoders are 64 ppr, eight encoders are 24 ppr.

  • The level of precision is irrelevant, the apps don't use the relative position of the encoder, just how many "ticks" have occured in each direction. So it wouldn't matter if to get 10 ticks took 1/4 turn or a 1/2 turn, apps just care that they had 10 ticks in one direction.

    I worked on a touchosc, max and even web based implementation before the arc hardware was released so devs could work ahead of the release.

    More info:

    TouchOSC Emulator:
    http://post.monome.org/comments.php?DiscussionID=10619
    http://nomeist.com/touch-arc-emulator/284

    Max Emulator:
    http://nomeist.com/max-arc-emulator/298

    Web based Arc OSC visualizer:
    http://nomeist.com/osc/arc/
    http://post.monome.org/comments.php?DiscussionID=11614

    To be honest I found the emulators to be utterly useless compared to grabbing a arc encoder and spinning it, so I didn't progress further with any of this as soon as I got my arc. But it might give you a starting point for your ideas.

  • It could still prove to be useful as making an actual encoder would be nice. Frankly, even without the nice resolution of the arc, using the encoders on my MPK-61 if they could somehow be mapped (perhaps through remote script changes) would provide some level of physical access to using an app like grainstorm

  • It would be very easy to map any encoders that connect to your computer (midi, arduino, etc) to Arc is you code a max patch to act as the middleware to convert whatever they are talking into whatever serial io is expecting. The communication in really is very simple, it's clicks going forward or backwards, usually just 1's, I think the largest I got out of the Arc for one tick was about 8 or 9.

    The tricker bit is the communication back to the LED's, but i have examples in all the mac patches that are linked to on google.

    To be honest, I wouldn't bother though. You'd be better off taking the arc apps you like and tweaking them so they work with whatever interface you have in a way that's logical for that interface. I couldn't find any interface to emulate an arc that I'd want to use for more than just developing and debugging.

  • If you want to know how to build your own open source arc. You probably want to read this thread http://post.monome.org/comments.php?DiscussionID=11264&page=1

  • @jp,

    I've noticed a few places where you've stated clearly that you only did this as a pre-release dev thing. I am not able, for some reason, to get either the touchosc.maxpat or the maxarc.maxpat to run in max for testing. I'd like to look at the module, but can't as I can't get it to open. I just get this:

    error parsing patcher file touchArc.maxpat
    parsing object, possible missing initial '{' character: line=5, char=2, text='...

  • which version are you running?

    I just copied the source out of the "view raw" view and pasted it into a blank patch in 5.1.8 and it worked 1st time.

  • I was running max 6, I'll have to try max 5 when I get home. I've been following the arcduino thread. Tehn had mentioned in an article posting the schematics. That would be quite helpful to see how the led rings are being handled.

  • You can see a high level view of how they work from this picture

    http://monome.org/here/arc-parts.jpg

  • Really like to know what chips are on both sides of those pcbs. Seems strange to have pins from all going to each if those are 5940s, which I would think they must be in that family to have the pwm intensity control.

  • Well, tried with max 5.1.9, just can't get it, but it also otherwise tries runtime. Will look at your js file at any rate.

  • are you using the run time? or full editor max? You need the editor version.

  • I tried the full version in demo mode. I have m4l, but the 30 day period on max 5 has run out. :(