hi devs,

i’m now sending out values from the ‘breather’ i’ve built. it sends this message:

/rt/state/breather/m n, where

m is the intensity of the breath, and n is the volume of air contained. the latter is to communicate whether the last breath was a breath in or out, but it could be later made to be a characteristic of the breath, ie. short breaths yield less volume.

you can control the behaviour via OSC:

/rt/state/breather/weakness n

and /rt/state/breather/adrenaline n

weakness makes the breath less calm and fluid, adrenaline makes breath faster and shorter.

it relies on msp for some of its parameters, so it’s maybe best run on my machine, but it can be moved to others, since all the IO is via OSC. it’s incorporated into my master pro/rt/snd patch as a subpatch, but if anyone wants to extend it i can make it available as a module in the general repository.

again, my machine is 10.0.0.10, and you’ll have to add yourselves to the udpsends in the [network] subpatch on my machine. also a reminder that my mic intensities are always sending out if you want to experiment.

I’ve simplified the event topology to a bare minimum that still has a chance of flow in two dimensions, and has a beginning, muddle, end. Let’s call it the VISIT4 topology, since it’s got only 4 states: NIGHT, DAY(=DAYDREAM=DESERT), GLASS, FIRESTORM.

We media folks met and talked about the experiential aspect of these states last week. Basically, the room leaves its NIGHT activity as the clock shows it’s Gallery business hours (9 - 19h?).

NIGHT is time for the Gallery to dance (danse macabre, sibelius’ valse triste, hiphop, etc. according to the season) as you like. It would be interesting to suggest autonomous life, autonomous intentionality, locked behind glass.

DAY is when the clock shows Gallery is open for business and there’s a minimal activity in the room. (We can set the threshhold just below one-body’s-worth of activity by calibration under the Gallery’s conditions, or we can use the surveillance camera trained on the receptionist desk to see when someone is near the receptionist area.) It could be interesting to characterize DAY state as when no visitor is there in the Gallery, but it’s open, and showing its dreams. What those “dreams” are is up to the creators to interpret. We did speak about playing back processed, previously recorded material.

As visitors infuse the Gallery, the room gets “wetter” (derives more energy from visitors). As it gets wetter, more weather happens: i.e. the state tends away from DAY and toward the mixture between GLASS - FIRESTORM .

GLASS is viscuous, liquid, continuous. In this state, horizon is distinct from sky: the projections on walls are distinct from projection on the ceiling. The visitor may be able to “write” on the surfaces — only one attractor (that associated with the biggest blob?), permits writing, e.g using a scattering of dust.

FIRESTORM is violent; sparky, atoms in void. Maybe nervous in the sense that the dynamics are quite sensitive to perturbations from sensors. Eg. motion from camera input drives the particles very hard, bc the particles’ masses are low, or attractors’ gravitational masses are high.

In terms of physical configuration, what distinguishes GLASS from FIRESTORM could be how people are positioned and / or moving near the sculptural elements in the room: the Cells, the Sensate Tapestry, possibly the Suitcase in the other, hidden room.

I don’t know what activity should tend to correlate with GLASS & FIRESTORM in the most tangible or compelling way. My first cut guess would be to sense whether people (a person) are gathered close to a (any) sculptural element. For example, people “touching” (within threshhod of our sensors) any part of the Cell structure or Tapestry could send the system into FIRESTORM.

This we’ll have to work out in situ, in vivo, of course.

Here’s a thought about transitions between instruments like

water - ice - … - waterfall

One question is how to make a 2 (or more) dimensional transition between states that is more interesting than a cross fade between two (sets of ) instruments.

For example, as we approach waterfall, maybe the NUMBER of particles can increase as DAY —> 0. While the SPEED or LIFETIME can increase as FIRESTORM —> 1.

Also the responsivity of the particles to human movement as seen by the Motion patch, should increase in FIRESTORM. We could decrease the mass of the particles, or multiply the strength of the attractors associated with the movement density distribution.

