![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Launchpad some more
Dec. 21st, 2009 12:45 amI've got the Piemaker working a lot better now.
ChucK (I'm going to stop using the capital K) is a weird little language. With some more development, it could be beautiful. The way it works is, you start up a Chuck VM, and then add scripts to it, which can broadcast events to each other / the outside world.
Surprisingly, it has no way to talk to pipes, even stdin or stdout (well, it has stdout, but without stdin it's not too useful). So I did what I should have done originally and used OSC, which is like MIDI but newer and better designed and simpler.
So, Piemaker works like this: you start it on a port (like 8000). It kicks off a Chuck script that waits for the Piemaker to send an OSC message (sending OSC from Ruby is easy) and then sends a MIDI message containing the same data to the Launchpad. I'll be able to get input the same way, receive events from the Launchpad and shoot them over OSC back to the Piemaker.
This morning I was trying to do this with a separate Chuck process for each message, which rapidly turned into a fork bomb when I tried to animate something (see, this morning, the only way I knew to get data into Chuck was with command line args).
So now I've the the boring part: writing an API to wrap their low-level Launchpad protocol. Already I can set the color of buttons and even bulk-load the entire screen in just a few messages. Next is double-buffering (which the Launchpad actually supports on the device) and then some kind of animation, then input, then Connect 4.
ChucK (I'm going to stop using the capital K) is a weird little language. With some more development, it could be beautiful. The way it works is, you start up a Chuck VM, and then add scripts to it, which can broadcast events to each other / the outside world.
Surprisingly, it has no way to talk to pipes, even stdin or stdout (well, it has stdout, but without stdin it's not too useful). So I did what I should have done originally and used OSC, which is like MIDI but newer and better designed and simpler.
So, Piemaker works like this: you start it on a port (like 8000). It kicks off a Chuck script that waits for the Piemaker to send an OSC message (sending OSC from Ruby is easy) and then sends a MIDI message containing the same data to the Launchpad. I'll be able to get input the same way, receive events from the Launchpad and shoot them over OSC back to the Piemaker.
This morning I was trying to do this with a separate Chuck process for each message, which rapidly turned into a fork bomb when I tried to animate something (see, this morning, the only way I knew to get data into Chuck was with command line args).
So now I've the the boring part: writing an API to wrap their low-level Launchpad protocol. Already I can set the color of buttons and even bulk-load the entire screen in just a few messages. Next is double-buffering (which the Launchpad actually supports on the device) and then some kind of animation, then input, then Connect 4.
