Had not figured that out, didn't know about the Object -> New View to get into that object, that was a huge help, thanks so much.Because789 wrote: Maybe you already figured it out but if not, you have to replace "path control_surfaces $1 components 150" by "path control_surfaces $1 components 148" in the Device/Track select object (right click on the object, "Object", "New View of <none>").
@nbyte: the device entered and push_display objects both seem to be working for me in 9.0.4 beta as is.
Working on push versions of plinkonome, trails, and flin monome m4l apps. Flin is proving slightly more difficult than the other two (which have been pretty straightforward using flocked's mods to polygome), but making decent progress. Once school is out in a week or so (I teach h.s.) I plan to spend some serious time tinkering with these and others. I'll post some vids and results once they're done. (trails specifically is looking/working really well and was really easy to port, a good exercise if anyone's looking for something easy to try on their own)
I did notice in flocked's 'pushed' version of polygome that the rows sound upside-down (higher rows sound lower); this should be an quick and easy fix in max (though I've yet to do it), but fyi.
Arguably the most popular monome apps are the mlr family, of which the most recent mlrv v2.3 stands head and shoulders over the rest imo. (The mlr_2.27_maxforlive version crashes Live 9 every time I try to load it, so mod'ing this doen't seem to be an option presently.) Unfortunately it has been made clear there is no intention to include push in the devices that mlrv 2.3 can use, despite the apc40 and launchpad both being in that list. I've been trying to figure out the most efficient way to go about getting the push involved given that mlrv2 runs in regular max and can send audio to a track input in Live. The max logic is a little more complicated/stream-lined than some of the simpler apps, so simply having a m4l device that re-organizes and sends list outputs from the push dev kit objects to receives added to mlrv might require more significant alterations to the mlrv structure than I'd prefer having to do (this is similar to what I'm encountering with flin but even more complicated at first glance in mlrv). I'm wondering if it would be easier to take the push dev kit output and format it properly to send with a udpsend object so as to 'fool' mlrv into thinking an actual monome grid is talking to it? Perhaps something like osculator could make this even easier?
I'm really just brainstorming at this point, thought I'd see if anyone had any thoughts on this before investing too much time on what would be a pretty indirect workaround or fairly involved reworking of mlrv itself. thoughts/ideas?