As GLASS –> 1 (and FIRESTORM and DAY necessarily –> 0), the particles (if that’s what they are) could increase in mass until they are relatively insensitive to the movement of the human visitors.

Another point: as the event goes to its terminal DESERT = DAY state, the particles perhaps should return to their original constellations.

Ever since Meteor Shower, I’ve asked for being able to set the initial positions of the stars according to simply the (x,y) coordinates of the brightest N pixels in the input video (could be a static bitmap). Michael Fortin may have provided this as an external to Max, but surely this can be done, simply enough, in native Jitter.

It would also help if the instruments near the boundaries of neighborhoods of the fundamental states look the same. In other words, it would be helpful if the FIRESTORM instrument(s) look like GLASS instrument(s) for some choice of parameters. So we can make multi-dimensional transitions.

For times series that suggest “intentionality,” I suggest
1. Mapping the game controller joystick via Max to a DMX instrument
2. Parametrize an instrument
3. Use Tim’s sensor data recording tool (a very important research instrument !!!) to record the INPUT (not cooked) sensor data while manipulating the DMX instrument.

You can re-use the sensor data

Alternatively just record people’s signatures on a tablet,
Use the x,y,t data mainly for the temporal dynamics,
Map the dynamics to all sorts of temporal processes, e.g. speed (or acceleration) along a trajectory, like the moving beam trajectory, whose (x,y) path is independently determined.

This may yield effect of “intention” …

