Synthesis

My main comment is that instead of creating custom code for a specific state / scenario that displaces the other instruments, we need to make the suite of instruments in Ozone available in parallel as well.  The way to do this is to continue to learn the suite of Ozone instruments which are a fairly small (5 or so) number of instruments, all resident in memory on the trashcan, where each can be varied widely (and wildly) in look and feel by parameterization and pre-sets.   Rather than code from scratch, let’s see what you can do by modifying parameters of the rich suite of code that already exists.

We’ll need the full suite for rehearsals this week, because the Dean’s invited the President and Provost for April 7-9.  A visit may or may not happen that week, but that is the earliest date by which we need to be able demo the full spectrum of Ozone++  including timespace and elastic.

Ideally addressable under Mira interface tabs on  multiple iPads  — say 3 iPads (ask Sylvia for the mini-iPad so we can install code on that one for me)  — so different people can be walking on the floor simultaneously varying different layers.

Visuals:

The visuals from yesterday were ok, but were far too sparse and simple and specialized to be adequate for the VIP shows to come.  We need the visuals to be cross-fadable to the older (and visually richer) instruments : 

timespace, 

particles, 

Navier-Stokes, 

elastic time,

live portal feed,

canned feeds (in a jit.submatrix + jit.rota),

vectorfield

We must be able to layer in the other instruments.   Connor: this was already written in Ozone so I’d like you to integrate your particular Jitter instruments into the framework what Evan left behind.

Project line art — Most of the textures do not work very well for demo purposes.  And they never appear as clearly as line art.  (Connor : I’ll  send separately the simple vectorfield patch so you can incorporate it into our kit of video instruments as a basic utility.   It would be worthwhile making a particle system that’s driven bib the vector field without Navier-Stokes, so that the particles will flow unbound. )

Sound:

Ditto.  This is in a better state of playability.  The main needs are

(1) True spatialization —  Julian and Navid had this so it must be exposed.  Don’t be shy to ask  Mike, Concordia, CNMAT, or IRCAM folks  for help.  The rich ambisonics recordings are pretty hard to appreciate mixed down as they are.

(2) Much clearer relation to movement (and location) — please for ideation purposes, let’s put in a sonic reticulation i.e.

 Julian’s jitgrid2snd

Navid’s wind , 

Garrett's tuned scales,

are the most successful.

ask Todd for the percussive code, or write it based on Julian’s rhythm.

Garrett has a great idea of writing a separate Mira tab for rhythm flow from instrument to instrument — cross-modally:

lights

fans

video

sound

Each of these instruments should be able to register i/o rhythm_type which is an FTM matrix a la Julian’s rhythm kit.

Connor: You should run the default sound instrument patches directly on your own visual computer, so that they run with sound even if they have to play out thru your own local computer speakers.   All video instruments must make (local) sound by default, if only as an experiential design aid.  This means that the video computer should have its own audio out to the sound mixer etc. etc.

Lighting:

All lights need to be addressed under a uniform interface.

right now the floor lamps, overhead LED’s, fans 

seem separate.   Even if the device level interfaces are distinct, they  should be addressable by a uniform channel map.

I’m not sure how to treat the iCue and Byron’s motorized mount.  I’m inclined to treat them as a new class of Ozone instruments: bodies.

For now these bodies are merely objects made of light.  They should take a parameter of type rhythm to introduce warbles in time (i.e. speed), and space (displacement).

The fans can be part of yet another new class of Ozone instruments : field.