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 ...

New Neurogami track - Age of Reason

Age of Reason by Neurogami on Mixcloud

New track from Neurogami up on Mixcloud.

It’s also on Soundcloud: Age of Reason

Read the full post ...

Kicking off the Chinese Forehead wiki

Back in 1979 in New York City I was in a band called Chinese Forehead.

I wrote the songs, sang, and played guitar. We performed at CBGB and TR3 and lasted, I think, less than a year.

No records were every made, but there were some live recordings plus a large amount of loft-studio recording of all kinds of maybe-songs and sonic experiments.

Because the whole point of the Internet is to allow anyone and everyone to lavishly document the most arcane of matters I’ve expanded the Chi4 site to include a wiki.

I have shoe-boxes of cassette tapes and a few open-reel tapes of things done either as a group or as some fraction of the group (cleverly done under the moniker of Not Chinese Forehead). All of it was done around 1979 to 1981.

Over the years I had transfered some tapes to digital, sorting through what we did. Mostly I focused on the live recordings. Some of that has gone up on Soundcloud and archive.org.

Read the full post ...

Happy Birthday!

Happy birthday to me.

And you, too: My book, Just the Best Parts: OSC for Artists is pay-what-you-want for today.

Just the Best Parts: OSC for Artists

Read the full post ...

Goodwill on Credit - Travels in Ireland

My brother Gerry wrote a book.

Goodwill on Credit – Travels in Ireland

It’s a collection of essays about (surprise!) his travels in Ireland.

Goodwill on Credit

It’s terrific; he’s a good writer. It’s part travelogue, part personal story. It funny, touching, and educational (but don’t let that last part spook you).

This is a collection of 14 stories written over the course of several years covering numerous visits to Ireland. While it contains some (hopefully) useful travel and tourist tips, the collection is mostly concerned with the wonderful things that happen between points A and B on the tourist map, and the people (and the occasional animal) that inhabit those in-between places.

If you’ve ever thought of tracing or Irish roots, or wanted to read a more personal view of the Irish people, you should get it.

You can read one of the essays here.

Read the full post ...

Setting up a WiFly RN-XV board with Teensy 3.1

So the WiFly arrived in the mail and the hunt began for a guide on getting it up and running.

The device came from Sparkfun so it was kinda-sorta but not really ready to use.

Pro tip: If you get this from Sparkfun you will probably want to get some 2mm 10pin XBee Socket things and a Breakout Board for XBee Module. The pins on the Sparkfun-packaged WiFly module are meant for XBee; they do not play nice with breadboards.

After getting the WiFly pinned-up I found a few guides. None of them worked. It’s quite possible that some initial flailing put the board into some funky state, but the guides were a problem in other ways.

For one, they all seemed to refer to either a different WiFly module version or an older version of the firmware. For another, the all used a library. What I wanted was something no-frills, bare-bones, this-is-how-it-works example.

To be fair, these guides and their libraries were a big help. Digging through the library code I could (in most cases) see what specific commands was sent to the WiFly. Long-term, a library makes a great deal of sense. My code (below, as a gist file) is a bit hacky a literal. That’s perfectly good because it works and it’s easy to follow. However, you do not want to build anything complex on top of this example. (If anything it will make you appreciate a good WiFly library.)

Read the full post ...