Dear Elliot, Flower, Elena, + whoever in Winnepeg has the electronics chops and is related to the cell sculpture or the WYSIWYG tapestry,To follow on the tests that Patrick & other Winnepegers have done with the suspended cell sculpture,I’d like to see if any of you can commit to getting data flowing from (some of) the cells to Morgan and me in Max.At this point I see no  compositional  need or plan to incorporate signals from the cell structure in the state-engine.   So it’s really up to those of you who are creating the cell structure to come together,decide what the signals could do that’s interesting and relevant to the cell sculpture relevant to the themes of RT,and to make precise plans on how to build the sensors, the electrical analog- digital interfaces, the data network,and  to program the signal processing.What platforms do you want to use?  Are the Arduino’s “merely” to map data from sensors in the cells to Max/Macwhere you’d code up the processing in Max so you can communicate with the Tim’s MSP or JS’ Jitter instruments directly?But who will write that code for that processing ?   (Not Tim or JS or Morgan, but an applications programmer.)SUGGESTION:  How about if Elliot+Doug talk with the cell sculptors : Patrick, Dirk, Candace, Gregory, Evan, (possibly JC, Flower, JS if they have time headspace, which is doubtful about possibly getting data from the cells to the WYSIWYG sound instruments?This could be engineered independently of the other systems.Xin Wei

In reference to Osc names:

The proposed OSC naming convention is:

/rt/clock/time/seconds [1,2,3…n]
/rt/clock/time/minutes [1,2,3…n]
/rt/clock/time/hours [1,2,3…n]
…
/rt/clock/time {s,m,h…}

/rt/clock/env/seconds [0.0,1.0]
/rt/clock/env/minutes [0.0,1.0]
/rt/clock/env/hours [0.0,1.0]
…
/rt/clock/env {s,m,h…}

Each clock drives its own breakpoint envelope, thus ‘env’. This means everybody has access both to elapsed time and to the current state of the envelope (defined by a breakpoint editor). Using envelope data (instead of elapsed-time) may make clock-dependent changes more globally coherent.

/rt/state/breath {nobody,inside,outside}
/rt/state/breath/nobody n
/rt/state/breath/inside n
/rt/state/breath/outside n
/rt/state/breath/mob n
/rt/state/visit {nightlife,daydream…desert}
/rt/state/visit/nightlife n
/rt/state/visit/daydream n
/rt/state/visit/firestorm n
/rt/state/visit/glass n
/rt/state/visit/desert n
where n is [0.0,1.0]

/rt/state/calibration [0 or 1]

/rt/state/dummy [1,2,3,4…n]
/rt/state/dummy/1 [0.0,1.0]
/rt/state/dummy/2 [0.0,1.0]
/rt/state/dummy/3 [0.0,1.0]
/rt/state/dummy/4 [0.0,1.0]
…
/rt/state/dummy/n [0.0,1.0]

The dummy patch (tml.pro.rt.dummy) is currently running on Miniserver. (Dummy OSC values are being sent to Tim’s computer (10.0.0.12), but I need IP’s for anybody else (JS) who wants data.)

The dummy patch consists of 4 sinusoidal oscillators driven by metros+counters (max = 6283), so period = ms*6283.

1 = sin(x1)
2 = 1-sin(x1)
3 = cos(x2) (Remember: not necessarily 180º out of phase, x2 is independent)
4 = sin(x3)
5 = cos(x4)

I’ve also added a patch called tml.pro.rt.util.dummyrate (in the util folder) that you can use to remotely change the rate of any oscillator.

Here’s a 5-state topology for a VISIT by a visitor
/rt/state/visit/nightlife n
/rt/state/visit/daydream n
/rt/state/visit/firestorm n
/rt/state/visit/glass n
/rt/state/visit/desert n

Here’s a very rough proposal for OSC names for state info. Change / suggest at will!

/rt/state/clock/1 n

/rt/state/clock/2 n

/rt/state/clock/3 n

(don’t know which should be which timescale – 1 is fastest?)

/rt/state/relativeActivity/0 n

/rt/state/relativeActivity/1 n

/rt/state/relativeActivity/2 n

/rt/state/relativeActivity/3 n

(could change to have more meaningful names?)

/rt/calibrationMode n (0 or 1)

(others would listen for this)

The Rolls Royce of such work will be Doug van Nort’s sensor time-series filter-based and geometric-model based predictors,
an outcome from his PhD and WYSIWYG work.

So for now we should look into Tim’s and ARJ’s patches for calibration as a solution for the medium term — this semester. But the important thing is to agree on a common procedure (protocol) for instrument-level and system-wide calibration at a sufficient level of abstraction to accommodate swapping out individual support externals or abstractions
without breaking the code you write.

This is specific to calibration
TUNING will be your own responsibility — but it’d be useful to write some ways for an instrumentalist other than yourselves to re-tune or even reconfigure your instrument.

Speakig of that — I think the Jitter instruments should now permit someone other than JS to save a set of parameters for a specific behavior. It would be smart to think of these “presets” as different (sub)instruments (on a fixed build of Jitter patches), and even name these pattr files as presets each defining an instrument/. (Much like presets for sound hardware synths.)

I recall JS was making this work for Cosmicomics — so does it work now? If so, can we learn how to do it?

Teachers: JS, Tim?
Students: Morgan, Marine, Xin Wei
Class: Friday after 5:30 ??

Cheers,
Xin Wei

On 14-Feb-08, at 11:00 AM, Timothy Sutton wrote:

Another example, here’s the patch for the Jamoma modules to do autoscaling, done by ARJ (now PhD).

If you open the main patch, there’s a bunch of dependencies not there, but they’re just shared system components for Jamoma. the help file gives some explanation and examples. but what’s there is very simple - using trough and peak for the most basic mode (a cleaner version of what i posted), and a bit more complex modes using a running window with standard deviation calculation.

more food for thought,
-tim

<jcom.autoscale.help><jcom.autoscale.mxt>

To structure the software development, we should adopt the tgvu-Oxygen-Ozone conventions as documented in the TML WIKI (thanks to Yon Visell, Emmanuel Thivierge).  Every developer should understand the OXYGEN software architecture, so you know where your code sits in the framework, and know what sorts of data goes where,  the processing layers, and strategies.   You can start by reading the documentation

http://www.topologicalmedialab.net/fields/tml/field.php?n=Category.Oxygen

Technical description of state engine (mostly for Morgan) :

http://www.topologicalmedialab.net/fields/tml/field.php?n=Projects.Eerm

If we make progress on integrating our software, and if we get funding to put it into shape, the OXYGEN epoch will be replaced by OZONE.

- Xin Wei