After a weekend of furious hacking, compiling and bug-hunting, I’ve finished a beta build of my control/editing interface for the Novation Supernova II synth.

It’s based on the Ctrlr project and offers a standalone executable AND a VSTi dll/AU with an extensive tabbed virtual controller mapped to lots of the Supernova’s most important CC and NRPN parameters.

Using Renoise’s MIDI Control device is fine for just a couple of params, but it’ll only do CC and each devices has a limited number of params – until now, I had multiple saved presets for the device which I had to laboriously load each time…

Now, however, you can basically treat the Supernova as a VST instrument – you send MIDI to it as you would a VSTi, it takes its own MIDI input from the Supernova (so knob/slider values are kept visually in sync), you can drop both CC and NRPN parameters (hundreds of them!) into an Automation device and go crazy. Except for a few really in-depth things which still have to be done by getting physical with the hardware, you can build complex patches from scratch within the controller and preview notes as you would with a VSTi.

This is a bit like Midi Quest by Sound Quest, with the slight difference that it looks better, it actually works and it’s completely FREE!

NOTE: eventually, there’ll be a *complete* CC/NRPN implementation, but this build only covers about 90% of the CCs and about 50% of the NRPNs. That’s because I wanted a controller that gave me DAW automation of critical parameters and also let me do a decent chunk of patch editing. For now, there’s some stuff you’ll still have to go to the hardware to do (and some stuff will never be available to software control, like the Osc Solo button), and I won’t invest time in doing the FULL implementation until Ctrlr has full sysex librarian capabilities – only then will it be worthwhile. But that’ll be reeeeally cool

NOTE #2: since most Windows MIDI drivers won’t let themselves be shared, you might have to play around with MIDI outs. I’ve got about 6 x MIDI I/O so I haven’t had problems…

NOTE #3: Nova/Nova Laptop owners – not sure if this’ll work for you, but it’s worth a try. I know lots of the mappings will probably be the same, but I make no promises 

Check it out here. There are also other Ctrlrs for other hardware synths on there. Next on my personal to-do list is possibly the Roland JV-1010 (although Roland have made it a REALLY complicated task…not sure if I can be arsed).

I also have a Virus B with some broken buttons, so I’m busy making an editor for that too. It’s mostly finished, though there’s fine-tuning and some UI tidying/graphics work to be done. There are a few commercial editors out there (not all of which seem to work very well), but my version will – again – have the advantage of being free and open source. In other words, if you think I’ve got it totally wrong and you want to do it better, you’re just an SVN checkout away from being able to do it

Here’s an indication of my progress on the B editor… I’ve owned a Virus TI Snow for a week or two and while it’s great, the band that I’m mainly using it in now has a Polar, and I have the B (old and broken though it is), so I’m going to sell it on and use the money to fund a repair of the B (not cheap, since there’s only one company in the world that can get spare parts from Access and do the job, and they’re in Germany). So bear in mind that while I’ve boxed up the Snow ready to ship when it sells, I’m quite happily using the Virus B VSTi in Renoise and Ableton to control, automate and record the B \o/ In other words, it’s very useable for me and will soon be very useable for everyone!

This post is password protected. To view it please enter your password below:

Password:

Click here to view the embedded video.

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.

So it turns out they last pretty well. And in this age of 1541 emulators, MMC64 interfaces and the like, it’s sad to see a Datasette sitting unused and unloved. So I decided to lavish about four quid on mine and turn it into a block-rocking pimp star supreme with:




# an internal speaker

# internal 9v battery power

# an external in (for when I eventually get the recording head to work)

# a line/headphone output

# a switch/knob for power and drive motor speed control (though this doesn’t really work yet)

# an unfeasible amount of mystery line noise, which I’m going to pretend is intentional and adds ‘character’.

As usual, my half-arsed attempts to document the process fell flat since I’ve lost the proprietary charger for my proper camera (damn you, Samsung) but I caught a few snaps on my phone cam and some of them aren’t too dreadful. Eventually I’ll get some video of absolute junglist techno dub rave spaz horror madness being perpetrated with this tremendous device.

Table full of crap - Datasette innards, a copy of Firelord, an op-amp circuit and some other bits.

Closeup - motor on the left, counter above it, now-redundant LED (used to signify data writing), Firelord again!

Squeaker! Louder than it looks, but the biggest that'll fit in the case snugly.

Ghetto-style Dremel speaker grille.

...and that's where that goes

Everything cut, drilled, inserted, etc.

Hells yeaowh

Finished product. Sort of.

So does it work? Well… Yes. Basically. The speed control isn’t right yet – possibly because Commodore put a regulated motor in that stops dead below a certain input voltage. Although it’s supposed to take 5v and I’m giving it 9ish… and it falls off below 90% of the pot. Oh well.

Some other stuff isn’t spot-on yet, either. I couldn’t be bothered with the LED, but that’s a possibility. Oh, and like I said, the recording isn’t working perfectly.

The final shame? I don’t actually have any audio on tape to test in this! I’ve only got data cassettes, so I’ve been chilling to the blissful binary of Revenge of The Mutant Camels, Arkanoid and Firelord all night. I’m reasonably satisfied that I’m getting what’s on the tape out through the speaker/line, so that’s fine. Oh, and my speaker cut-out for when something’s plugged in isn’t working very well either – probably dodgy soldering on my part. Twill be fixed.

Updates will come…