poll: max4live support and future directions

  • hello!

    i've spent the day poring over the enormous list of patches and applications in the wiki, and am presently attempting to dream up some ways to streamline their organisation, and also develop some tools / systems to help people find interesting patches.

    max4live support is one significant element which has proven rather elusive to me, and i dare say a number of others. at present there are a number of 'systems' (pages, 7up, liiive, stretta-suite) which handle different layers of integration, but they aren't particularly well organised nor compatible with using multiples at once.

    i have some ideas about how this might be implemented but would love some community input regarding some general questions that could guide the structure of such a system:
    - how do you currently use the grid/arc when interacting with ableton (max4live or not)
    - if it were possible / easy / logical, would you want to run all your patches from within ableton?
    - what major barriers / frustrations / gripes do you have with the present m4l offerings?

    i'm starting a wiki page to create some kind of working document to describe my ideas and i'd be grateful if you would add your thoughts and suggestions: http://monome.org/docs/app:llllllll

    please make changes and add your thoughts to the wiki page but UNDERLINE anything you add so we know what's new.

  • hi galapagoose!

    hope you're well!

    i've been doing the majority of my monome'ing in max 4 live for the last few years. i've gone through a few different systems but am currently working with, and on, one that i'm pretty happy with. i haven't really shared any of it yet as i didn't feel it's up to a good enough standard to share without documentation.

    what i've built already sounds similar to the ideas you've been thinking about and i'd be more than happy to work on developing those ideas, based on some of the things i've built or starting fresh. possibly what i've been missing for a while is some other people to throw ideas back and forth with, and to test and work on the devices.

    [am moving the bits below to individual posts with attachment so it's not so cluttered]

    distributor device:
    i've built a device similar to what you've described as the distributor in the wiki, it's called "Monome Grid", there's a near identical one called "Monome Arc". it houses the serialosc connection, and controls which "monome m4l apps" are being connected to. all of the other m4l monome apps, i.e clip launcher, device control, game of life, send their led messages to, and receive press messages from, "Monome Grid".

    i've built a thorough auto-focus abstraction for m4l that deals with it all well. i'll attach it here. it doesn't currently work with the distributor device, need to add a way for apps to send a focus request to the distributor.

    live api control:
    i've built a very thorough device for interfacing with the live api, it's called "M4LC Hub". i'm just finishing converting it all over to using 1 dictionary to store all the live api data, rather than lots of var and coll objects. i need to update the other m4l monome apps that talk to the api, such as the clip launcher, to use the new 1 dictionary system.

    clip launcher:
    i've built a clip launcher, and am planning to add a few more useful features now possible with the live 9 api. just needs updating to use the new version of M4LC Hub.

    game of life:
    i've built a version of game of life for max for live, it was a while ago so it doesn't link with the distributor device though, had it's own serialosc i think. will check it works and post it up.

    ableton push Notes and Scales mode:
    i've built an app that emulates all the Notes and Scales behaviour and more, i'll port it to max 4 live over the next couple of days and post it up.

  • @myr all of this sounds fantastic!

    as much as i'm excited to work on this stuff, i'm even more excited to hear other people have been working on it for a while. i remember you sending me some interesting api related things earlier in the year that i regretably never got around to working with..

    of course you're more than welcome to continue as your own project, but i'd love to help complete the package / documentation and make it easier for users to get up and running as quickly as possible. also, if the basics are already in existance (the distributor & live api & clip launcher) then i can spend much more time porting apps and refining patchers / gui.

  • distributor device:

    i've built a device similar to what you've described as the distributor in the wiki, it's called "Monome Grid", there's a near identical one called "Monome Arc". it houses the serialosc connection, and controls which "monome m4l apps" are being connected to. all of the other m4l monome apps, i.e clip launcher, device control, game of life, send their led messages to, and receive press messages from, "Monome Grid".

    it saves the setup with the live set, using [live.] user interface objects and the "parameter mode enable" attribute on pattrstorage. it also has a preset system using the pattrstorage object. i've made the preset recall and store controllable by [live.] user interface objects so you can midi map them or automate them. for instance you could write automation into a clip in live which controls the preset recall, then launch this clip to change which app is focused.

    so far it doesn't allow for app switching from the grid. I'd like to add the option but keep it optional so you can just app switch via scene launches or auto focus.

    auto-focus isn't currently implemented, although i've built an abstraction that handles auto-focus detection. i think the auto focus would need to be within the individual monome app, which would then send its focus request to the distributor device. sound good?

    the ideas for the columns displaying channels and being able to select two apps for display sound great.

    currently i'm using send and receive objects to send data between max for live apps, would you rather use udp?

  • @galapagoose
    sounds good! i'd also like to get the parts i've worked on out, finished and useable as quickly as possible. they've been in the works for ages and should really see the light of day. i'm pretty useless with user interface design and documentation so would be really happy for you, or anyone, to help work on that.

    it will take a bit of work to get the devices i've built to talk nicely to each other again. i've developed new ways of doing things along the way so the devices i've posted above won't actually talk to each other properly anymore. i posted them up mainly as examples, with the majority of the work done, just the communication protocol needs solidifying and copying to all of the devices.

    i've got the next week free, so will try to get the distributor, clip launcher and live api communicator up to scratch and working solidly. also the push notes and scales emulator if i have time.

  • clip chopping:
    i'll also work on updating live clip chopper, haven't looked at it in quite a while, but i don't think the live api has been updated to improve the speed at all.

    i still think a mlrv type device which contains its own audio buffer and sample player would be much better, especially now you can get the hard drive location of any audio clip in live's session view via the live 9 api.

    something like a single channel of mlrv which can be dropped on an audio track and mapped to a certain row of the monome grid.

  • you'll have to explain the preset system & scene launching automation a bit more because it sounds like black magic to me! i like the idea of being able to automate which app is focussed for which scene (eg. taking you to a step sequencer at the beginning of a new song / taking you to the clip launcher after you've been step-sequencing for 12 minutes .. haha)

    personally i'd like to present something that is as simple and easy-to-use as possible, so perhaps omitting (or nesting) the more complicated features would be advisable..

    using send&receive is probably far more robustly implemented than udp i'd guess (also much more lightweight).

    let me know which devices are most recent and i'll delve more into them (gotta get a copy of live9 first..)

    i'm going to start writing out some required functionality for the child patches into the wiki and then start a mockup template & style for them.

  • i've got a version of mlrv mapped out in my head already, so knowing you can find audio files easily is refreshing. going to build it across multiple channels so you can mix the audio in groups properly..

  • I spent an hour or so going through the m4l section of the docs and unfortunately a tiny percentage of them even work at all with the current version of serialosc. I suppose a bridge app could be used but if we are confident serialosc -as we know it now- will be around for a while, we should consider porting/re-doing/revising some of these older serialosc m4l apps. (maybe some prioritized "key" apps we agree on?)

    I know for a fact there are threads floating around with patches that were modified and in use but are not present on the docs/apps page. _edit_(For instance, this very moment I'm running press cafe in m4l on my 128 using the latest serialosc).

    I will continue to scan and am willing to help in any way I can in this effort.

  • yeah - i think an important thing to do is make a list of apps that should be ported (whether they have been or not). i'll be investing some time into giving everything a unified interface so there's a bit of a language to how you interact with each patch...

    i've got a shortlist, but please help me elaborate it.

  • here's a working version of a "distributor" (Monome Grid.amxd) and "template app" (Monome App Template.amxd) device using the simple system i had working.

    it uses a global send and receive between the distributor and apps. messages are routed to and from the apps by setting the "App ID" parameter in both the "distributor" and "app" to the same value. in "Monome Grid" the "App ID" to connect to can be edited in a text edit under the word "Prefix" (should say "App ID" really). then click the corresponding square buttons under "On" to open the connection to the app. in "Monome App Template" the "App ID" can be set in a text edit, which will then be saved with the live set, but without a pattrstorage it's not automatable or midi mappable.

    as you can't automate or midi map a text edit object in max for live there's a pattrstorage object which allows you to preset all the text edit objects and other parameters in "Monome Grid". The preset recall parameter can then be automated or midi mapped, allowing you to write app switching into clip automation and trigger the app switch by launching the clip or containing scene.

    tomorrow i'll work on tidying them up and adding more comments, also work on a slightly different system for communication.

    you can generate a unique "app id" for each "monome m4l app" using the symbol "---" in a max for live device. like "#0" in normal max. on app initialisation the "app-id" could be used to create a unique [forward] and [receive] object for the app to communicate over. the app would broadcast its existence with its "app-id" over a known global send and receive and also store the app-id and information in a global [dict] object.

    it would look quite similar to the example patches attached here, but would save so many messages being sent over one global send and receive. it would also allow a list of available monome m4l apps to be populated and selected from.

  • @myr

    I've almost finished an mlrv a like for ableton, based on alex augers ml(ive)r but with some additions like sequencing patterns into clips, per step automation, and closer integration with live. It's also got groups. Not quite at distributable state yet but its getting there. Currently ive only got push support (and flakey launchpad), but happy to add monome, etc

  • @Myr

    It looks like an amazing tool, somehow the serial osc doesnt work for me, (just nothing shows)

    aslo playing around with it i couldnt figure out how to name presets, sometimes it named the first one, mostly it just saved it as unnamed

  • this is a great idea, it would be great to have a system that could integrate max for live apps, so when creating a new one it could be done in that system so more and more apps would be unified.

    @myr i've tried and i could connect my monome with serialosc but i was unable to make other apps to speak to each other.

  • I am very interested in following this discussion. Ideally I would like to run all my monome apps within Ableton; auto-loading and auto-connecting when I open an Ableton file. Currently I run some patches within and MLRV externally, rewired back into Ableton. I also don't have a standard good app for mapping monome/arc to ableton functions...

  • I think that you have to add the obo version made by novasnoa ... He fixed all my problems.. I tried different kind of obo ...now i can use pattern change with knobs & ableton clips without any kind of audio glitches

  • At the moment i used two Apps: Monomodular (python Based Monome Emulation/Modular App System made by Aumhaa)and Sigaborts Gridlock (the only Emulation that i know that supports the new Serial OSC). As i am no coder i can only do Testing support for both an make some suggestions. One was to bring both Projects together to get much more flexibility and more possibilitys in working with Monome stuff on an Emulation (on the Launchpad in my Case). Most of the Stuff i use is max4Live, some Apps like Insnity for example run in Native Max.
    I really Like the Idea to get/make a Plattform as a "standartmodel" so to say when it come to working with ableton/Max4Live (a Plattform where i cam controll all my used apps was the idea behind connecting Grodlock and Monomodular.....haven´t seen this Post as i came up with it).
    I´m not quite shure, but i guess the Python Scripting aumhaa had done for Monomodular, specially when it come to conversion of Midi Messages into osc for the Monome Apps, the wide arrey of Supported Controllers (Livid, the APC´s, and Lauchpad are fully supported atm) as well as the possibilitys of defining what every single knob on the grid does (one of Gridlocks benefits) would come handy for this Project as well.

    A Modular system like Myr has came up with or Monomodular would fit the needs of us best i guess. Everyone can load up what he/she needs without cluttering the system with stuff that gets mostly never used.

    I point both aumhaa and sigabotrt to this discussion, who knows, maybe they join in the project and contribute as well.

    Another thing that would be nice is a "wrapper" for native Max Apps (like insaity) for enabling you to load up a native max app inside ableton (in a Midi Rack along with others for example)....but i guess that will be a dream....

  • hi guys,

    i wanted to show what "M4LC Hub.amxd", my attempt at simplifying and consolidating communication to the live api within a live set, is capable of. so, i've created a tester version which has some extra controls and comments in the user interface, the controls allow you to test parts of it without having to write other m4l devices. i've attached a copy to this post.

    it's not finished yet and i'm still in the process of converting all of the old functionality over to a new way of doing things (wohoo Dictionaries!). as such some functionality is currently limited, for instance currently information about what clips are in the session view clip grid is only collected on device initialisation. in a full version working with other apps "M4LC Hub" will update and store information on the session view clip grid continuously.

    let me know if you guys can get it working from the instructions in the user interface. more thorough documentation, commenting and help patchers to use it are needed, but hopefully you can see how it can be used and useful.

  • @galapagoose @st8

    awesome! look forward to seeing some mlr style samplers that integrate nicely with other apps.

    i've been having a lot of fun with the [grainstretch~] object by Timo Rozendal. would like to make a granular mlr style sampler. may have to rewrite the granular algorithm in gen as the [grainstretch~] is 32bit only as far as i know.

    in the M4LC Hub Tester example above i added the get audio clip file path function, and also added the function that jumps position in the playing clip, like live clip chopper does. it's definitely somewhat quantised, without me writing any code to quantize it. worth working on an app that uses it i think.

    sorry to hear the serialosc connection isn't working. it currently contains my own version of serialosc.maxpat. i imagine the finished version will use the standard serialosc.maxpat.

    the preset window may be an old version of the code, sorry it isn't working properly. i've got a more advanced preset window built, which lists preset number and names in a spreadsheet like grid, allowing you to edit and rename them more easily.

    they are only examples of an initial idea so far, so won't work with any other apps.

    steps to get the distributor and app examples to work:
    - open a blank live set, drop a copy of "M4LC Monome Grid.amxd" and "M4LC Monome Template App.amxd" onto a track.
    - select your monome grid device from the drop down menu and click the "C" (connect) button.
    - in "M4LC Monome Grid.amxd", in the "Apps" section of the user interface, change the "Prefix" of App 1 to "template" (it's "application" by default).
    - in "M4LC Monome Grid.amxd" click the square button labelled "On" for App 1.

    your key presses should now light up the leds on the monome (vary-bright only, think i used the led level set command). or you can draw on the grid object in "M4LC Monome App Template" to see the corresponding leds light up on the grid.

    try dropping in a few "M4LC Monome App Template.amxd" and giving them individual "App IDs". you can use the app size, app offset and grid offset parameters to change what part of the grid each app focuses on.

    ah, i've had a few versions of apps that map the appointed device or selected live parameters to arc encoders, or faders on a monome grid. i'll polish one up and add it in to the project.

  • I'm currently working on converting/porting a few standard Max/MSP patches into M4L patches. (TML - grid+arc micro looper & Boinngg - grid bouncing midi pattern generator)

    I've also cleaned up Obo grid sequencer: Added improved preset recall behavior (http://monome.org/community/discussion/comment/198292)

    I'm going to keep track of everything so as we evolve best practices I can modify as needed and post on the wiki

    @Myr -- wow. cool, I'll need to dive deeper.

  • A little aside: I'm wondering about the use of "---" before send and receive objects in M4L. I've heard you need to do that but I've never experienced adverse behavior from a patch that doesn't.

  • @emergencyofstate

    it's to do with the programming idea of scope, such as "global" and "local" scope, or max's version of it anyway.

    it's useful in certain situations, not useful in others. it depends on what other, if any, parts of max or max for live devices you want your device to communicate with.

    many objects in max share and store their information "globally", such as a send, receive or a buffer~ object. if you know the "name" of the send, or buffer~, any other part of max or max for live device can get and edit the information from your send or buffer~ objects.

    this can be useful in many cases, but what if you want to hide or stop people from editing certain information. for example if you have a device with a sample stored in a buffer~ object named "sample". if anyone else makes a max for live device and creates a buffer~ named "sample" it will interfere with your device. also if you open two copies of your device both buffer~ objects will look at the same sample, any changes made to one will affect the other.

    so, you could instead use "---", which generates a number unique to each m4l device. name your buffer~ object "---sample". then if you ever want to use two copies of the device in the same set with different samples, or anyone else makes a device with a buffer~ named "---sample", the devices won't interfere with each other.

  • @Myr this is an amazing tool too!!!
    i am sure i will use i alot in the future, i would be very happy if you keep on posting it whilst updating!

    big thanks for sharing it!

  • @Myr Thanks for the explanation. I did not know --- generated a number.

  • @emergencyofstate
    yeah, so in the last example "---buffer" is turned into something like "2419buffer" when the device is not being edited. this is kind of like "local" scope in max.

    you can test it by creating a blank max for live device, create 1 message box with "---" inside, put the message box where it can be seen in the user interface then close the device for editing. if you look at the device in ableton you'll now see the message box with a random number in it.

    the "---" number is unique to each m4l device but it doesn't truly give a device "local" scope or stop other devices finding out the number. in the distributor device for this project i'm planning on using the "---" number of each monome app to create a unique send and receive object to talk to the distributor. i'll likely store each monome apps unique "---" number in a global named dictionary (something like "m4l_monome_apps") with its app name. the distributor device can then look at the "m4l_monome_apps" dictionary, look up the "---" number for the selected app name and then connect to the app over unique send and receive.

  • @Myr - I am really appreciating your input on this. @emergencyofstate and I were just pondering how to access the 'appointed device' through the API on this thread. http://monome.org/community/discussion/16654/maxforlive-parameter-control-arc-2#Item_4

  • this is needed

  • here is a quick and dirty version of a Monome Grid Device Parameter Fader App Thing. it maps the parameters of whatever the current appointed device (a.k.a blue hand device) are to faders on a monome grid.

    it's pretty messy and could of course do with a lot more useful features, as well as converting to an arc version.

    it works in conjunction with the distributor app example, "M4LC Monome Grid.amxd", which i posted above. drop a copy of both devices into ableton. in the "Monome Grid" user interface change the "Prefix" of one of the Apps to "parameterfaders", and then click the "On" button next to it.

    let me know if it works for you.

  • Works perfectly. Thanks Myr. If I get a chance over the weekend I'll think about how to use the arc alongside this...

  • @myr i just got the doubt if your patches are made for varibright only... because in that case they won't work on my monome. i followed your instructions setting up the distributor and the template and as i can connect to serialosc, i don't get response on my monome. thanks!

  • Working fine on my non-varibright.

    m4lc.poly.deviceparameter is a sight to behold!


  • @Trinxat

    here's a screen grab of an example setup that is working for me.


  • here's a non-vari-bright version of M4LC Monome App Template. it wasn't using any different led levels anyway.

    let me know if it works for you.

  • @declutter
    sorry about how messy it is, heh. too much coffee and not enough forward planning. working on tidying it up and abstracting/sub-patching parts of it.

    the part of the app that deals with taking presses from a grid, and sending leds to display is very small and pretty simple. will be very easy to convert to an arc version once i get it all tidied up a bit.

  • here's a slightly updated version of M4LC Hub.

    if anyone looked through the last version they may have noticed i'd gone to a bit of effort to create the right hierarchy within the dictionary before setting values to sub dictionaries. only today did i notice that changing all the "set ..." messages to "replace ..." does it all for you.

    also added observers for the master tracks volume meter, and peak level.

  • The hub looks amazing, myr, but I haven't quite understood the point of it. Can you explain how it can be used?

  • @declutter

    i'm just finishing up adding all the old functionality to the new dict system, which will allow it to work well for clip launcher apps again.

    i'll knock up a quick clip launcher example test, and polish off an old fully functional one, once i'm done which should help show why it's useful.

    the last clip launcher app i built didn't have a single [live.path], [live.object], or [live.observer] in it. all of the api work was done in M4LC Hub with the clip launcher app just sending and receiving messages between M4LC Hub and the controller.

  • i'm away for work for the next few days, but will try and get a more advanced/simpler to use version of the distributer and app template. my main idea is to store information about current "m4l monome apps" in a global named dictionary, and have them announce themselves over a global send and receive. this information on the m4l Monome apps can then be used to populate drop down menus of current apps, which you can select from in the distributor. the individual m4l monome apps would then need no configuration for connecting to a monome, they'd simply appear in the distributor where you could select to connect.

    would it be useful to come up with a name for this project? could then maybe setup a github? and also have a useful prefix for send and receives, global data etc in max.

    i've currently been working on the project under the name "max for live control". basically pinched from ST8's "live control" python script. maybe it would be useful to get monome in there?

    would be good if it was easy to understand as an acronym, i.e "m4lc" has m4l for max for live in it. often prefix max patches and other things in max with the project name.

    maybe "Monome max for live" or "mm4l"?

  • Thanks Myr, look forward to seeing that clip launcher. I've already been cataloguing all your apps under M4LC so I'm happy to stick to that, but also happy with mm4l!

  • regarding the name - just think about where you're going to see it (in the ableton browser) so it would be nice to have a short but indicative prefix. you could even use the classic underscore to make sure they're all at the top and bunched together in the browser.

    personally i've never liked the '4' meaning 'for' but that's just an aesthetics thing...

    also there are already about 10000000000 monome applications with 3 or 4 letter abbreviations as their titles, most including the letters 'm' and 'l' so perhaps a random 4-letter word that you like would be more helpful... haha!

  • This is off topic in relation to the Router system BUT

    It'd be great if we could implement (like BEAP and other Max/MSP externals) RIGHT CLICK for the contextual window and choose:


    Then.. boom! you've got a sub-patcher ready to go. There could be other useful things as well like a lot of things found in the SerialOSC Dev patch

  • @myr - just so you know I still have my eye on this thread. no pressure!

  • back to working on this again, sorry about the wait.

    really want to have a working version of this by the new year. a kind of pre new year resolution.

  • no pressure but i think this could solve all my problems in life ;-)

  • perfect timing -- just got hold of live9, as well as building a nice solid .js interface for routing data to/from multiple devices.

    will shoot you a pm!

  • dude y'all are fuckin BOSSES up in here!!!!

    much respect.

  • Really excited to check it out :) Respect.

  • Just got off the phone with Israel and Palestine, they said they're willing to shake hands and settle their differences when this all up and working. No pressure.

  • no-sleep-til-two-state-solution

  • hopeful bump?