monome

thisinstance is a maxforlive primitive for dealing with two issues of maxforlive monome tools.

issue one: how to deal with multiple instances of the same monome app

issue two: how to direct focus elegantly from multiple monome apps to the monome hardware


There are three types of autofocus behavior.

Track based autofocus is the most typical. When a track is selected in live, the monome app on that track assumes control of the monome hardware.

Plug-in based autofocus is used if you have two or more monome applications on the same track. Focus is applied when the plug-in itself is selected.

Off turns off autofocus completely. Focus is only achieved by clicking the toggle manually.

I'd like to say that this utility will completely usher in the future of monome use with Live. Freakin amazing.

Gotta convince my wife to let me buy M4L :(

This is so clutch. You're the man Stretta!

Stretta, is it possible to separate the concept of actual UI/Track focus that you describe above from the concept of app/monome instance focus (ie, grabbing monome control).

While I understand the concept of using the UI for focus, I think that is not necessarily the only viable model. Focus of the app is not necessarily tied to what you are viewing on the computer screen, although it could work that way.

Obviously, in the case of 7up for instance, the app is spread across numerous components. Focus inside the app is controlled via the monome.

I would be all for a generic protocol for shifting app focus on the monome. I'm just saying that I hope the protocol is not specific to necessarily tying it to focus in the UI. It might be controlled by keypresses or a remote midi device or whatever. Sometimes you want to move around the DAW without shifting focus on the monome.

I don't mean to imply there is only one viable model. I'm simply offering the primitives as a way for the monome community to take advantage of the methods that I'm using.

The third autofocus mode (off) is essentially the same as banging the prefix out to monomeserial - no different from how any monome application that uses monomeserial works currently. If you don't want autofocus, just turn it off. Simple.

Since focus is achieved by banging the prefix out, this can be accomplished by any method you like including a key press, remote midi device or whatever. Very easy.

what i used for the dj64fx m4l was the crossfader on the bottom changes a forward message that sends all the press info to whatever [r ---djfx] and each separate instance has the led data stored in a matrix control which gets a bang when that 'page' of effects is selected thus changing the focus and leds..

it would be very easy to make a pages styled monome router app which you could assign different device to each page in live and switch focus between them..

using the --- is naming sends and receives is one of the things thats impressed me the most about m4l..

@stretta
Thanks for the clarification...sounds great. We can't participate because we connect to UDP via Java so we can't share ports with other m4l apps, but the idea is really nice. This where I wish it could be at the monomeserial level.

@stevieraysean
We really need to use the --- notation. Thanks for the heads up.

if anyone can think of a better way than manually going through patches and finding all 'send' , 'receive' , 's' , 'r' etc objects and changing them manually i'd like to know :)

maxpats are text files...some fancy grep command might do it.

@ Stretta

Still no LEDs. I'm noticing with the newest thisinstance.amxd that my UI is correct now. Before the matrixctrl objects were out of whack and looked different. Now everything is neat and clean and the matrixctrl objects look right.

Anyway, after dropping a fresh instance of thisinstance into a track, here's my max window. Does this lend any clues?

You're running the patch inside live, correct? It won't work inside the max patcher.

Yes, this is inside Live. Got it all open now so I can try anything. It must be something minor. The oscroute.js inlets are never broken so that all seems correct.

Monomeserial: 0.2.0

So I've downloaded a few different m4l patches and have been poking around a bit, doing some max tutorials.

I've added this patch and am trying to edit it. The enable edit command is grayed out.

I'm able to edit other patched and am not sure what is going on. Thanks for any help!

hmm. sounds like it may have opened in max runtime? do you have that installed also?

Yeah, I should probably remove all of my old max stuff and reinstall.

Reading another thread about packaging these things had the solution - click the unfreeze button.

I am not sure it is the good thread, but anyway, stretta, I am trying your awesome suite for m4l, playing with obo and polygom

@chapelier fou
Make sure autofocus is set to 'track'

Yes, I do. obo seems buggier than polygom

I just retried. this time, polygom

I've uploaded an autofocus maxforlive device at the thisinstance wiki.

You only need to edit the base prefix in one place. Simply replace 'sf' with the name of your patcher. The sub patcher then does all the messy routing for you.

Moved from
http://post.monome.org/comments.php?DiscussionID=6538&page=2#Comment_76851

stretta said..
"edit: I tested stepfilter and it works as I've described. Make a preset with autofocus turned off, and with the focus indicator ticked off. The preset recalls correctly and no prefix is banged out until you manually do so."

I see...I didn't have the "focus indicator" ticked off as well as autofocus "OFF". Still grabs 8080 8000 though...but I guess that saving of ports is not implemented yet.

Yes, the focus indicator needs to be saved in the off position, otherwise the maxdevice will grab focus as soon as it is recalled.

Altering the OSC ports is a new feature for the next release which needs to be tested. There isn't a text object that live can store/automate to the best of my knowledge, so this would not be saved.

search for "pattr" from MAX help. Click "live_pattr"
The document "Using pattr in Live Devices"

"If you want to use standard Max objects and have them interact with Live, you will have to make use of the parameter mode features of pattr objects. The first step to enable parameter mode in a pattr object."

"autopattr" does not work.

Thing is...I'm 99% sure I had this working with the MAX text boxes in 7up and they were saving to the presets, but now I see that it's broken, not sure why. I'll let you know if I find the answer.

live numbox though works fine for port values.

Having an explicit "start" or "connect" option that can be saved to ON position but defaults to "OFF" might be an option to be a little more explicit for the user. Just a thought.

Interesting...yeah saving the state of MAX objects in M4L was working in the betas just before release, but seems to have been removed from the release version. It was all working in 7up but now it isn't saving the text fields like it used to. I guess that means it is likely coming soon.

Here is an example from cycling of how to do it in MAX For Live beta...but this example no longer works.

The relevant bits being "Parameter Mode Enable", "Restore Value at Patcher Load", "Parameter Visibility" = stored only


----------begin_max5_patcher----------
492.3ocqT01aaBCD9yvuBj+bWDjlsnNUUo86XpB4Deo41.aj4HMoU4+dsOLD
RkosSZRIlj6smm6wG2qoIhMliPqH6mY+NKI40zjD1j2PR3+IhZ4wsUxVNLgF
d1r4Oha5ccPZ0xZf8PvQZvN+auwFIQ1rotLcTEPzoFnGVg3lv2rGCgrynoV7
ENfhkKxCl0c0n1kKSjhfQG.a2i5mJsvVpuhqW6RIaEe9c9bY9h7wpiJlYtt3
aKESPbrQ9kEkUhKf1yXF0aCVsPKYrCcv8PcCc5gKMPq7.nJcH33ToWAvMcTu
NmLpqdtacXRfsDzxMU88K66b5UUZrDePwNHq5.ytAyC1mhREp+quK4bCp5UA
TaTtOvbtQ8NCqPhHNMVEXmKyNM1KfQSssA.UEVOW1sDzLKmgiMFMn469hEyB
NcJnuQ6a2Hd+v15Ew8iZF+ndGlkuMpjgjaZZxEbzFbuwRwdQ5c05.1hCyIyb
88wMhTqMjjPitbDtXPUYzO8o7wC2ntz69bZ5kG7oaR9KtYwCCnPZtcKS8EcI
B5FB9euK4te32eb2J+YQdNuRYlkIE+qKSVMQj3BJbuf99swLm71uV4ZMc1sC
MeXUVVwHsTt8SnlunmDiigYWn9dTo.8jQRQMpZLNULPgrGuhfomSeCPVwwHH
-----------end_max5_patcher-----------


Ok, enough on the subject...

hey, so, this is pretty neat.

but, i've been thinking of my monome and ableton in a slightly different light.. i want to have an app setup that controls everything i need in ableton from the monome, but this introduces a new problem that autofocus doesn't solve.

i want to post this here, because i think consolidating this sort of functionality is important, and autofocus already does some great things.

basically though, the problem is that of splitting different sections of the monome up and mapping them onto different tracks..


i've given it some thought, but haven't really come up with any concretely good ways of doing it within this sort of framework. if anyone has any ideas, i'd be happy to discuss, preferably without derailing this thread too much.

yo soundcyst have you checked out monoroute with auto configuration?
its a java patch you run along with monomeserial.
uses osc to setup automatically when you add patches into live.

allows for patch changing with two button presses. similar to pages but the buttons can be defined. ie you could have 16,16 and 4,5 to change to mlr or whatever..

most of the doc at http://www.loop-party.com/

also

http://vimeo.com/videos/search:monoroute

i haven't. i will check it out now though. thanks.

Has anyone succeeded to use some sort of autofocus mechanism in combination with molar? I tried the autofocus patch tonight and changed the prefix in the patch to the same 3 chars prefix as the one in Molar128.cfg, however it's not possible to get led feedback on press when I switch to the other monome patches.
The prefix switches correctly, Molar works and the leds from polygome lights up for example, but no reaction on press.

It would be nice to be able to have Molar running together with m4l patches, and some ableton live control patch. I tried my old pages setup today as well but it doesn't work well in live 8.1.1 for some reason, the clips are not updated correctly on the monome :(

@ soundcyst

i've been thinking along the same lines as you.

i'm intending to start work on a suite of mini-appliciations that allow you to split the monome up for diffrent purposes. Probably into columns or clumps of them.

I'm hoping miniature step sequencers, banks of on/off switches, toggles, clip launchers, loop manglers and all sorts of other devices could live quite happily on one page of the monome together rather than being spread across different prefixes or pages as they are currently.

I've checked and it's possible for a couple of different m4l applications to share the same prefix and have managed to switch between groups of them using stretta's auto focus (probably obvious to some, but i'm new to this max and OSC malarky).

