data visualization using [jit.gl.nurbs] in Max

I wanted a more attractive and engaging visual representation of the discrete and/or simultaneous dynamic data streams coming of the 18 FSRs, so I badgered Luke Woodbury for some advice and he kindly assisted. With a little tweaking and ctrl-c-v action I produced this:

MaxMSP 3D-mesh

latching FSR; without using Max!!!

An FSR, by definition and by design, has momentary functionality. It is in an inactive state when no contact is made, it becomes active upon contact and returns to its inactive state when contact is released.

An accessible 'transposition' feature will be added to the evolving interface design, such that the user touches a large pad once to raise all pitches by one semitone, then touches again to return to untransposed. The alternative is momentary functionality, whereby releasing contact returns to untransposed; transposition thereby requiring continued contact. This immediately reduces the number of available hands for pitch triggering to one. Undesirable, particularly given the extraordinary abilities of the chosen participants (musicians with cerebral palsy).

Momentary or latching switches are usually unwieldy things, so the choice is to use a DIY FSR, a design I'm already familiar with, and set a user-centric force threshold (eg 50%) turning the FSR into a momentary switch. extracting latching functionality within MaxMSP would be a doddle, thanks to the indispensable [togedge] object.

However, as I require latching output from the Arduino - I intend to implement visual feedback via different coloured LEDs (blue untransposed, green transposed) for the pitch triggers on the hardware interface - I was faced with three choices:
1. learn how to send serial data from Max back to the Arduino, and thence to the LEDs;
2. crack the code in Arduino;
3. give up and stick with momentary functionality.

Option 1 would require more time than Option 2. So I tackled the logic in Arduino (I really prefer to do this in Max though). The problem lies in the fact that when the circuit is closed and powering an LED, it is continuously in a given state (input pin reading is HIGH, output pin is also HIGH). How do I code for: "if it goes HIGH, what was the previous state and is this new state different?" Conveniently, Arduino provides an example called StateChangeDetection; but this doesn't include code for: "send a 0, then if the state changes send a 1, if the state changes again send a 0".

My solution uses a counter variable to determine whether the extracted button press (edge) should produce either a 0 or a 1:

Sharing

Short tutorial video, requested by the Cycling74 forum community, on writing code and a patch to access all 16 analog pins on the Arduino Mega2560, and sending the data to MaxMSP:

touch sensitive pad with tactile and visual feedback

 Using a small rubber disc, made from translucent silicone gel and an embedded superbright LED, I have prototyped the sensor pad which I will embed in an accessible interface. Here's a short video and stills of two stages of the process.

PVC pipe section as disc mould; silicone compound set, with embedded LED; testing for response:

one - to many, many

I recently had a discussion with a class of music students about parsing a single dynamic data stream (in MaxMSP); the subtext was the optimization of control-gesture data in a one-to-many mapping system. The input from an FSR ranges from 0 (inactive) to 250 (maximum force). How many different mapping modes did we achieve?
1.
binary state momentary: > 1 = on, < 1 = off, using [togedge]
2.
binary state latching: as above, adding a [sel 1] --> [toggle]
3.
raw velocity (dynamic or continuous data, i.e. aftertouch)
4.
peak, using a [gate]/[delay] system
5.
delta, using [t i i] --> [-]
6.
contact duration (between any ON and the next OFF), [timer] and/or [counter]
7.
trigger frequency, [counter] and some [mstosamps] maths

I'll post a video shortly, but can you think of any we missed?

"if logic" in Max

To enable the application of optimum gesture data, for those with a physical disability, one more (and final) gesture parameter may become available: current parameter data is location, force and duration/aftertouch; some participants have, in the past, demonstrated the ability to trigger two events consecutively, that is, use both hands to some extent. To this end I have applied a logic algorithm in Max to determine if and when two consecutive noteOn events or triggers overlap, such that contact is made with one trigger, and then with another before the first is released. When this occurs a glissando is applied between the two events (it could be any synthesis parameter); more importantly, when it doesn't occur there is no effect applied - events occur as normal.

Most of the video content for this blog is mirrored on my youtube channel:
http://www.youtube.com/user/ronnie9253

bend sensor, as flute

For the flute synthesizer, I initially used the MaxMSP external bundle PeRColate, which contains loads of weird and wonderful hybrid wind and wood synth sounds. The [flute~] abstraction has many parameter controls for breath pressure, embouchure, bore length, over-blowing, distortion etc etc. Great for use with a velocity sensitive MIDI keyboard with aftertouch, but not so stable with a bend sensor. Given the jittery and unpredictable data coming off the bend sensor, I built my own simple synth with four oscillators and a breath/noise generator in Max, then hammered the crap out of the sensor data to impose some stability - and it's still not 100% perfect. I wanted this to be a simple plug-n-play mapping, so breath pressure = pitch. Amplitude etc is fixed; vibrato crossfades in as a function of note duration. Pitching the thing is a challenge; it's tied to a given diatonic pitch set and after spending the afternoon learning how to 'play' it, I was able to get predictable octaves and fifths out of it. The only real control is: blow soft for a low pitch, blow harder for increasingly higher pitches......