Another project sparked by a random request on mulch-discuss was Femme. An FM oscillator basically plays a tone (the carrier) at a frequency which varies according to the level of another tone (the modulator).
Now, in the case where the modulator frequency is high, you're essentially altering the timbre/waveform of the carrier, which can give rise to a wide variety of sounds -- especially if you use multiple FM oscillators in serial, parallel, or looped networks. This is cool, and cheap 4-to-8-oscillator FM networks were heavily used in 80s-era synthesizers and PC sound cards. However, if you think about the case where the modulator frequency is very low -- too low to be heard as a pitched tone by itself -- and the modulation depth is moderate, not hugely varying the pitch of the carrier, that's equivalent to vibrato -- a wavering in pitch that adds to the character of a tone.
So I let Femme operate and output both at audible frequencies, and in Low-Frequency Oscillator (LFO) mode, under 20 Hz, where it can act as a vibrato for another Femme contraption. At this point, though, the Mulch audio signal chain was being used to carry signals at sub-audible frequencies. It works just fine for doing so, of course, but this hearkens back to the days of modular analog synthesizers, where each component of a synth had inputs and outputs, and an inputs and outputs could be put to uses not originally intended -- it's that idea of a bunch of small simple boxes instead of one big complicated closed box again. Mulch's audio signal path can carry control signals as well. I'd already actually used this concept to let Pegger sync to an arbitrary rhythm track -- Pegger has an extra "control input" that it watches, triggering a pulse whenever the amplitude of that signal exceeds a certain level, allowing you to sync to an arbitrary rhythm rather than to Pegger's internal clock. That's another control signal, like an LFO driving vibrato.
Now, here, I ran into a bit of a dilemma. All the Mulch builtin contraptions and VST plugins have several parameters which currently can be driven by rodentially adjusting onscreen sliders and knobs, or by MIDI controllers. For maximum flexibility, it would be absolutely terrific if we could now take any audio signal in the chain and connect it to a parameter as well. Then a Femme oscillator running in LFO mode could make any knob in the system go back and forth automatically, freeing up your hands to do other things. Well, tough, there's no such feature in Mulch. I've talked to Mulch's author, Ross Bencina, about the idea a little bit. He's open to the concept, but he's got a lot of features going in, and I can't expect an integral audio-to-parameter gateway any time soon. So, how can we work around this?
Well, parameters can be driven from MIDI controllers, so I wrote MIDIBounce as a proof-of-concept. It's a standalone program that runs 8 LFOs into the MIDI controllers of your choice, which Mulch lets you hook up to contraption parameters. Works great. Now I don't even have to wiggle the knobs myself. That's useful. Driving MIDI controllers from arbitrary inputs within Mulch is the next stage, and that's what my latest projects, Nooner and Renoon, are -- one converts Mulch audio signal data to MIDI controller data, and one does the opposite. With those, I'll be able to convert between all three types of data that Mulch works with. There's a little bit of a hassle in that Mulch doesn't let you inject MIDI out data directly via the VST API, so instead you have to go through a "MIDI virtual loopback" device/hack, but that's a small price to pay.
There's more to come... but I need to get my implementations a bit more caught up with my concepts first.
Some of the plugins I've been working on only make sense
in the context of the VST plugin host that I use.
I glossed over a point in my previous post. I don't actually
use Cubase. There are a number of VST hosts out there.
(There's also another plugin standard, Cakewalk DXi,
but VST seems to be more widely used.) The host I use is
a weird one: AudioMulch.
Mulch is pre-version-1.0 beta shareware and still evolving.
It has some conspicious gaps compared to other VST hosts.
For example, most VST hosts have sequencers in them, allowing
you to edit a sequence of notes for VST instruments in a relatively
musical way. Mulch doesn't have a sequencer. It was originally
designed to apply effects to live performance rather than
to be a composition system of its own, apparently. I'm more into
noise-scapes than heavily structured composition,
so I'm okay with the lack of a sequencer.
As with Buzz, in
Mulch, you connect individual components together with virtual
"patch cords". Most of the components are effects and filters.
You can get unexpected, emergent results by chaining a bunch
of effects together. You can build feedback loops, "seed" them
with a squirt of noise, and listen to the sound evolve.
I like Mulch because it doesn't try to tell me how to work. I'm
not really a "music guy", I'm not a DSP guy, I'm not heavily
into rave/techno culture. Mulch's interface is clean and simple
and doesn't try to hide the fact that it's a Windows app, unlike,
say, FruityLoops.
There are basically three kinds of data in Mulch: audio, parameter,
and MIDI.
Audio data is handled by both VST plugins and built-in Mulch
objects ("contraptions"). Both act basically the same: streams
of 32-bit floating point samples at a 44.1KHz sampling rate
go into contraptions, get transformed, and come out the other
end. A contraption may have any number of inputs and outputs;
an output can "fan-out" to any number of inputs, and inputs
can "fan-in" from any number of outputs. Unconnected inputs
act as if they're connected to an endless stream of zeros
(although plugins can check for connected inputs and alter
their behavior accordingly). The internal representation
of audio has more dynamic range and precision than the 16-bit
representation of most consumer soundcards, so digital
quantization noise in a Mulch effects chain is not normally
a problem.
Parameter data are the settings for each contraption -- the
positions of the knobs and sliders controller mixer channel
gain, flanger rate, or heavy metal grindage distortion levels,
or whatever. Besides manipulating these controls individually
via mouse, Mulch can store and recall presets for all the
controls of a given contraption at once, and automatically
adjust the parameters over time via "parameter automation
tracks". Some brave souls have gone so far as to use the
parameter automation system as a sequencer of sorts, painful
as it may be.
Finally, MIDI data can be used by Mulch in two different ways.
First, MIDI controller data can be mapped to Mulch parameters,
so when you adjust the mod wheel on your synth keyboard, it
kicks up the reverb depth and turns up the "screams of the
damned" sample loop in the mix. Secondly, any VST plugin that
cares can receive MIDI events. This is how VST instruments (aka
soft synths) get their marching orders.
Whew! That was a lot of background, but it helps make sense of the projects I'm working on.
I've been working on some audio programming projects while I've been unemployed. If you're so inclined, you can visit them here.
Steinberg developed an audio plugin API standard called VST for their Cubase line of "virtual music studio" software. At its simplest, a VST plugin takes a block of audio samples in at one end and spits another block of audio samples out the other end. In the middle, it might apply reverb or echo, or frequency-spectrum modification, heavy metal distortion, or whatever else you can think of. VST plugins can also respond to MIDI events; those which turn musical notes on and off in response to the appropriate events are known as VST Instruments (VSTi's) or software synthesizers. The VST SDK is free for the downloading, so anyone with a compiler and an idea can, in theory, write a plugin. However, to write a good one requires a fair amount of understanding of the disparate realms of software engineering, digital audio signal processing, and music.
So, I'm learning to write audio software.
I hope to differentiate my audioware from the rest of the stuff that's already out there, not by having the most CPU-efficient, or the cleanest audio output, or the most cutting-edge synthesis techniques, but by providing a different set of knobs than everyone else does. In my opinion, the vast majority of both hardware and software synthesizers out there don't make it easy to use the features they provide.
The fundamental problem is that there are a lot of ways to control a sound -- in technical terms, control of the sound is an N-dimensional parameter space with a very high N. Some synthesizers offer N knobs with which to explore this space, which lets you dial in exactly the "coordinates" you want, but it's very hard to plot a smooth trajectory through N-space this way. Consider an Etch-a-Sketch, the 2-dimensional case of one-knob-per-dimension. It's very easy to get to a specific point on the Etch-a-Sketch screen. It's sheer misery trying to draw an arbitrary curve on it. Now imagine trying to explore the 75-dimensional space offered by rgc Audio's Square I soft synth. Don't get me wrong: Square I is a fantastic soft synth; a bargain at $35 (and its excellent little brothers, Triangle I and Triangle II, are free). All I'm saying is that adding more knobs to a synth, hard or soft, reaches a point of diminishing returns (especially in the hardware world where knobs cost money).
So, in short, I'm looking at ways to interestingly explore higher-dimensional spaces by ear.
This is a test of Russell's new Vitriol Distribution System. This is only a test.
The purpose of this blog, as distinct from UBVB, is to give me a place to talk about things that aren't about my personal life. The initial impetus is my need to bitch about software that doesn't work. It occurs to me that I can also use it to talk about development plans for my audio software projects. Of course, that will also amount to bitching about software that doesn't work.