Page 6 of 7
Re: Push2DisplayProcess
Posted: Fri Jun 09, 2017 10:24 pm
by Pinner
I've been experimenting with a crude workaround that seems to maintain screen-independent push2 functionality and disables the screen and push2displayprocess.
I'm on an (elderly) macbook:
- Find the folder the holds push2displayprocess (Live->show package contents->Contents->Push2)
- Open Live and turn on Push2
- quit push2displayprocess in activity monitor
-quickly, before the process restarts, move push2displayprocess from the push2 folder into contents folder (or anywhere else would probably work)
I'm just starting to try this so I'm unsure how stable it is. Saving seems to work but when opening a new set the steps need to be repeated.
I'm curious if this works well for others and what problems arise.
Thanks
Re: Push2DisplayProcess
Posted: Sun Jun 11, 2017 8:53 am
by Stromkraft
Pinner wrote:
- Find the folder the holds push2displayprocess (Live->show package contents->Contents->Push2)
- Open Live and turn on Push2
- quit push2displayprocess in activity monitor
-quickly, before the process restarts, move push2displayprocess from the push2 folder into contents folder (or anywhere else would probably work)
I'm just starting to try this so I'm unsure how stable it is. Saving seems to work but when opening a new set the steps need to be repeated.
I'm curious if this works well for others and what problems arise.
And you mean this gives you a fully functioning graphical display on the Push without a running
Push2DisplayProcess?
Re: Push2DisplayProcess
Posted: Sun Jun 11, 2017 10:58 am
by Pinner
No the display is completely disabled. Though the encoders above the screen still control whichever encoder mode you are in (ie: control the faders while in mix mode). So it abolishes some functionality such as push-screen dependent tasks like browsing and trimming samples.
But the load that is taken off my CPU is huge - my fans never come on anymore. The reduction in strain on my computer almost seems disproportional to the 20-25% (over 4-cores) that the push2displayprocess takes up.
Turning off push2displayprocess has been fairly stable. Once a Mail app alert caused Live to freeze, but I was still able to save my work. I'll probably use this technique when needed until I can save for a new macbook.
Re: Push2DisplayProcess
Posted: Sun Jun 11, 2017 1:50 pm
by [jur]
Pinner wrote:No the display is completely disabled. Though the encoders above the screen still control whichever encoder mode you are in (ie: control the faders while in mix mode). So it abolishes some functionality such as push-screen dependent tasks like browsing and trimming samples.
But the load that is taken off my CPU is huge - my fans never come on anymore. The reduction in strain on my computer almost seems disproportional to the 20-25% (over 4-cores) that the push2displayprocess takes up.
Turning off push2displayprocess has been fairly stable. Once a Mail app alert caused Live to freeze, but I was still able to save my work. I'll probably use this technique when needed until I can save for a new macbook.
IMHO you'd better sell your Push2 and go for a 2nd hand Push1.
Re: Push2DisplayProcess
Posted: Mon Jun 12, 2017 5:15 pm
by hoffman2k
[jur] wrote:Pinner wrote:No the display is completely disabled. Though the encoders above the screen still control whichever encoder mode you are in (ie: control the faders while in mix mode). So it abolishes some functionality such as push-screen dependent tasks like browsing and trimming samples.
But the load that is taken off my CPU is huge - my fans never come on anymore. The reduction in strain on my computer almost seems disproportional to the 20-25% (over 4-cores) that the push2displayprocess takes up.
Turning off push2displayprocess has been fairly stable. Once a Mail app alert caused Live to freeze, but I was still able to save my work. I'll probably use this technique when needed until I can save for a new macbook.
IMHO you'd better sell your Push2 and go for a 2nd hand Push1.
Or perhaps wait a few months till the custom user modes take over in popularity from the main Live Mode or further optimisations to the Push2Display process happen. Its Ableton's method of rendering that takes up the CPU, not the actual act of rendering. This can be verified by the growing number of solutions to control the display. A Raspberry Pi is more than powerful enough to run graphics on the screen.
Pretty much everything required to do something with the display has been documented and made available by Ableton.
http://cdm.link/2017/06/ableton-now-mad ... rk-push-2/
The stumbling blocks for making extra modes with MFL have been the MIDI Filtering that Live does and one huge oversight when it comes to the User Mode. You can't take over the display in User Mode because its still connected to the Push2Display process.
@Pinner, Do you use MFL? I may have another method for killing the display. The push2display process will still run in the background but at about 1-2% CPU. And the display will just be blank.
Re: Push2DisplayProcess
Posted: Mon Jun 12, 2017 8:12 pm
by Pinner
hoffman2k wrote:
@Pinner, Do you use MFL? I may have another method for killing the display. The push2display process will still run in the background but at about 1-2% CPU. And the display will just be blank.
Yes. I'd be interested to see your method. Thanks
Re: Push2DisplayProcess
Posted: Mon Jun 12, 2017 8:44 pm
by hoffman2k
Pinner wrote:hoffman2k wrote:
@Pinner, Do you use MFL? I may have another method for killing the display. The push2display process will still run in the background but at about 1-2% CPU. And the display will just be blank.
Yes. I'd be interested to see your method. Thanks
Alright, quick disclaimer then. Use this at your own risk. Though it isn't voodoo, its just sending a message to the commandline to kill the process.
It'll only work in OSX and uses imp.push from David Butler and Shell from Orcutt/Bernstein.
I added a mappable button for it and you can control it from Push, i mean.. if you can find it
http://covops.dreamhosters.com/uploads/ ... r.amxd.zip
Re: Push2DisplayProcess
Posted: Tue Jun 13, 2017 10:00 pm
by Pinner
hoffman2k wrote:
Alright, quick disclaimer then. Use this at your own risk. Though it isn't voodoo, its just sending a message to the commandline to kill the process.
It'll only work in OSX and uses imp.push from David Butler and Shell from Orcutt/Bernstein.
I added a mappable button for it and you can control it from Push, i mean.. if you can find it
http://covops.dreamhosters.com/uploads/ ... r.amxd.zip
Thanks for that! I also automated what I mentioned above into a automator + applescript that is triggered from a keystroke. Works fine!
Re: Push2DisplayProcess
Posted: Fri Jun 16, 2017 9:38 pm
by JAMM
So a lot off people seems to have a problem with the display and come up with solutions and workarounds.
it's about time ableton should work something out officially in the direction...
Re: Push2DisplayProcess
Posted: Mon Sep 18, 2017 2:09 pm
by JAMM
Alright, quick disclaimer then. Use this at your own risk. Though it isn't voodoo, its just sending a message to the commandline to kill the process.
It'll only work in OSX and uses imp.push from David Butler and Shell from Orcutt/Bernstein.
I added a mappable button for it and you can control it from Push, i mean.. if you can find it
http://covops.dreamhosters.com/uploads/ ... r.amxd.zip
Hi Hofmann2k,
I tried this MFL decvice but it turns off the display off for only a few seconds.
I throw it on a empty midi track....am i doing something wrong?
JAMM
Re: Push2DisplayProcess
Posted: Mon Sep 18, 2017 2:14 pm
by JAMM
For the rest....i noticed in the OSX activity monitor that the push mixer mode takes the most CPU.
The 'device mode' on the push consumes 10 to 15% less CPU......around 28 % on my MBP.
Re: Push2DisplayProcess
Posted: Mon Sep 18, 2017 5:49 pm
by hoffman2k
JAMM wrote:Alright, quick disclaimer then. Use this at your own risk. Though it isn't voodoo, its just sending a message to the commandline to kill the process.
It'll only work in OSX and uses imp.push from David Butler and Shell from Orcutt/Bernstein.
I added a mappable button for it and you can control it from Push, i mean.. if you can find it
http://covops.dreamhosters.com/uploads/ ... r.amxd.zip
Hi Hofmann2k,
I tried this MFL decvice but it turns off the display off for only a few seconds.
I throw it on a empty midi track....am i doing something wrong?
JAMM
It seems the process now kills my killing process. Not much I can do I'm afraid. It reboots while imp.push is connected.
There's a User Mode, there's documentation on how to control the screen, but somehow we're not technically allowed to control the User Mode screen while switching to Live mode and back. It is possible, but this current method was already messy if stability is key.
Re: Push2DisplayProcess
Posted: Mon Sep 18, 2017 8:47 pm
by JAMM
okay hoffman, thanks for the MFL effort and info.
Shame that it isn,t allowed because i don't use the screen on live gigs.
Re: Push2DisplayProcess
Posted: Sun Sep 24, 2017 3:17 pm
by hoffman2k
When trying to debug this, I can't reproduce it anymore. Now it just stays off, no matter what I do. I think I accidentally moved the first encoder when this device was still selected, which would turn the screen back on. Any chance the same happened with you?
Otherwise, check the Max Window (right-click on MFL device title). The only thing it should show is the imp.push credits.
Its not a matter of not being allowed to also use user mode, but more of an oversight in regards to how the render software works. They just need to add a "switch off screen" function instead of the "User Mode Active" rendering function when you press the User Mode button.
Re: Push2DisplayProcess
Posted: Mon Sep 25, 2017 2:06 pm
by JAMM
Hi Hoffman2k,
Whatever i try it's keeps switching the screen back on...
Also when using the mouse to put the screen off and not the push encoder.