Push 3 Live API Problems
Update: I sent a report to Ableton and they confirmed it is a bug.
What kind of unstabe behavior - apart from not getting control over the buttons - you experience with Push 3?
Is it about running Max for Live devices on the Push 3 standalone in general, only calls to the Live API or even the entire performance / behavior of Live on Push 3 standalone?
Or do you even got problems with a "normal" Push 3, while Live is running on a desktop machine?
All of the above!
Too many little bugs to list here, but the most problematic are the hardware freezes and crashes, which happen fairly frequently in my short experience with it. Max for Live device stability is definitely an issue too, although some things that I expected not to work (like sending MIDI between devices via udp send and receive) actually functions. Many of my commercial devices ship with custom Push grid layouts, and I'm having mixed luck getting those to work on Push 3 thus far. I'm fairly confident most of these things will be resolved in future firmware updates.
Despite bugs, is the Push 2 API supposed to be similar for Push 3?
From what I can see, it appears that all Push 3 button and encoder names are the same as Push 2.
I use my Push 2 with only Max/MSP and route MIDI message towards custom MIDI ports. I do this without Live and I ignore the "User Mode" button. I basically detect input from the Push 2 and then send messages to other software.
Do you know, even theoretically, if the same should apply to the Push 3? I'm debating getting it.
Theoretically, I'd say yes.
If you post a test patch, I'm happy to try and run it on my Push 3 unit.
Hi Ian glad to see you are diving into push also. Are you using in it in Standalone mode?
I am actually in the same jam, taking over buttons and reassigning them and it feels very random when the max4live device fails to work. Everything is fine when tethered, but in standalone mode i get problems with the observer take over - but not always.
I've made manual initialization buttons, resets, take over controls in case its something to do with [live.thisdevice] or live.path or live.object, but they also fail to consistently work.
One of the first devices I slapped together I actually have a delayed bang to initialize it since it wouldnt do it on set load or device add - so this made me think I need to try manual init buttons but with this particular device its just not behaving well at all.
I wonder if its something super weird like - send receive failing sometimes, or encapsulated parts of patches or wrong placements of deferlow for the standalone version.
I have only carried out some basic standalone tests of my devices and was surprised by how much ran as expected. But, until they fix the observing buttons issue, I can't really move forward with officially porting things to Push 3. I am hoping the update comes soon...
I've made some more devices and did some observing and it seems like live.observer on the control surface (push 3) can fail sometimes (after initial boot and first time adding the device) but observing live related functionality seems to consistently work.
...a lot about the standalone and m4l still feels pretty beta, I got to say.
also, the standalone crashed on me will playing my first gig with it, actually we had an audience of exactly one person so nevermind.
anyway. I also didn't get any observing of buttons done via the API, the only thing that works is 'call grab midi' --- for now, you can get the push's buttons like that.
and it does work! in standalone - mode.
--- UPDATE -- but not reliable at all.
patch based on Ian's work attached.
cheers
R
Thanks for your patch @RBRT!
I am able to receive the button and dial values via "call grab midi", but I wonder why MIDI notes from the grid are excluded?
And for me, the grab midi method works on standalone mode. I just updated to firmware 1.1.13.
I've been playing around over the last week porting a m4l device that takes control of the entire matrix and some of the buttons. One thing I did notice is that you have to grab_control before the live.observer (or callback in javascript) will report. This is NOT the case with Push2. Unfortunately, that doesn't work well for me, so I had to resort to the 'grab_midi' call and filtering to observe buttons without grabbing them first
@ Evan, this is fixed... but in the current beta that's been and still is in beta for several months.
Yeah I saw that - I an coming across a lot more things that are breaking some of my other Push centric devices that depend on the control surfaces API to function. Will be opening another thread about that, as it seems like it might be intentional.
ive now played a few gigs with a couple of devices that take over control and observe changes and i have 0 issues.
i use push in standalone mode exclusively so i built my devices with that in mind.
i completely threw out the control surface look up script since there is only one control surface
i also actually use pipe to delay some data and i believe some delays on bangs too because i think there's something up with the way code is loaded on the standalone.
Stuff just doesn't init fast enough. I think ive written to support about this already but its been lost i think.
I am revisiting the devices again after the latest update (11.3.20 - and whatever was the standalone/controller/live os versioning for this) and building some new devices.
Will familiarize myself again and post here and bug it. But i got a feeling that we are stuck with just delaying data so the devices function properly.
in controller mode devices function completely differently obviously.
@EVAN,
Were you ever able to find documentation explaining the changes that are relevent to Push 3 takeover? I'm hoping to update some legacy devices too and am not sure where to start.
@IAN,
Do you have any recommendations for where to start on this learning curve? You've obviously made it through the learning journey already, with Polymath being a bright and shining example of success in this area.
Thank you in advance for any guidance!
Neil
@ODDEO - The issue that launched this thread (not being able to observe Push 3 buttons) has been resolved in the current Push firmware.
The next hurdle I encountered is using dynamic port assignments for UDP Send and Receive. As of now, it crashes Push 3 Standalone. My SEEDS collection relies on communicating MIDI clock and raw data using UDP.
The hacky solution I settled on was to make numerous copies of UDP Send and Receive with hardwired port assignments on device load. It is not efficient code, but it works and I can now run everything on Push 3 Standalone.
I have reported this issue months ago to Cycling/Ableton, but I know they have their hands full with the Live 12 roll out and subsequent updates/bug fixes.
Hi, has there been any progress on this. Finding that udpsend is working with latest P3 standalone firmware fine, but any attempt to udpreceive causes a situation where reboot it needed.
@Lee - Just wrote Ableton again about the issue. There is no fix at the moment as far as I know.
We are working on a fix for the `udpreceive` issue. Not sure when this will land in a Push 3 build, stay tuned!
just revisiting my earlier devices that were 100% solid. None of them work now.
Did something change regarding live.observer or the control surface in the last live 11 version for P3SA (live 11.3.2 and push v 1.2 firmware 1.4) ?
.. i remember there was a change at this point with P3SA: max for live is not loaded at startup and is loaded if a device is added or a live set contains it.
This could be a reason why some observer devices fail..maybe? I've tried loading a random m4l device first t and then adding a button take over device but thats also not working.
** nope no changes here.
I see that the -DontLoadMaxForLiveAtStartup flag in Push's options text is new. After removing it, my devices still dont grab controls. I actually even changed the Max version back to the one that was with Live 11.3.11 (i have a backup) but no dice.
I guess i could roll back to that version of Live for the standalone but thats kinda extreme. Strange that changing to old Max version didnt have any effect. hmmmm
hey problem solved here!
looks like something got fixed and the Push standalone's "control surfaces" id is now 1. Was 0 before. Since i skip the whole push3 lookup id and hardcode the surface number, my devices stopped working. Maybe its not necessary to hardcode the id to get good performance now, but it def was a huge problem before.
wonder why it was changed.
If the ControlSurfaceID abstraction is now super snappy then theres probably no reason to hardcode the id for push3stand alone only devices - especially if the id will change randomly in some update again.
I'm still having problems with Max4Live and the push3. I'm able to grab controls and initiate observers. They all work without a problem. When the device gets deleted I release all controls. That part works, manually deleting the device releases the Button_Matrix.
I'm running into problems when loading a new live set with the same device. The device is able to execute grab_control commands. The problem occurs when you try to initiate the observer. It reports a "bang", but doesn't register any changes to the control. When push is in this state, I can try switching the push off and on again, but then push won't see the running live instance. Rebooting Live fixes the problem and I can load the Live set and the device works again. It feels like a bug on Ableton's end, but maybe I'm doing something wrong. Anybody else encountered this bug?