Our csound system, was Show this Saturday

Ok, long winded description of our show rig from last Saturday . . .

Well, our csound system for writing and live stuff has a number of different
components, not all of which were being used in this particular show. Some stuff
just hasn't been tested and/or practiced enough etc. Essentially in a nutshell, 
during the show we were muting/unmuting tracks, editing patches, and editing
mixer settings. The only thing running was a large csound ensemble with drum
samplers, synthesizers, mixer channels, and fx units. The only part of that not
actually generated entirely by csound was the drum samples. 

The monitor was really only there to make sure csound started up ok, once it was
going there was no visual output at all, hence it being out of the way and
sleeping most of the time. ( Actually I kept turning it on 'cause it was darker
than we expected and it was a good light source! ) Hardware wise, we had two
keyboards and a fader box, one of the keyboards also has two handy rows of 16
buttons some extra assignable buttons along with four faders. In csound, we
wrote some input handling modules that allow multi-user input with paging menus,
so for instance the big keyboard was being used to edit all three targets (
mutes, mixers, synths ) by paging through menus. Some buttons chose mode, then
one row was choosing track, the other target within that instrument ( ie filter
cutoff, pulse width, etc ), and then either the keyboard or the faders were used
to enter the values for that target. The fader box was going in on a seperate
input stream and was being used for track volumes. It also had four knobs used
for editing whatever we wanted with the second keyboard choosing destination
track. The second keyboard was locked on track mutes, but we used that as a
convenient way to select tracks for the fader boxes knob edits. So there were
essentially two pods, each routing various midi inputs to targets chosen by
weird menu systems. This required some fancy code in the input handler as we
essentially mimicked multiple-clients interfacing with a server through csound.
( So yes, if we want to we can even fight over a paramater! I think this may
have happened accidentally a couple of times. ) That part has been designed so
that one could have additional pods added on and essentially get four dudes
editing the sequencer and system at the same time. 

The actual music was coming off a csound score. We wrote in the Pimped Out Gvim
Traxor, a heavily extended gvim turned in to a spreadsheet multi-track tracker.
Gvim can completely controlled from python, so I basically used gvim as a host
for a set of python functions to edit, copy, move, view, etc. This is still
pretty unfinished, so parts are kinda ugly, but the higher order functionality
is already in place and it makes programming in complex patterns or really
really fast once you understand the system. It also forces one to write by ear
and not by gui! In addition to the event lists there is a high level arrange
file that allows one to easily string to together different event clips,
offsetting, repeating, shuffling, etc. The event lists made in gvim are then run
through a script that changes all the data into a csound score or sequences 
for our sequencer engine. For this show we decided to prewrite the arrangements
and run off a score in order to focus on only a couple of new things per show.
In retrospect, that was a good idea, our hands were full enough.

Other interesting features . . ., well the instruments have these cool
autoramps, which was an invention of mine that I'm particularly happy with. Each
instrument paramater has a shadow paramater for portamento time. When you change
a paramater, instead of it just going there instantly, the synth starts a new
ramp over the port time to the target you just put in. So if you leave the ramp
time at 0, it's a normal knob. If you put in 8 bars for ramp time, you can hit
one target value, and the synth paramater ( say filter cutoff ) will glide over
8 bars to the target while you sip beer or edit something else! If you want to
abort the ramp, you just put port time back to 0 and grab it and move. 

The delay units were cool too. Each instrument had too delay units in parallel
with a moogvcf emulation in the feedback chain. The delay time paramater was
quantized to 16th note multiples. This way wacky delay stuff could be done
really  easily without having to zero in on delay times. A lot of the cool
effects in the show were based on us setting up the delays and filters, then
spiking the filter cutoff on an instrument to quickly let in some sound and then
ring it out the delay units for a while. That would be called "Tard-Out" mode I
think. ; )

The synths are pretty monster, 124 paramaters per synth with four oscillators, 8
lfos, 4 envelopes, and a whole wack of modulation routing. Every synth was
pretty much the same code with just different settings and maybe a different 
filter opcode. The pads and chord instruments were interesting too, they were
what we call our Subtractive Synth Accordions. Each has four x four oscillators,
with each oscillator bank of four receiving a different pitch argument. This
means we could use 303 style glide with chords, which sound pretty damn dope,
without having to use and program four seperate synth lines.

Next show we will probably add real time playing and also move the actual event
handling over to the sequencer engine so that we can dynamically edit loop
paramaters as well as program in patterns on the fly. All of that works, but we
didn't think it was quite show ready yet. We will be able to use score data,
sequence preprogrammed data, and sequenced on the fly data all at the same time.
One of the cool features of the sequence engine is that there are multiple
levels going at once. So if you want to program in a bunch of changes, but have
them all happen at the same time at the top of the *next* sixteen bars you can
do so. The idea is that one should have only to write basic sketches and
harmonic/melodic material out ahead of time and be able to do variations and
arrangements on the fly. 

All in all, I'm quite happy with how it worked out and how well it sounded given
that we wrote six of the 8 tunes in the three days before the show! Prep was a
little down to the wire . . . I'll be putting up all the code on our website in
the next couple of weeks, www.xornot.com. If anyone has further questions, shoot
'em off! 

                                                                               
         Iain 



_______________________________________________
csoundtekno mailing list
[email protected]

Subscribe, unsubscribe, change mailing list options:
http://plot.bek.no/mailman/listinfo/csoundtekno