Open brunchboy opened 8 years ago
I am currently using your library together with processing. Maybe I'll find the time to create a plugin but at the moment it's a bit a mess because I have to convert a PGraphics
to the BufferedImage
which takes a lot of CPU time.
Yes, it is unfortunate that Processing has its own hierarchy of nonstandard graphics objects. I would be surprised if they were full-featured enough to do the kinds of bit-striping needed to support the LCD in the Push 2, the way that the standard Java BufferedImage
class does. But if you find that is the case, you might be better off creating a separate library for working with the Push from Processing.
If you do ever go forward and create a plugin that embeds Wayang, though, I would love to hear about it.
I am using your library since two years in my own visual software (processing based), but now I wanted to rewrite the whole software and also modified your library. I will release it as a processing library (Ableton Push 2 for Processing), but I did some improvements.
For example it is now possible to use multiple Ableton Push devices, nothing is static anymore (which does not have to be static). I've also implemented a hotplug listener for LibUsb to check if the device is connected or not.
Here is an example code how to use the library (this
referees to the processing sketch):
PushContext pushContext = new PushContext(this);
pushContext.open();
if(pushContext.isPushAvailable())
{
PushDevice push = pushContext.getFirstDevice();
push.open();
// just a dummy example to send one frame
push.sendFrameAsync();
push.close();
}
pushContext.close();
PushContext
is the new manager for the push devices. It handles the libusb connection and the event thread.
Here you find the source code, if you are interested. Currently the processing sketch is not used and there are no methods to send a PImage
to processing. I will add these methods later.
Maybe it would make sense to split the processing related part and the plain old java part of the library.
So today I changed the structure of the API to be more extendable for different image sources. Now the processing related part is capsuled into two decorator classes, which do not effect the java part. Now the PushContext
does not need a processing sketch as constructor parameter and is just usable in any Java application.
The processing part was a bit trickier. I am using a JAVA2D
PGraphics object as screen buffer. This buffer uses 32bit RGB color mode, so I am convert the pixels into 16bit BGR and then masking them like you did.
It looks like it might be fairly straightforward to create a Processing library that lets people draw to the Push screen, as long as I can figure out a way to have access to
usb4java
without exporting all of that mess into the Processing environment. There are hints of that in the above-linked documentation, but it is not spelled out as clearly as I would like. Starting from the Eclipse template is probably easiest, even though that would require using Eclipse…