Re: Our csound system, was Show this Saturday

Hi Iain,
I just read you message today, and I'm very pleasantly surprised that 
your extremely complex setup ran properly. From what I remember there 
were some failure reports with very complex code. Also some very nice 
ideas there that I'll try in the future.
Did you run your live show on Windows or on linux?
I really like your idea of modular code can be recycled. I started 
writing my current setup several months ago, and it's so convoluted now 
and so targeted to a particular performance that not very much is easily 
recyclable, but I'll make sure it is for my next project.
I see you recommend using pd for the graphical interface, maybe that can 
be changed to a Csound FLTK interface when Csound5 is stable? That could 
give better resolution than MIDI, but I'm not sure if it would affect 
real-time performance...
I'm curious, what is your schmo job? ... I am about to quit mine...
I'll have a good look at your code and report back. Thanks very much for 
making it available.

Cheers,
Andrés

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


_______________________________________________
csoundtekno mailing list
[email protected]

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