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.

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

Let’s see if we can agree on a regional spatial configuration of the sculpture + projectors & image-bearing surfaces in the main space by Tuesday morning so Harry can make critical decisions on the design of the lightfield.   We need sufficient lead time to get, build, work with the lighting gear.

This includes coordinating  the placement of projectors (one on floor + one just below grid,  near center vertical axis of left-hand wall?), on what they beam (strato-cells + the atrium wall ?), as well as the placement and visual type of the cells.
I’ve chatted with JC, Harry, JA, Tim, Morgan, Elena this past couple of days.  Soon JS.   I’ll chat with Patrick on the weekend.   I’m leaning toward one cloud at eye-level of mostly transparent cells, plus another denser cloud of image-bearing cells high up across much of the ceiling.   This way Harry’s beam will dapple through the cells when / if they intersect.

And this would simultaneously give a sense of density upon entry to the gallery, yet leave most of the floor space clear in the interior for the projector beams, the light-beam, and most importantly for the visitors to absorb the space.

On 15-Feb-08, at 12:48 PM, Harry Smoak wrote:

I’m here (in the lab) today well, but also won’t be here after 5:30.

What’s the status on the ground plan and location of projections.
Need to know for lighting.

On Fri, Feb 15, 2008 at 12:41 PM, Timothy Sutton <timsutton@fastmail.fm> wrote:
Hi all,

I’m around this afternoon, but probably won’t be able to still be here
by 5:30. In the meantime, I’m plucking away at learning the basics of
FTM and this concatenated synthesis stuff.

On Thu, Feb 14, 2008 at 12:34 PM, Prof. Sha Xin Wei
<sha@encs.concordia.ca> wrote:
Hi Morgan, JS,

JS said he has some patches for multiclocks that he’ll give you.

Gentlemen — please  coordinate ASAP to avoid duplicated effort.  I’m
assuming that Morgan if you can supply the clocks by Friday then  this
should strike off of JS’ list,
so JS can focus on creating the Jitter instruments that I and Morgan can
drive,
Hope to see the Jitter wraps at least
by Friday
so we have an API  public layer to code against

When I am free Friday end of the day,  I’d like to  see you guys netsend
some dummy engine params from one Mac (Morgan’s and My Macs)  to another Mac
running a JS patch.

Netsending and Receiving 3 floats (for clocks), and a 4-vector.  Dummy
visuals is OK!  We must get the the plumbing in place. and work outward
from there bc then we can get into roughing in the entire show.

My approach is to sketch the entire 20 day event and work in the
implementation details as we go, depending on the materials and elements (eg
sculpture, soundfield, lightfield)  as they emerge.

Let’s aim  to get some rough overall timing in place by the end of our next
programming session.

State 0 _ EMPTY - NIGHT
State 1 - INSIDE
State 2 - OUTSIDE
State 3 - MOB

Understand that this is just one topology , and that the topology may change
to a 5-state one with very different semantics.

The 5-state dynamics will allow a more meaningful transition from NIGHTLIFE
to  DAYDREAM

Thanks
Xin Wei

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