i'm hoping that i can impliment some logic that'll allow apps to find a space for themsleves on a monome prefix when they're started up and think this will still work with stretta's autofocus.

i'm a little concerned about wether it'll be compatible with this new fangled autoconf/monoroute stuff though. I've yet to look in to it but plan to over the next couple of days.

fingers crossed i'll be able to pour a week in to this from next Monday onwards but i haven't had the time off work confimed yet.

any offers of help or ideas about how things should work would be much appreciated.

apolagies if this post wan't really suitable fo this thread. i'm beginning to think i should have started another one...

I've been thinking about this as well, when jamming I prefer to switch directly on the monome, from arming clips in live to Molar, then switch to a m4l device etc. It's nice if it's possible to have both modes, one where the monome is the master, and another one which is controlled from the computer when arranging for example.

As a temporary solution I think I will add a prefix and port switch in autofocus, and let pages be the master when jamming. Maybe it's possible to reuse a lot of the pages code and come up with a nice master patch in m4l in no time :).

@ billinsky

i think what you're after will arrive with autoconf/monoroute. I don't know if molar will be compatible with this though.

what i'm talking about is multiple apps sharing the same page and then hopefully being able to page between those.

The idea of 'mini-apps' is cool, using columns (or indeed rows) rather than the whole grid will allow users to completely customize their set up. As triss said these 'mini-apps' could be for all sorts of controls, for example loop mashers, step sequencers, sliders, clip launcher, toggles or what ever you can think of.

