Updates for Push 3?

[FigBug]

Is the Push 3 backwards compatible with Push 2.

[tastez]

seconded

[mpancia]

Hi there, is there any update on this? There seems to be some change in the Push 3 commands to set pad sensitivies that breaks from the Push 2. This makes extensions like DrivenByMoss difficult to use, as the pads are not sensitive enough to be usable by default.

[jaekong]

For people who are curious - at least some things are backwards compatible. I have tested LED palette get/set sysex commands and they work the same way.

+ Also Touchstrip config / LED sysex commands work the same.

[jaekong]

Update: I have tested the USB display interface, and it works the same as well.

Demo

[ofou]

Update: I have tested the USB display interface, and it works the same as well.

Demo

Can you share the code?

[jaekong]

Can you share the code?

https://github.com/jaekong/pushDisplayTest

It's quite messy and quite slow, but I think it's a good enough of PoC.
Left side of the max patcher is for LED matrix, and the right side is for LCD display.

[jonasfehr]

@jaekong thanks for sharing... unfortunately i can't get it to work. Part of it is, that i just have Max 8 and can't use the v8 Object. Can you confirm it's a Push 3 you are using... i am working on an Openframeworks app where I try the same, but can't get anything on the display.

[jaekong]

@jaekong thanks for sharing... unfortunately i can't get it to work. Part of it is, that i just have Max 8 and can't use the v8 Object. Can you confirm it's a Push 3 you are using... i am working on an Openframeworks app where I try the same, but can't get anything on the display.

Oh dang. I think you'd be able to replace v8 with js or some Max objects. It's just some code that converts RGB values from the matrix to the format that Push 3 expects (as documented in this repository).

And yes, I am using Push 3 Standalone.

I have tried another implementation some months ago. It's a display server written in Swift that runs in the background of Push 3 (or on a host computer connected to Push 3) and fetches jitter matrix data sent from an M4L patcher through jit.net.send. The file Frame.swift has the code for encoding image data to Push 3's format, and Push.swift is for actually sending the data - although most of the USB connection stuffs are abstracted away in a separate library.

I recommend just looking through the code rather than trying to actually run this (on a Push 3 Standalone at least), because of glibc/glibcxx ABI compatibility issues. (Push 3 has quite an old version compared to most linux distros) Trying to untangle the whole dynamic library mess was very frustrating, although I eventually succeeded running it, it was quite convoluted - I assume it would be the same case for OpenFrameworks, but at least you would be able to compile the code on older distros.

You can use the Swift version on Push 3's Controller Mode as well, running the code on the host computer. I've only tested it on a Mac though.

Also, in any case, you'll need to claim the USB endpoint before trying to control the display. On the host computer (or on the Push 3), there will be a process called Push3 if you are running Live (or in Standalone's case, after it boots up.) This process is for sending the display data from Live to Push, and it would already have the control over the endpoint. You'll need to terminate this process before hijacking the display. It's been a few months since I tried this so I don't remember if the Max/NodeJS version automatically did this or not (I don't think it did) but I am certain that Swift version does not do that.

[ofou]

Can you share the code?

https://github.com/jaekong/pushDisplayTest

It's quite messy and quite slow, but I think it's a good enough of PoC. Left side of the max patcher is for LED matrix, and the right side is for LCD display.

Awesome, thanks for sharing! BTW, I ended up vibe hacking Push 3 two days ago, and I managed to visualize some videos/gifs on the screen up to 60fps! If you want to check my WIP is here, I added some utils scripts to test as well ofou/push3-python@31c2b18

My plan is to add full support for Push 3 interface, including MPE, screen and so on, but still trying to figure out the MIDI ports, to be honest, I don't know much about this yet, but it was so cool to see some videos on the screen working!!

IMG_4167.MOV

IMG_4178.MOV

[jaekong]

@ofou Cool! It seems like your version runs video directly via FFMpeg. I'm assuming the bottleneck in my Max version is probably from inefficient matrix handling. My Swift version did fare better, but still it had to decode matrix data sent via TCP from Max so it wasn't too great. Since your version seems to run much smoother, if I pick this project up again I'd probably start from just displaying video file first as well.

[ofou]

@ofou Cool! It seems like your version runs video directly via FFMpeg. I'm assuming the bottleneck in my Max version is probably from inefficient matrix handling. My Swift version did fare better, but still it had to decode matrix data sent via TCP from Max so it wasn't too great. Since your version seems to run much smoother, if I pick this project up again I'd probably start from just displaying video file first as well.

I was hitting the same perf bottleneck, but with ffmpeg handling the conversion, it runs very smoothly. This opens up a lot of possibilities. I'd love to create alternative interfaces for learning Push. I was experimenting with a piano layout for visualizing the keys. It's very cool.

Btw, if you have some time, it'd be awesome if you can double-check my attempt to create a push2-map.json port for Push 3. I was battling with some rotary encoders; this weekend I'll be figuring it out.