Thanks for the detailed responses & great advice. I've been able(for the most part) to find analogous structures to the things I'm missing from the traditional syntax's, I've been reading, trolling, reverse-engineering, plagiarizing, etc, like crazy. As you correctly state, the resources are abundant. The problem is me, I feel as though I'm moving at a snail's pace. I am amassing my toolkit, making elaborate notes on my favorite objects & what problems they solve best, as well as checking out the “related” objects in the help, etc.
Since you asked, here's a small example. My goal at the outset, which I think is modest, is to use Max for Live to enable me to design a proper arduino-based foot controller for live clip-based (as opposed to the looper device) looping. By proper, I mean Live API event-driven feedback to LED's on the pedal board, including the blinking status of fired/cued clips . The looper is 4 Tracks x 4 Scenes (for now) w/ 4 track footswitches & four scene footswitches. Basic. I'd considered trying to learn some python & do this using the framework classes, etc., but I'm thinking (hopefully correctly) that the time invested in learning Max will pay off down the road as my ambitions (& skill level) increase, and allow me to do things beyond the scope of python/framework/remote MIDI scripts, etc.
Until now, I've been duct taping everything together with a combination of Bidule, Autohotkey, Clyph-X (all brilliant tools, btw…), but I'm seeking a more integrated (and hopefully bulletproof) approach.
Consider the following subpatcher, which is one small module of (of many) in my device. Although this is a Max for Live device, I'm posting about it in this subforum, since it's more about Max “zen” than Live, since I'm not asking for help w/ the device(it does actually work…), as much as a sanity check on my approach. To me it seems heavy-handed & clunky, and lacks the minimalistic elegance that always impresses me in well written code.
The second input is a metro-based “clock”, essentially an 0 & 127 alternating on 1/8 notes.
Any data entering the subpatcher does two things: Fires all the if-then groups, resulting in an output of four consecutive cc's, for LED control. Because only one Track has been selected ($1), the other three cc commands will be 0, turning off the previously selected LED. A signal from the “LED Clock” is then injected (or not, if the switch is activated on an exact quantize boundary & the clipslot never flashes…) into the MIDI datasteam of the active track's LED, which is then disconnected when the router is cleared by the expected change of TriggeredStatus from 1 to 0 when the clip starts actually playing/recording.
Yeah, it's pretty basic, and there are potential unhandled exceptions (accidentally stepping on two switches, etc.)and I know the proper way to do this is with the arduino handling the flashing logic, and Max simply providing a third cc value for flashing, w/o the clock hack. But at the moment, my “footswitch” is a TouchOSC iPad mockup, and besides, I guess I wanted to see if I could pull it off.
The thing is that I could do this without using “IF” objects (which seems almost to be frowned upon among the Max elite…), but it would require more objects. From the standpoint of efficiency, I have no idea how these objects run under the hood, so I'm not able to say whether one IF object beats a Change, Select, two Messages & a Trigger ( I just made that up, not saying that's the alternative, but you get the idea)
So bigger picture ( parent patch, design objectives, etc,) aside, is this approach reasonable? Heavy-handed & clumsy?
I do appreciate any feedback. Thanks again, sorry for the length.
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
Mar 26, 2013 at 7:22pm #242317