FINALLY, I’ve got a release-worthy build of my MOD/XM/S3M replayer library for Processing! PortaMod is based on a very high-quality (but bare-bones) pure Java replayer engine by Martin Cameron called IBXM. IBXM had been around for a few years, but I wanted to implement it for Processing and make it available to that lovely little sketching language that’s been so helpful to me in my effort to learn OOP.

I’ve been working on this in a couple of different ’strands’, and if you’re following my sporadically-documented, mad-scientist crap to any degree, you’ll know that they include:

• Chipdisco (a dual-deck module DJ application with MIDI control, headphone cue-mix, module-loading from URL and dual playlists) – click here for a work-in-progress
• PortaMod Player (a single-deck player with scrolling tracker-style patterndata display and various other nice features – interface similar to Chipdisco)
• PortaMod Single (a very very compact single-tune player intended for embedding on websites, particularly websites that archive modules)
• PortaMod itself – the library which will make projects like these easy for others to make. Usage can be basic, e.g. doing a soundtrack for a sketch when you want to avoid bundling a massive mp3 file, or more complex, e.g. driving a series of visual effects triggered by note-events in the music.

Anyway, just click here to get all the details.
Please discuss it or ask any questions you might have using the comments on this thread – it’s probably the easiest way to get an answer to a question and it’s good to have discourse that’s publicly visible (especially when bugtesting!).

Updates (10th December 2009):

• Fixed the transpose function so that it works only on each PortaMod instance’s channels, rather than on the static Channel (and therefore all instances globally) at the same time. The transpose function will also allow transposition for individual channels!
• loopAdjust and loopReset do just that, for specific samples/instruments, following a feature-request from goto80.  As well as the instrument number, you pass the desired loop start-point and the desired loop length as percentage values: start-point is a percentage of the entire sample size, while length is a percentage of the size that remains once the start-point has been set. To cut a long story short, mapping these to X/Y mouse values in Processing allows for crazy amounts of glitchtastic fun Oh, and loopReset resets it…either to zero, if there was no loop to begin with, or to whatever it was originally set to in the MOD. Coming soon: bidirectional (ping-pong) looping.
• Improved the still-experimental notedata override thingy. Now you can pass certain hex effects, as well as custom notes to cause specified instruments to play on specified channels at specified volumes. It’s based on a keydown/keyup idea, where you can set the state per-channel. There’s a lot of bug-ironing to be done with that, as I haven’t decided the best way of doing the various things it does. It does E9X (retrigger) commands pretty well, though!
• sampleDump – does what it says. Dumps RAW 8-bit/mono/22050hz samples to your sketch’s data directory, ready to be loaded into a tracker of your choice. This is a bit buggy – mysterious extra bytes appear from nowhere, and I haven’t figured out how to handle 16-bit XM samples properly yet, plus loop-data and finetuning info is lost, but we live and we learn. I did this as a by-product of trying to learn how to write MODs to disk, which could be cool for saving messed up versions of extant mods – with samples replaced and new loop-points set, etc. – or maybe even for writing new ones, if I was ever able to write a tracker. But, er, that’s hardly on the horizon…it’d be vastly complicated and would waste *all* of my time, instead of just half of my time like PortaMod is In the meantime, this could be fun either for wholesale ripping or maybe to save from a MOD that’s being played in one PortaMod instance and load it into the MOD being played in the other PortaMod instance.

Tung Twista