sum - Mira mod

  • Hi! I finally bought full Max during this recent 30% off sale so I took a stab at adding some mira.frame objects to sum. This takes some of the controls currently only available via the computer GUI and makes them available to Mira. Ideally, I would like to add controls for the Step Sound Editor but it's not particularly straight forward how do this at the moment so more research is needed.

    Currently there are 3 tabs implemented for Mira:

    masterControls: key, scales, tempo, volume
    modulation/envelope: mod env, fm multiplier, fm index, shape, slope, env length
    pitch/timbre/filter: putch env, finetune, noise, timbre, filter [resonance, env, state, cutoff freq]

  • sick!

  • cool, i'll check this out asap

  • " recent 30% off sale"

    maybe this means max 7 is on it's way??

  • @racs: not necessarily. there had been a huge max sale already last year when i picked it up.

  • ahh I'm getting ahead of myself :(
    I noticed there was a sale on Ableton too, it's probably synced

  • i've been messing with mira, but i've been messing with lemur a LOT. making some interesting stuff - but i have to check this out!

  • I need this for windows !

    Any idea ?

  • @starfucker: I've properly forked the github repo so I will post the source here shortly. Someone with Max6 on a Windows box should be able to build it.

  • I posted a proper release on my github page (original post updated too, I would use this one and discard the earlier version if you downloaded the zip previously from the hightail link).

    If someone with a windows machine could build a windows application from the source I can include that with the release.

  • eos: i only now had the opportunity to play with your mira mod. works very well here and opens up another dimension in sum interaction. appreciate the effort! even simple things like being able to influence tempo directly form a touch interface like mira is welcome addition. thanks for sharing!

  • @myecholailia - glad it worked well :) I'm digging it too because now i can ignore the laptop and just have the grid + touch surface in front of me. My favorite so far has been manipulating FM index and Envelope lengths.

    What will make it complete in my opinion, will be implementing mira with the drum step editors. I'll take a peak at that again soon but will probably end up needing to pick the brain of @galapagoose

  • okay, i'm getting around to this. with Trent's mention about the glories of JS, combined with my new-found comfort in lemur's C-like scripting language (elements of C, anyway) - i'm back at it. but i'm not making anything new until it's almost all JS - I love patch cables, but code is just the shit. Efficient as HELL, and studying (and poorly designing) algorithms is too fun :)

    I'm downloading this badboy tho. I'm stepping away from the Lemur until i get an iconnect midi - so sick of using the CCK and a USB UNO midi connection to my Komplete 6, and then having to go ad-hoc when i need to charge my ipad :(

    really excited! Lemme just edit about 500 field recordings for some sound design shit before i get back to it.

    Just throwing it out there, anyone in Brooklyn know anyone that's hiring a... well, one of us? i guess that's "musician, engineer, code hacker, designer, etc", and all round geek? sound design isn't paying well at the moment.

    LOL - if that wasn't just the thread hijack of the year! I'm getting this ASAP. I really C74 would implement more mira objects. dunno if they can use jsui - one thing i loved about the Lemur was their (bastard) implementation of the HTML5 canvas element. i mean, it's NOT canvas, as all the commands are different, but it's still KINDA canvas, and you can do some DOPE stuff with it.

  • happy to lend a few brain cells where necessary.

    every step sound is essentially an individual instance of the whole sum synth. i haven't looked at your work but i imagine it would be either making a bunch of tabs pointing at the different step sounds.

    i'm not certain how mira works, but the more effective way to go about it from a max perspective would be to dynamically change the pattr binding of your UI objects in mira. hopefully you won't need to actually edit anything inside of the step editors.

  • @galapagoose
    Thanks! For reference: Mira works (for the most part) by adding a mira.frame object to a patcher window. It acts as a "canvas" meaning, if a supported Max object: as of 6/16/2014:

    button, live.button
    toggle, live.toggle
    dial, live.dial
    slider, live.slider, rslider, multislider, kslider, live.text, live.grid
    message box
    number, flonum, live.numbox
    gain~, meter~
    mira.multitouch, mira.motion

    is on a mira.frame object, they will show up on the iPad. Every instance of mira.frame becomes a tab in Mira.

    I think I need to determine whether it's possible to have only 1 Mira tab for whichever active step/synth is is being shown via thispatcher by dynamically creating/removing mira.frame objects via scripting. Or, I may have to have 15 tabs and focus whichever one is currently being edited.

  • once you drop the object inside the mira.frame can you still access it like a normal gui object?

    if so i'd just make a single interface and send all the objects 'bindto' commands (or is it just 'name' or 'scriptingname'?) to change which pattr location they are bound to. when you change the scripting name it will auto-update to the current status of the newly bound object.

    finally make a tab in your mira.frame (it does not need a scripting name) which sends an int that triggers the update of the scripting names.

    i'm not exactly clear on how mira works, but i assume it has a live connection to the app and allows bindings to change inside your max patch? i guess this would mean the mira interface is really just aliases for the computer objects, so it would seem changing pattr routings in the patch would simply have the effect of making the object look like it's moved to a new place.

    thinking out loud!

  • Cool, thanks for the feedback guys. This is right at the boundaries of my experience/understanding so I'm going to do some thorough reading on pattr/binding tonight.

    Things I know now:

    1. the mira.frame object needs to be live inside drumeditor.maxpat because that's where the UI objects exist that we want to manipulate.

    2. 'script newobject mira.frame @varname mira[%d]' is the proper scripting format thispatcher expects.

  • i guess we're suggesting that rather than having to manually edit the drumeditor patch at all, you create a new patch with your UI objects, and you bind these 'interface' objects, to the 'real' objects in the patch.

    you'd need to send a message to every interface UI object each time you switch tabs, but this avoids needing to reconstruct the mira UI for each new tab you add.

    to put it another way, the interface in sum is really just a bunch of UI objects displaying the internal data of sum in a UI object. the sliders themselves don't actually 'store' the data, they are simply a lens into the internal pattrstorage object. this way all the UI is arbitrarily modifiable, and it would be possible to radically change the UI without having to update the patches themselves.

    we're suggesting you use a similar approach for the mira interface – building it once, and then changing the data connections on all the objects. pattr is highly useful where if you change the binding of a UI object it's graphic display will update to show the newly attached data instantly. the presets in sum work in much the same way but with sets of data, rather than changing the source of the data.

  • Thanks for taking the time to put it that way, because it clicked for me. I understand the gist of the concept now --- and I'll give it a shot!!

  • @emergencyofstate
    I have been having a bit of a look at this today and have a proof of concept that should work with mira and would also reduce the number of UI components significantly in the base sum app. I'm not totally sure it will work yet but it's about 75% there.

    - I've cut the drumeditorswitcher patch out completely, the main sum window now opens drumeditor directly.
    - I've placed the 1-16 selector and the mira.frame inside this single instance of drum editor
    - The output of the 1-16 selector feeds the store-in-coll subpatch, I've added an inlet and this replaces the previous #1 variable so that the correct drum sound gets updated.
    - The output of the 1-16 selector also updates the GUI elements by being fed through a "sprintf varname svf-filt[%ld]"

    My grid is currently out of action as 10.9.4, my arduinome and Serialosc are not playing nice so I can't test this.
    I can confirm that I end up with the values for each individual drum sound being correctly updated from the single UI instance to the drumsounds coll.

    The one thing I haven't figured out is how to make the single UI instance update to the currently stored values when you switch between drum sounds. Also the 1-16 selector is a tab which mira doesn't support, I can't imagine it'd be that hard to replace with buttons.

    Just FYI, if I get anywhere more useful with it I'll let you know.

  • Just saw this post, would be happy to build the windows version. Just need to ask a couple questions, sent a PM.

  • @herringson: thanks for taking a look and providing this info kind sir. I'll have to jump back in there myself and take a look this weekend.

    @shimoda - replied!

  • Hiya -- @ shimoda was kind enough to spit out a windows build...

    Any windows users out there with Mira that could give it a test?