Because there are problems with the wiimote support in SuperCollider, I wrote a class for talking to Darwiin OSC. This class has the same methods as the official wiimote classes, so, should those ever get fixed, you can just switch to them with minimal impact on your code.
Because this class takes an OSC stream from a controller and treats it like input from a joystick, this code may potentially be useful to people using TouchOSC on their iPhones.
There is no helpfile, but there is some usage information at the bottom of the file:
// First, you create a new instance of WiiOSCClient,
// which starts in calibration mode
w = WiiOSCClient.new;
// If you have not already done so, open up DarwiinRemote OSC and get it talking to your wii.
// Then go to preferences of that application and set the OSC port to the language port
// Of SuperCollider. You will see a message in the post window telling you what port
// that is .... or you will see a lot of min and max messages, which lets you know it's
// already callibrating
// move your wiimote about as if you were playing it. It will scale it's output accordingly
// now that you're done callibrating, turn callibration mode off
w.calibrate = false;
// The WiiOSCClient is set up to behave very much like a HID client and is furthermore
// designed for drop-in-place compatibility if anybody ever sorts out the WiiMote code
// that SuperCollider pretends to support.
// To get at a particular aspect of the data, you set an action per slot:
w.setAction(ax, {|val|
val.value; // is the scaled data from ax - the X axis of the accelerometre.
// It should be between 0-1, scaled according to how you waved your arms during
// the callibration period
});
// You can use a WiiRamp to provide some lag
(
r = WiiRamp (20, 200, 15);
w.setAction(ax, {|val|
var scaled, lagged;
scaled = ((val.value * 2) - 1).abs;
lagged = r.next(scaled);
// now do somehting with lagged
});
)
Calibration
this class is self-calibrating. It scales the wiimote input against the largest and smallest numbers that it’s seen thus far. While calibration is set to true, it does not call any of its action methods, as it assumes the calibrated numbers are bogus. After to set calibration to false, it does start calling the actions, but it still changes the scale if it sees a bigger or smaller number than previously.
WiiRamp
The WiiRamp class attempts to deal with the oddness of using accelerometers, but it does not just do a differentiation, as that would be too easy. The accelerometers give you major peaks and valleys, all centred around a middle, so just using the raw values often is a bit boring. In the example, you see that we scale the incoming data first: ((val.value * 2) – 1) changes the data range from 0 to 1 into -1 to 1. The puts the centre on 0. Then, because we care more about the height of peaks and depth of valleys than we care about whether they’re positive or negative, we take the absolute value, moving the scale back to 0 to 1.
When you shake your wiimote, the ramp keeps track of your largest gesture. It takes N steps to reach that max (updating if a larger max is found before it gets there), then holds at the number for M steps and then scoots back down towards the current input level. You can change those rates with upslope, hold and downslope.
OscSlot
This class is the one that might be useful to iPhone users. It creates an OSCResponderNode and then calls an action function when it gets something. It also optionally sends data to a Bus and has JIT support with a .kr method. It is modelled after some of the HID code. It also supports callibration. How to deploy it with TouchOSC is an exercise left to the reader.
http://www.berkeleynoise.com/celesteh/code/WiiOSCClient.sc
