r_constanzo wrote:
Some questions:
If you make a M4L Instrument, is there a way to override the default keyboard LED feedback?
If so, is it possible to have an instrument that also takes audio input?

Yes, there is, you'll be diving head first into the deep end of the control surface API, or using User mode.
Only Audio Effects can take audio input. Instruments, take MIDI input. No way around this as far as I know.

r_constanzo wrote:
Depending on the answer(s) to the above:
If you have a M4L Audio Effect, can you access the [notein] info from the main 8x8 Push grid?
Can you access aftertouch?

You cannot access MIDI input in an audio effect, but you CAN observe the button grid through the API to get control messages from the Push into any M4L device.
I believe you can also get aftertouch, but I've never had a need for it, so I can't say with 100% certainty.

P.S. Hi Rodrigo! I've seen you plenty of times on the cycling forums, and even made a M4L device based on Karma! Nice to see you around here as well.

dataf1ow wrote:
You cannot access MIDI input in an audio effect, but you CAN observe the button grid through the API to get control messages from the Push into any M4L device.
I believe you can also get aftertouch, but I've never had a need for it, so I can't say with 100% certainty.

P.S. Hi Rodrigo! I've seen you plenty of times on the cycling forums, and even made a M4L device based on Karma! Nice to see you around here as well.

Ah that's good to know.

So it looks like I want to make an Audio Effect, and then use the API to get grid messages (and presumably be able to control LEDs), (without going into User mode?)

Yep, I'd stay away from User mode. The convenient thing about the Push/2 is that you can selectively 'grab' and 'release' components of the control surface, and leave all other behavior intact.

You're free to take a look at any of my devices to see how I've done it, but the older ones can be quite a mess, and I've moved to javascript for all of my LED handling/Live API stuff. If you're comfortable with JS I would go that route. Using traditional max patches to do the LED stuff can get messy, depending on what you want to do.

Here's some code that shows how to get access to the Push2 control surface in M4L. It does a bit of API navigation and spits out the path and the id of the Push2 script. It prints all the objects information to the max window. You'll want to look into the controls for all of your buttons and LEDs. Specifically the button matrix, I've got an example of sending data for LEDs observing presses, and grabbing and releasing the matrix:

I've not tested/tried it yet, but that's the exactly the kind of thing that I was looking/hoping for.

For the most part my idea at the moment is to only use the 8x8 grid to control stuff, and leave the rest of the components in the control of Live, but I'll see how things go.

I've always been a bit wary of js (at least in Max) since running into an issue of LED lag a bunch of years ago with the low priority-ness of js creating a backlog of events. That being said, all the modern monome apps are built in/around js, so if it works there, I'm sure it's much easier to do.

That patch should get you started on using and controlling just the matrix.

I didn't start using js to do LED stuff until recently, but I've found it much easier to manage. Defining utility functions, and iterating through LED states/colors is way easier and cleaner in a text based environment. I have run into some serious lag issues when developing, but once the device is closed its been pretty snappy.

Actually, was playing with it a bit more and it looks like the colors are in arbitrary order.

I imagine, from you moving to js for what you're doing, that it's not as straight forward as taking a color (green for example) and just going from bright to dim to off with one value control value?

I haven't gotten too far into the LED/UI planning side of things, but I plan on doing most of the LED stuff with brightness, rather than color, although there will be color differentiation in the mix (hence the question above about brightness).

I'm away from the hardware until Monday, so I won't be much help until then with practical advice, but it looks like section 2.6.2 of that document you linked to earlier provides some insight into how colors are calculated. The MIDI values 0-127 are translated via a color palette. I do not recall if there is a rhyme or reason to the organization of colors, but I am assuming there is.