Code Log

I’ve been wanting to make a sound-generating game for a while, I’m always inspired when I play games like Rez, Every Extend Extra, and ElectroPlankton. However, what I don’t want to do is make a Rez clone where there are already constructed songs that you just trigger new layers in and I don’t want to do a beat matching game because Harmonix already has that market cornered. So I’ve started working on a little sound-generating game/toy. It plays like a really simple shmup, but the mechanics are really just an interface to building up sound over time. You can fly a little ship around with some amoebas and they will just harmlessly bounce off of your ship. If you shoot an amoeba it will add a note to a music loop that plays throughout. This loop starts out with nothing in it, so the beginning of the game is silent. The color of each amoeba directly maps to the pitch and velocity of the note that they will create, but it is a narrow range so it is not immediately obvious what note you will get.

Play it.

There are still a few things that I want to add, both visual and aural, but the basic idea is there. I will probably also be writing my own Sequencer implementation because the one that comes with Java hiccups sometimes and doesn’t do track muting properly. Or, rather, it probably does track muting exactly how the author of the implementation intended, but that intent is not one that I agree with. If Processing didn’t make it so easy to create visuals I think I would have totally given up on audio/midi in Java by now.

Decided to take a little break from developing Minim and make something with it instead. I made a synth that uses the positions of particles in a simulation to change the frequency and pan position of several oscillators. It comes in two flavors: mono and poly.

Well, I accomplished one of my two goals and finished writing the Minim manual. Hopefully it is clear and will be a useful reference for people. I wasn’t able to push out a new release because of holiday parties, distractions from other projects, and so forth.

Some good news for Minim development, however, is that I finally got around to setting up my PC to dual boot Ubuntu and Windows XP, so I’ll be developing primarily in Linux and then testing things back in Windows. I have already discovered that Linux is pretty tetchy, has latency issues, and is just generally not as great for audio. I have an idea for how to solve the latency issue, but it will require pretty significant recoding. I may just release a new version of Minim within the next month to make some small API changes available and then push dealing with the latency issue into the following release. I’m going to try to be better about semi-regular releases so that when people send me bugs I deal with them quickly and then release a new version.

Man, been a long time. I used to be annoyed by people who release tools like Minim and then leave them undeveloped for long stretches of time with nary a peep about how things are going or when they plan to release a new version. I was even more annoyed when documentation was missing or incomplete. No longer! I have become one of those people! It makes me a bit sad but at the same time a full-time job plus a social life really eats up most of the hours in a day.

Here is a promise I hope to keep:

Before the year is out I will finish the Minim Manual and release a new version of the library, incorporating a couple fixes people have sent me and also adding a little bit of new functionality.

Finished up the second gameplay prototype for Primaries. Play it here:

http://code.compartmental.net/primaries/proto2/

I like it. It hurts my head a little to play it, but I enjoy that in a puzzle game. However, I don’t think it’d be very fun to play while drunk. I also don’t think it’d be very fun to watch someone play it, either while they were drunk and you were sober, or they were sober and you were drunk, or you were both drunk. It’s also not very conducive to a five minute gameplay session, even if you already know how to play. Admittedly, the keyboard controls complicate things a bit and it would be a little easier with a 360 controller, but even still.

The verdict?

KISS!

I think I’m going to reduce it to a single grid and do Puzzle Quest style swapping. Color mixing will still be involved, since you could swap two tiles and match two colors with that swap, and I think that will be a nice twist. But it probably also means I will have to come up with a clever way to initialize the board so that you don’t get a bajillion matches right off the bat.

But now, Bioshock calls!

So I started working on a way to draw the grids for Primaries. It involves using a particle system. Here’s a prototype that does not allow me to do what I need to, but is fun to play with:

http://code.compartmental.net/primaries/particle_spring_grid/

I’ve started working on a game for Gamma 256. It’s an idea that literally came to me at about 2am in the morning. I sent a brief design doc to Fish and Heather and incorporated some of their feedback into the design. I’ve just finished the first gameplay prototype. The basic idea is to match three or more colored tiles in a row. The catch is that there are three grids, each corresponding to a primary color (RGB), and the tile and grid have to be the same color for a match to work. In other words, red tiles are matched in the red grid and so forth. To move tiles around you position selection boxes in each of the three grids and the swap tiles between them either clockwise or counter-clockwise. If a swap results in a match in two grids, then a tile that is the mixture of the two, like red and blue making magenta, drops in the top of one of the two grids. Since magenta is red and blue mixed, magenta tiles can be matched in the red and blue grids. Anyway, describing this with words is silly, just go try out the prototype:

http://code.compartmental.net/primaries/proto1

I’m very happy to announce the release of Minim 1.1!

If you’ve been using Minim 1.0, there are some important changes you need to be aware of:

• AudioFileIn is now AudioPlayer.
• AudioClip is now AudioSnippet.
• To get an AudioSnippet you use Minim.loadSnippet(String).
• AudioFileOut is now AudioRecorder.
• To get an AudioRecorder you use Minim.createRecorder(Recordable, String, boolean)
• Additionally, the methods of AudioRecorder are ever so slightly different than those of AudioFileIn.

Another major change from 1.0 is the inclusion of a bunch of Interfaces that define library functionality. Essentially what I’ve done is defined how everything in the library should behave and then written an implementation of that spec. This is why createRecorder takes Recordable as the first argument and not an AudioInput or other concrete class. The use of Interfaces shouldn’t break any of your existing code because I used the existing methods of Minim as the starting point for the Interfaces.

I fixed a host of bugs relating to mp3 playback for this release. They should behave exactly like WAV and AU files now. There are many more examples now, one for each method of each Interface that defines the functionality of Minim classes. Examples are organized by Interface, rather than by concrete class, hopefully this isn’t too confusing for people.

Please let me know if you have any problems or questions!

I was recently motivated to revisit Minim when I got a note about it from Casey Reas, one of the initiators of Processing. Man oh man did I revisit it. The implementation details went through two waves of refactoring, but I think I’ve gotten it to a place that I’m happy with. I’m only incrementing the version number by .1 because I haven’t added any new features. I just changed the names of a couple public classes, made all the implementation details package private so that they don’t clog up the Javadoc, and fixed some bugs relating to mp3 playback.

Additionally, the API is now defined by several interfaces, which opens up the possibility for people to write their own implementation of a file reader, for example. I’m not sure why anybody would actually go to the trouble of doing that, but the possibility exists, nonetheless. Defining the API in terms of interfaces helped me a great deal with standardizing the methods of different public classes that can do similiar things (like applying effects to an audio stream).

I hope to do a release this coming weekend, but it depends on how quickly I can whip the examples into shape. But do keep an eye out!

Last night I was thinking about live coding and also about how Java has reflection built into it. So, even though there is a forum topic about live coding with Processing, I decided to code up a simple sketch that evaluates a single line of Processing code and continually draws the result. There are drawbacks, of course, namely that you can’t specify fills or stroke colors and you can’t change the background color. However, in the next iteration I plan to ditch the textfield being used and instead use a textbox that will be evaluated in draw without the user having to press the enter key. Probably I should check out the tools talked about in the forum topic, but I like the idea of having a sketch that is itself an interpreter, rather than using a more generic tool for evaluating Java. Then again, I may discover that building something even marginally useful is more complicated than I care to implement, at which point I will probably turn to an existing tool. In the meantime, please enjoy:

Live Code v01