New Renoise tools

Two new tools are up on the Neurogami/renoise-ng Github repo.

One is New from template, which allows you to set up a number of songs to be used as new-song templates.

The other is Randy note columns, a tool for configuring controlled randomness among multiple note columns in a track.

Read the full post ...

Fork of osc-ruby to add support for Boolean

Just a short note to say that the osc-ruby Ruby gem ha sbeen forked to add support for Boolean T and F.

Github repo is Neurogami/osc-ruby-ng

More info on the Neurogami site.

Read the full post ...

OSC Jumper for Renoise released

A new tool for Renoise, OSC Jumper, has been released.

You can read the details on the Neurogmai site.

Read the full post ...

Video for the Neurogami track "Morgen"

Here’s a video for the track Neurogami track Morgen

Morgen from Neurogami on Vimeo.

It was done using Processing triggered by MIDI from Renoise, and then multi-layered in Screenflow, with a few graphics overlayed.

The computational overhead led to assorted glitches. Rather than try to remove them, I embraced them.

Read the full post ...

Wiivisiting old software

Back around 2007 or 2008 I started hacking around with Wii controllers (AKA “wiimotes”). People like Johnny Lee were doing some cool stuff by repurposing the controllers.

I even gave a talk about this at the 2009 Mountain West Ruby Conference as well as at Ignite Phoenix IV.

I’ve continued to experiment with game controllers and music generation, but at some point the Wii sort faded into the distance. It occurred to me that I know a fair bit more now than I did then and decided to dig up the old code and give it a whirl.

I had about six or eight local repos of stuff, some for music, some for demos of one kind or another. None of them still ran.

Changes to Ruby, JRuby, and Java broke things in subtle ways. I had updated my JRuby install because I didn’t see much point in having working code that depended on an already outdated JRuby. Likewise for Java. Use the latest, and get stuff working.

Read the full post ...


Sharing Lua script files among Renoise tools

Recent articles showed how to use to Renoise Lua scripting to alter a track’s send device. One was driven by OSC, the other by MIDI.

In both of them the code that did the actual send device manipulation was the same. But since these were two different scripts the same code appeared in both places.

Sharing code using copy-and-paste is not the world’s worst programming sin, however much it might make some developers cringe. If you are throwing together a one-off script for a short-lived need, go for it.

In many cases, though, having the same code in multiple places is a poor idea because it breaks one of the golden rules of software development: Be lazy. (Read up on the three great virtues of a programmer.)

Copy-and-paste sure seems like the laziest thing to do at first, but if the code has any amount of complexity or importance there’s a really good chance that sooner or later you will want to change it. Maybe to fix a bug, maybe to make it faster, maybe to add a feature.

With the same code in multiple places you need to keep track of all those places and edit the code in all those places. Oh, bother.

Can Renoise Lua code be shared? Can you create a file that can be loaded and used by multiple scripts?

Indeed you can.

Read the full post ...

Renoise send-track scripting with MIDI and Lua

A previous article explored using OSC to call Lua code to set the “Receiver” value of a send device.

The basic idea was that a given send device would be associated with some set of send tracks using a naming convention. The OSC handler code would then allow for changing that send device to use one of those associated send tracks.

It works great. But what if you want to use MIDI instead of OSC?

Read the full post ...

How We Sleep

Read the full post ...

Renoise send-track scripting with Lua and OSC

As previously described, I am a big fan of Renoise, and a big fan of manipulating the send device.

Renoise has three kinds of tracks: sequencer, send, and a single master. A send track is an intermediary between a sequencer track (e.g., a “stem”, the track where you have the notes and other commands ) and the master output.

You can chain devices (e.g. reverb, gate, compression) on a sequencer track to change the sound of that track. You can also “send” that track to a (duh) send track, and the send track can also have a device chain.

One reason to use send tracks is apply a common set of device effects to multiple sequencer tracks. Perhaps you want most tracks to have the same amount and style of reverb. Set up that reverb, then send those tracks there.

Since different send tracks can, with variations in device chains, give the same source track very different output, they make for a handy way to quickly alter the sound of a track during a song by changing the “receiver” (i.e. the destination) of the send device.

In the previous article you saw how to use device automation to have the receiver of a send device change automatically at different parts of a song.

What if you want to control such changes during a live performance?

Read the full post ...