Another test input to my interactive system _derivations. This time I hooked up my polyphonic sampler instrument to feed into the system – I’m improvising here with the sampler controlled by a MIDI keyboard…

This was a lot of fun to experiment with. Having only recently acquired NI’s Razor synthesiser and experimented with some sounds, I thought it would be interesting to have it controlled and processed generatively through some of the systems I’ve built in MaxMSP… ‘Multiple Players’ picks up where my short keyboard impro left off, generating improvised MIDI responses back to Razor derived from my performance, and _derivations analyses the audio output and recalls and transforms previously performed phrases… An interesting experiment I’m keen to try more of!!

]]> http://benjamincarey.wordpress.com/2011/05/29/_derivations-percussion-input-experiment/feed/ 0 Ben Carey http://benjamincarey.wordpress.com/2011/04/18/_derivations-with-statistics/ http://benjamincarey.wordpress.com/2011/04/18/_derivations-with-statistics/#comments Mon, 18 Apr 2011 08:58:25 +0000 Ben Carey http://benjamincarey.wordpress.com/?p=422 ]]>

It’s been an interesting experience documenting different steps along the way as I refine, change and add elements to this interactive system of mine, _derivations.

This is an example of the most recent iteration of the system design. Without going into details, I’m running a pre-recorded saxophone improvisation through the patch as a simulation (the soundfile is a recording of the dry signal from a previous improvisation with the patch). I quite often run simulations through the patch for testing purposes, and although this is a very practical means of testing and evaluating the system response, the ‘interactivity’ is of course only one way, computer responding to performer with no feedback in the other direction.

My most recent preoccupations have been in the analysis and matching of live input gestures to those stored in memory. The idea is to enable the system to be somewhat aware of the current context of the performance when making choices about what to respond with – i.e. which stored phrase to send to the synthesis modules to be output with transformations.

I’m using some statistics on four descriptors (amp, pitch, brightness and noisiness) to do this matching – and although it is still rather crude and prone to some errors, it’s working a great deal better than randomly choosing phrases from memory.

The latest test of my recent system _derivations - I’ve been in the development stages of this project for a while now, however it has evolved quite a bit over recent months… have a listen below:

This is a short demonstration of my phrase player module, with delay times modulated by output amplitude curves.

Coming back to a module I built a while ago is a nice feeling. Sometimes it’s good to take a breather from something to realise its potential. I find I can get bogged down in the detail of what I’m working on fairly quickly – then lose sight of why I was doing it in the first place! I find coming back to it later on makes it much easier to work out where to take it next. Description below…

Phrases are recorded from a live signal, their start and end points determined by a specific silence threshold and indexed as cue points within the recorded soundfiles. In this example the four players choose a phrase to output according to a movement function along the phrase length axis (short to long), and delay times are continuously modulated by the output amplitude curves of the players themselves.

This video demonstrates a few of the modules I’ve been using of late – hooked up together and responding to analysed instrumental input. The saxophone track is a short pre-recorded improvisation that I have been using to test my patches – so in terms of interactivity it’s really a one way street – but it does give a glimpse at what can be possible from the analysis of live input. I’m using the phase vocoder to stretch and manipulate some sounds with high partials (cymbals, piano scrape etc), with its output either continuous or rhythmic – determined by analysed accel/decel curves from the live input. I’m also using my analysis/sinusoidal re-synthesis patch to capture the saxophone spectrum and create a harmonic wash. In this example triggers to record, playback, change envelopes and trigger synthesis are all determined by pitch onsets in the live signal.

Here’s a demonstration of a little automaton patch I built this afternoon. It’s using probability (first order Markov Chain) to analyse and output the movements of an xy pad. From the analysis it continuously outputs the probability transitions to a second XY pad, creating an automatic variation on the original input.

I’m hoping to hook this up to some of my patches that use XY data to control things like mix, transposition and soundfile scrubbing.

The above recording is a short demonstration of an interactive system that I developed in MaxMSP earlier this year. I designed the system primarily for use between acoustic instruments and computer – however in this example I am using a MIDI keyboard as input to the system. The system analyses the input of the performer and develops algoritmic responses based upon the analysis of the performance data. Below is a more detailed description of the system in its current state:

Multiple Players is an interactive improvisation system and is an example of an interactive system that uses event-based methods for the analysis of incoming performance data. The computer listens to the performance of the instrumentalist either through direct MIDI input or through pitch and envelope following algorithms, and groups these streams of performance data into musical events such as notes, dynamics, rhythms, articulations, rubato and silences. Three virtual players model the instrumental performance by gathering this performance data into collections of transition probability tables known as Markov chains, and the output of the three players is in the form of MIDI data output to external software sampler instruments. User interface features include: choice of either MIDI or signal input; output destinations; options for routing of performance data; turning on or off player memory loss; output transposition and range for random tempo fluctuations. This patch makes use of the external object sigmund~ written by Miller Puckette and ported to MaxMSP by Puckette, Lippe and Apel.

Been playing around with my sinusoidal re-synthesis patch of late and made this three minute recording. I was interested to see how saxophone multiphonics would sound re-synthesised and layered on top of one another – and I got some really interesting results. It’s the same system used in this recent post, though I thought I’d use this post to describe the patch in a little more detail:

Pitch Models:

The patch is for the analysis, storage, manipulation and polyphonic output of spectral snapshots (sinusoidal models) taken from an incoming signal. Spectral snapshots are stored dynamically in an indexed data collection in three separate ways: upon a pitch onset; continuously at a user-specified rate in milliseconds or stored continuously for a user-defined duration in milliseconds upon a pitch onset. Output of the sinusoidal models is achieved by referencing a model index within the data collection. Options for output include constrained random output, direct output upon pitch onset, and output by MIDI note number (for remote integration with other software). Once triggered sinusoidal models are sent through both an amplitude scrambler and vocal resonance module, the latter of which holds a variety of vocal formants that can greatly vary the harmonic content of the stored model. Sound output from the patch is in stereo or four channels. This patch makes use of the external objects sinusoids~ and resonators~ written by Freed, Wright and Zbyszynski of the Centre for New Music and Audio Technolgies (CNMAT), University of California, Berkeley.