Nodal

Computer Music magazine is not really my cup of tea. And there's a reason that too: the oh-so-dangerous semiotic fuel to the app upgrade race that happens to benefit only the advertisers that take up about 50% of the magazine's publishing space. In their correspondence section of the latest issue (June 2009), some reader complainted about their lack of coverage on freeware utilities, arguing that a digest of the most pertinent happenings in such a chaotic universe would be very welcome to Computer Music magazine readers. The magazine replied that, since freewares are free to try, why should they deny their reader-base such joy. Aren't they such darlings? Yep, that's right: Computer Music magazine is intended to be a buyer's guide, not journalism. Luckilly, they betray their intentions from time to time and in their single-page eye-on-freebies section of the same issue, they present us with the acknowledgement of the existence of a gem: Nodal. No tutorials, no raving reviews, just a screenshot and two paragraphs of briefly telling what it is. Oh, and a URL for whoever gives a fuck - and so I did. But enough with the bile.
Nodal is a MIDI manipulation tool. It's grid-like interface supports a non-linear sequencing of MIDI instructions in a circuitry logic. Remember Pipe Dreams? That's what you do to the MIDI signal in Nodal. The lenght of the side of each square in the grid is a beat in a definable BPM tempo. You can also create nodes in the plumming (hence the name), where you can edit many aspects of the signal and control it's flow around your circuit. The idea is to create a (not necessarily linear) sequence of MIDI messages, yielded to a third-party MIDI receiver. The downloadable pdf tutorial shows you the ropes proper, so be sure to get it.
Like they say on the webpage, Nodal doesn't make a sound by itself. In my system Nodal found the soundcard's synth by default, wich in turn produced sound. But you can route it to a hard synth, if that's your thing. Routing it to anything "software" is not trivial, though, and it depends on the MIDI slave, really. For example, Nodal can produce different MIDI notes, in different programmes (or "instruments"), in up to 10 MIDI channels. You must also understand that there's no concept of transport (play, stop, record, etc) yielded by Nodal, just the MIDI protocol. I tried to use Reason for a slave and eventually gave up when I learned how tricky that can get in a couple of forums. In those forums, people kept asking for rewire, vst versions, etc. But, if you a take closer look at Nodal, you will understand that this would cripple it's possibilities.
My suggestion is to use it on Plogue's Bidule, where you can liberally create MIDI-ins for whatever Nodal needs and route them to your weapon-of-choice favourite softsynth or effect, or even to Reason, through Bidule's Rewire. MIDI Yoke as a virtual MIDI port takes care of the harware-to-sofware bridge and Bidule picks it up with no fuss. I havent's tried Nodal on Audiomulch yet, but I guess you can get it to wait for an incoming MIDI message in mapping certain parameters.
What's exciting about Nodal is the possibilities it opens in MIDI management, be it generative music composition (scales, chords, etc), be it stochastic control over MIDI acessible parameters.

Some ground rules

I was thinking about some meta-duet-yourself issues...

We need to have project files and folders optimized for sharing. It takes a little obsessive-compulsive behaviour but it pays off in where's-Wally-sample-locating time. I don't mean to sound like I mastered the linguistics of folder creation but I think I have a pretty nice and ergonomical scheme going. And the software we use does require one, so here's my idea, obviously based on my set up.

I created a folder on my C: drive called musica. I installed all my music production related software in this folder, instead of in Program Files or Programas. This is not absolutelly necessary for sharing sakes, since the project file (be it reason's, audiomulch's, bidule's...) saves the pathway to the used files (samples, refills, vst's, etc), regardless of it's own location and I already came across a piece of software or two (namely freeware) that just gets a little annoyed with not being in Programas or Program Files.

But the pathways are the real bitch. I created a folder called vst in the musica folder for the obvious use. Most modern vst hosting software just needs a designated folder and does all the work by itself: bidule organizes vsts by instrument/effect criteria and then by programmer name and audiomulch preserves your own directory tree and finds the .dll down to at least four levels of subdirectories (tested). FL studio, however, makes you look for each plug-in you use by yourself at least once wich is a real pain and Muzys (for exmple) preserves the pathway to the vst and it goes berzerk if you move it somewhere else. I don't know how Cubase, Ableton and others manage plug-in hosting but we have one of two options: (1) we say 'screw it' and keep our own vst directories how we like 'em and plead to the programming gods that every software we use in the future is smart enough to detect plug-ins, despite the folder organization, or (2) we legislate about that and use, for example, my organization. I'm mostly inclined to crossing fingers and going for door #1 if your experience tells you that most sofware is cool with detecting plug-ins on the fly. However, going for door #1 might exclude someone in the future who uses dumb software...

For reason reffils, I just drop 'em in the general Reason folder. I have Reason installed in the musica/Propellerhead/Reason folder, but I can easily work around it if you have it installed in Programas and you're not into following my scheme in this chapter. One uniform scheme would be nice, though, if Duet Yourself includes other people. Again, two options: (1) screw it and future colaborators must pick up the pace if they want or (2) we "legislate" (my scheme, your scheme, other scheme...)

Samples are THE UBER BITCH and there's no "screw it" option here, since all software we use saves the pathway in the project file. So, no matter where we put 'em, we must go down the folder-creation-procedures road. I'm putting all samples of all projects I work in in specific project-related folders in C:/musica/samples and I find it pretty ergonomic to work with a sort of sample-central area that all software I use is led to find, so that all files used in a specific project (be it bidule, audiomulch, whatever) are all packed into that folder. This means that whenever I use a sample placed somewhere else, I must copy it to the work-in-progress sample-central folder and load it from there to the project file - yep, this means working with the Windows Explorer window always at hand's reach. This might seem like hard work but then again, that one folder is all we have to send (sample-wise) when it comes to sharing.
Ok, here's an example: let's say I'm working in a song called duetyourself. I must create a folder called duetyourself in the sample-central area folder. In my case, the pathway to this folder would be C:/musica/samples/duetyourself. I must now put every single sample file I use in the duetyourself song in this folder for the project files to find (again, be it reason, bidule, audiomulch or whatever I use) and this must also include .rex files that are not part of a reason refill. If I want to send you the duetyourself song for you to work in, I only need to send you the duetyourself folder I created, when it comes to samples. I also have to send you the project file, say duetyourself.rns, (and the plug-ins and reffils used that you might not have) but this file would only have pathways to the duetyourself folder. The sample-central area doesn't even need to be in the same place in our directory trees (if we're up to redirecting pathways there by hand) but the sample folder to that specific song must have all the used samples in one place, for ergonomy's sake.

This way, we would send each other a nice and tight little .zip or .rar file (with a password for unzipping to protect our god-given genius talents and authorship from unauthorized blog visitors) that would be ready to work in in no time.
Further versions of the song could be named by project number. Let's say you work on a version of the duetyourself song. You could send me back a duetyourself02.rns file and the updated duetyourself folder (with samples you added) and I could work on your version and create a duetyourself03 or improve the first version or whatever. By adopting these procedures, we could even be up to date with what the other one is doing. Updating our version of what the other one did (say, last night) would be totally fuss-free and fast. By the way, another nice linguistics thing to do would be to keep the format we regularly use for naming loop files: name_bars_bpms.wav or (name_bars_bpms.rex). No need for it in one-hit samples, though.

Another meta-duet-yourself issue: the Duet Yourself name is kinda settling in, isn't it? I say we're christened!