Having the apps so they only take up a column (or row) means you can have multiple apps accessible all on one page, so if you only need 2 loop mashers you only use 2 columns leaving the rest of the page free for other apps, rather than having say 8 loop mashers and ignoring 6 of them and paging to another apps for another function that you may only need one column for.

personally I like the idea as this is similar to a set up I had using the old 7up's 'clip launcher' to have multiple controls on one page that all related to one track in live.

@bilinsky
Molar hasn't implemented autoconf, however, it can still participate, you just need to manually register the app for example in monoroute.

File->AddOSCApp

Make sure OSC Dest port and prefix is unique. OSC Listen Port is shared between all apps and defaults to 8080.

As far as "autofocus" and Molar. This actually cannot work. Because Molar is written in C, it cannot share both udp ports with M4L apps which is what autofocus requires. Same with 7up. So with molar and 7up and external MAX apps, autoconfig is the solution.

I put the autofocus patch before molar on the same track, and I could switch with correct led feedback from the monome, but no input on m4l devices. So I guess the problem was the "shared" listen port between C and m4l.

I tried monoroute and autoconfig yesterday, but I really miss the way pages handles the session view in ableton live. I've not been here so much lately, maybe I've missed out on a similar app, or it's time for me to implement one in m4l :)

@blinksky
>So I guess the problem was the "shared" listen port between C and m4l.
Yes, this is why autofocus will not work with Molar. Molar cannot use the same port.

If you want to use autoconf, you need to turn off autofocus in apps that are using it. For example stretta apps. loop-party is creating autoconf versions of these, to be posted soon.

It would be great if Pages supported autoconf. Seems like it would really make configuration easier for pages users.

The new version of Monoroute that is in private beta now supports multiple monomes and multiple layouts. Doesn't have a session view like pages though.

@bilinsky
i am not sure how pages handles the session view, but this might be what you want
http://post.monome.org/comments.php?DiscussionID=7208


@anyone
i wrestled with implementing autofocus for much longer than i needed to because M4L wasn't converting "---" into a number when i went to edit the patch... is that normal? sprintf would throw an exception saying it couldnt convert --- into a digit...which makes sense, because it was being given "---" and NOT the unique number.

@stretta
thanks for this. good stuff.

@griotspeak
Looks nice! I will look into it and see if I can add arm and solo as well (or maybe you plan to?).

well, i have a bcf ... so i really wasnt trying.

where does that even fit in pages?

how is 'plugin' supposed to work? i can't tell if i broke it.

should clicking the bar and making the blue hand show change focus automatically?

@griotspeak
Your patch works correctly except that led feedback is broken. It sends without the num prefix: /Clipnome/led 2 6 0

i fixed that...i believe. my first update with autofocus did have that problem though.