Cycling74 mobile app: MIRA

  • Looking forward to this. Might be useful for some video work. Certainly for sounds... Ad a big MAX (and iPad) user, I will definitely dig into it.

  • Came out today, anyone grab it yet?


    I'm assuming at this point that it works w/ M4L but I'm not 100% sure.

  • now i regret spending the same amount of money on the lemur app... shit i want this.

  • gee that looks pretty swish!

  • yeah i want it bad. maybe after my shows in san jose and sf next week i'll get it :)

  • no doubt that's stretta's hand ;)

  • Totally bought.

    Effing amazing...

    Definitely making Mira version of the party van...
    Also using it for my dynamic display/score system.

    Latency is VERY small when using adhock network. Also super fast to set up. WORLDS fucking better than touchosc.

    I hope they make an iphone version too.

  • funny rodrigo, my first thought was "oh man, this would do wonders for the party van". HELL YES, good sir!

    btw how are your ad-hoc networks on osx? im on lion and it seems like apple 'ganked' them with lion

  • I'm on mountain lion. Just make the network, pick it on your iPad and you're done. No faffing about with IPs etc...

    The ease of this totally changes things too. Can have so much control, so easily. TouchOSC has such a work input to make a layout that changing any little thing is a whole pain in the ass.

  • I wonder will iPhones be supported at some point in the future?

  • This looks pretty damn cool

  • This is pretty big! Rodrigo - cool! Would I need max to run Party from my iPad with MIRA? I have m4L, but not Max.

  • You'd need whatever you normally use. It would still run in max runtime. The mira implementation would only be there if you want to use it, like the current TouchOSC version. Just another way to control what's already there, though it's super easy to use, so maybe I'll build more around it.

  • ::nods approvingly::

  • @rodrigo same with liine's lemur. it's not max, but it's not simple either.

  • I'm excitedly looking forward to more objects being added in coming months.

    (of obvious interest to this community: we don't have matrixctrl or live.grid yet...)

  • ^^ yup yup.

    I'm particularly interested in live.step.

  • I'm actually messing with it now. Can't figure out a good approach to adding this to an app that already has a UI. Do you duplicate objects inside the mira.frame?

  • Depends whether you want Mira to be optional or not. Duplicating objects, with accompanying sends and receives, isn't a bad idea.

  • basically anything with a slider right? :)

  • These UI concerns make me think that a 3rd mode could be useful : patching mode, presentation mode, and Mira mode.

  • been following this excitedly for the last few days, saving up for an iPad now. heh.

    some thoughts on programming for it so far:

    i don't think an extra max presentation mode is a good idea. max makes sense with two views, an edit and presentation. what if a new app comes out for android or a different device, should max provide a presentation mode for every device you want to display UI on? i don't think so. if you want extra user interface views for different devices in your patch then it should be up to the programmer to build them, you can use separate patches for user interface, use object scripting to move, resize or create objects in the presentation etc. when building max apps for monome we are effectively building user interfaces for the app, you don't want to clutter max's workflow with presentation modes for all user interface devices.

    i think the release of this app has tied in quite nicely with ideas i've been working with in recent apps, i.e monome notes (although the code is still pretty messy so far). basically trying to bring ideas or practices from other more standard or structured programming languages into max. (i'm not actually a "real" programmer, i've just been watching the free Computer Science courses provided by Stanford on youtube and think i know what i'm talking about now :P)

    so these days i always try to separate the code dealing with the actual processing, or functions of the application from the user interface part of the code. so i use pattr, the pattr family of objects and objects with scripting names extensively to send and get data around patches. i normally use a pattr object as a main parameter or variable for the application that when changed causes functions to run or changes in the app to happen.

    i make the user interface in a separate patcher within the app. any changes to the pattr/parameter objects are sent to the user interface patcher which sets or displays the changes on the relevant ui objects. any changes to the objects in the user interface patch are sent out to the pattr/parameter objects which update to the new value and then pass it on to the process part of the application to do something with.

    programming in this kind of modular way means if you want to add extra controllers, like adding an arc to a grid app, or if you want to add extra user interface displays the process is relatively quick and painless. you just make a new user interface patcher or subpatch which talks to the main pattr parameter/variable and displays or interacts with it in its own way. i think the code can also end up much cleaner, and be clearer to people working on, learning from or editing your patches. which i think should be a much bigger part of max programming and programmers thinking when creating max patches.

    when i've done a bit more work on Monome Notes i'll upload the "finished" version and hopefully have time to make a basic template and tutorial patch that shows some of these ways of working. i think they will really help when building patches so they can take input and give output to multiple other controllers and displays without too much code duplication.

    i strongly advise anyone doing max programming to check out the pattr family if you haven't already, have a look at [pattr], [pattrforward], [pattrhub], [pattrstorage] and also [pvar]. using these objects and using Scripting Names can save so much programming time, patch space and save you from a spiderweb patch full of cables all over the place.

    also getting used to the "scope" of scripting names and pattr objects is very handy. for instance at the top of the main patcher of your application you can create all the variables/parameters you need for the app as pattr objects with appropriate scripting names. if you then wanted two different user interfaces for the application, one for a computer screen, one for an ipad running mira for example, you could create a new patcher as a bpatcher for each user interface. make the desired user interface in each of the new subpatchers and set the scripting name of each patcher to something different i.e "user_interface_screen" and "user_interface_mira". in the main application patch you could have a parameter/variable in a pattr object with a scripting name "grid-width" which defines how wide your monome controller is. if you want to control this in both user interfaces you could create a [slider] in both the "user_interface_screen" and "user_interface_mira" subpatchers and name both with a scripting name "grid-width". these wouldn't conflict as they are in different patchers, but could be very easily talked to by adding the parent patchers scripting name as a prefix. with pattr objects you'd use "user_interface_mira::grid-width" to talk to it from the main patch or when using cables or send and receive objects you could just prepend "user_interface_mira" to any messages coming from the mira user interface patch.

  • here is a video covering all this "mira mode" talk

    luckily the programmer has already thought of a solution

  • @myr great post! food for thought indeed.

  • Hey, so I built something a while ago that let me develop for arc while my hardware was getting repaired. It wasn't quite an emulator, but considering you were using your mouse on default max objects, it worked much better than expected.

    The good news is that I just ported that to mira, and was able to simplify a few things in the process.

    The bad news is that updating multisliders over wifi (even over an ad-hoc network) is prohibitively slow, so I had to move the visual feedback off of the iPad.

    Anyway, I'm posting the experiment for academic study, mostly.

    See attached. Here's how you use it:

    Open plates_linked.maxpat (a hacked version of tehn's "plates")

    Open one of the two fakeArc maxpats. (the _slow one has LED feedback on the iPad screen. the other one, you'll have to keep open on your laptop)

    The interface is on your iPad.

    Drag with one finger to rotate a knob. Press with two fingers to activate that knob's button.

    That's pretty much it.

    I don't see this as a terribly viable arc replacement -- the LED feedback is basically ass. But if you're just looking to build endless encoders in mira, that much works great.

  • blue sky thinking: a field of grass and wifi. lol

  • is anyone else getting these erorrs in the max windown on startup since they installed mira?

    max: doesn’t understand “addobjecttocategory”
    max: doesn’t understand “setbadgeforcategory”

  • Checking...

    Yup. I've got a billion of the first one, and one of the second.

    Looks like my standalone max/msp is behind, at 6.1.2... updating now.

  • Installed the latest version. No longer see that error.

    Maybe it will crash less.

  • Good to know. I had several crashes the first time I used it which put me off a bit.

  • yep that's done it. cheers @GreaterThanZero

  • someone please buy me this. :(

  • oh, and they added gen code export in 6.13 - including porting to ios - maybe someone will come up with some sort of "bridge" external? im no computer scientist over here, i'm just a blue-collar abstraction guy.

  • Anyone else using multislider objects and having the problem of them reset back to 1 slider whenever you re-open the patch?

  • just a proposition, hacking a panel object based matrix to simulate ... leds :D

  • Huh. I could have sworn I'd tried every object listed here:

    Missed the panel altogether. Will have to look into that!

  • So how is it working with m4l ?
    Cause it would mean that for each liveset i could have a specific set of control that would load on the i pad, right ?i'm almost sold...

  • It would indeed mean that. Each mira-enabled device would display in a separate tab, and if you're really anal about it, there's a setting in the mira.frame object for establishing the frame order.

    Mixed feelings about m4l. mira.frame is more or less a 4:3 aspect ratio, where a m4l device could be any width. So, how you optimize your space is potentially very different in either context. I think Julien solved that by putting the onscreen controls in presentation mode and asking the user to configure mira to display from the editor view. This feels wrong to me; editor view shouldn't be concerned with presentation.

    Nothing wrong with either approach, but if I publish an app that requires one view and Julien publishes one that requires the other, the user will have to reconfigure Mira every time they switch tabs. And that isn't acceptable.

    So... we need a way to detect which frame has focus, and to let the active frame signal which mode Mira should display in. (or better yet, for that to occur transparently without our involvement)

    Maybe that's there now. Maybe it'll be there in the next version. But I can see it being an annoyance in the meantime.

  • heads up:

    Mira (among other c74 products) is significantly cheaper this week.

  • it's actually "pretty easy" to get editing on the ipad screen directly. it's kind of similar to a project i did where you could create and move modules of max code, in bpatchers, around the screen.

    you'd need to make a kind of "edit mode" button on screen, once pressed it would put a see-through button type object on top of all of the current UI objects in your mira.frame. when one of these see-through buttons is pressed down (looks like you're just touching the underlaying UI) it could work out any movements of your finger with a mira.multitouch and move the corresponding UI object the relative amount. mmm scripting.

    ...thinking about it, it's quite a bit trickier with mira, as apposed to the computer, as you'll have to use a mira.multitouch, rather than just getting mouse info.

    i'm planning to keep my copy of mira pretty firmly linked to presentation mode. i'm pretty sure/hoping it will become standard that any mira enabled apps created should be used in presentation. linked or editor mode should just be for experimenting and creating your interface.

    if you've programmed your app in a modular way adding a second UI for a 4:3 mira aspect ratio should be relatively little work. and i'd advise normally building it in a separate patcher/bpatcher which contains your mira.frame, lots of fun scripting stuff and is set to open in presentation mode.

    but then as usual i'll probably spend way more time thinking up approaches to different problems rather than actually finishing an app that solves the problem, heh.

  • My patch find you here:
    click on "SugarSynth for MIRA ZIP Download"

    Here tutorial with Mira

    Best wishes

  • just got it. haven't had a chance to play with it too much yet - but Sam (OMG Dude 873!!!) followed me on soundcloud, and we had a little message party. i had a nerd moment. he said he wants people to put up cool videos of what they've done with it.

    He also stated that "people have barely scratched the surface of what they can do with it" - he's a mysterious fella.