Liveblogging SC: live coding with assembler

Dave – 

Esoteric programming languages are an interesting thing we might care about.

CPUs in mine craft – you can see the processing.

Space invaders assembler with lines showing the order of execution.

Very slow execution can show what’s going on. This can be sonified.

 Till – 

BetaBlocker is a quark in sc3-plugins

(talk to him if you want to go work in helsinki)

BBlocker never crashes, but it  might not do anything.  It has a stack and a heap and a program counter.

This is like Dave’s grid on the DS, where it runs in an infinite loop.

UGens

DetaBlockerBuf – is a demand rate UGen. So you can do weird computations in your ugen?  It does a programming step everytime it gets triggered.

The programs are stored in buffers. You can do random ones.

There is also a visual thingee.

BBlockerBuf exposes the stack and the program counter.

BBlockerProgram holds a beta blocker program for the assembler. 

You can create a program with the assembler code.  you can play the program.

BetaBlockerProgram([NOP, POP, ADD]) etc

Tom Hall – 

John Cage would be 100 this year.

A metaphorically digital, constrained, sonic system. An invitation to listen

Questions

  • Is the heap a wave table? No, the output of the program is the sound.
  • Is it a coincidence that it sounds like putting a induction coil on a laptop?  Um, maybe. He says it sounds very 8-bit-y. Maybe because it’s 8bit.
  • Is it easy to write logical seeming programs, or are they mostly random? It is possible to write things that make sense. The fun of it is the weirdness and things getting trashed by accident.  Dave is going genetic programing with a system like this.
  • The output is one byte at a time? No, each step does something and the output is something I didn’t understand.
  • Graphics question? Not Till’s field.

I think this could be really useful for student or teenagers who are sort of intereted in programming.

LiveBloggin the SC symposium: Keynote – Takeko Akamatsu

Using SC since 2000.

Main project is Craftwife. (All members are housewives, she says).  Going since 2008.  There are 5 members now. They are between pop and art culture.

She started initially doing demos of Remkon, an iOS OSC app.  How to make this popular? 

  • Borrow the image of something already famous – Karftwerk.
  • What is Originality? – SC patterns
  • Crash of music industry – live to record, record to live. Craftwife should be live only

Influenced by “the Work of Art in the Age of Mechanical Reproduction”

She makes extensive use of PatternProxies

She also works with Craftwife + Kaeso+.  Kaseo+ is a circuit bender.  she controls strobe lights, analogue synthesier, etc.

SuperCollider.jp

SC in Japan. They have a meetup in Tokyo. She posts on twitter. She does workshops.

During her show in the Hague in 2007, she got frustrated and smashed her computer. And then quit making computer music for a year and grew vegetables.

She held a workshop at a place called the WombLounge.  Not everyone was a musician. She covered interaction between many environments.

SuperColliderSpeedCodingShow

She will give people a theme and five minutes and they have to make a sound.

4 people are quickly coding something on the theme of spring.

SuperCollider.future

She wants the book in an eBook in Japanese.

SuperCollider.cycling

She has attached a sensor to her exercise bike and uses this during her workout routine.

She’s tired of loud sounds. And sound systems are annoying.

She played a video of JMC saying what he wants for sc4. It’s not client server and it’s a lot smaller.

Liveblogging the SuperCollider Symposium: SC AU UI

by Jan Trüzschler and Zlatko Brackski

This is the SuperCollider Audio Unit User Interface Library, which enables the creation of custom user interfaces for Audio Units built in SC.

You can use AU stuff in live or Logic and having a nice GUI can enhance the user experience.  Mapping controls can increase the complexity possible with the AU library.

This is MAC-only, as it uses Objective C.

The interface has some grey boxes and is editable. 

This is not yet added to the main SCAU library yet, as it needs to be merged with the SCAU lib.  The UI library needs some work. There needs to be some documentation.

Examples

This would be cool, but the GUI is really obtuse. 

You can download this stuff from BCU via TEE DMT. Or this will be released in a more normal way.

Questions

  • Where is the lovely GUI coming from? Objective C, so you can’t do your own version in SuperCollider
  • Why is this a one-time library install rather than packaged in the component? Jan thought it would be easier to do an installer.  They’re not difficult to distribute.
  • Can the AUUI controller thing use sidechains? Not yet.

Live Blogging the SuperCollider Symposium: Freesound Quark

By Gerard Roma

Uses the Freesound Website. www.freesound.org. The sounds are Creative Commons.  The website has more than 150,000 sounds from around 4000 users.  Most users only download sounds.  All sounds are moderated – listened to by a human.

I’m always charmed when a presenter shows a supercollider window rather than using a slide programme.  The syntax highlighting of their talk notes is especially good.

Google gave them a grant and they re-wrote the site.  They have a feature extraction library to analyse the sounds.

There is a new freesound quark based on their API.  The quark will give you the sound, the sound’s preview, the tags, the spectrogram, the signal descriptors from freesound’s feature extraction.

You need to get an API key to use the quark. The quark will search stuff for you according to filters. You can find a sound that’s glitchy with a particular duration.  You can search by similarity as well.

The analysis frames of the sound are kept in a separate file, but can be loaded into an IdentityDictionary.

This quark could be really interesting if you want to do stuff with freesound, you don’t need to do your own MIR and you might be able to make cool pieces in real time.

Questions

  • Are people doing cool things with this outside of SuperCollider?  He doesn’t know.
  • Will the API upload to freesound? No.  The API needs some more authentication stuff put in. Also the moderation creates a delay.
  • Zlatko wants to know about how they know if sounds are copyrighted.  The moderators try to figure it out and respond to complaints.
  • Can the same API key be used across multiple computers? Yes.
  • Does the metadata include the licence terms and the user who uploaded it? Yes
  • Is there a GUI? No, this is a new quark, not the old one.

Dissertation Draft: BLE Tech

In January 2011, five of my colleagues in BEAST and I founded BiLE, the Birmingham Laptop Ensemble. All of the founding members are electroacoustic composers, most of whom have at least some experience with an audio programming language, either SuperCollider or MAX. We decided that our sound would be strongest if every player took responsibility for their own sound and did his or her own audio programming. This is similar to the model used by the Huddersfield Experimental Laptop Orchestra (HELO) who describe their approach as a “Do-It-Yourself (DIY) laptop instrument design paradigm.” (Hewitt p 1 http://helo.ablelemon.co.uk/lib/exe/fetch.php/materials/helo-laptop-ensemble-incubator.pdf) Hewitt et al write that they “[embrace] a lack of hardware uniformity as a strength” and implies their software diversity is similarly a strength and grants them greater musical, (rather than technical) focus. (ibid) BiLE started with similar goals – focus on the music and empower the user, and has had similar positive results.

My inspiration, however, was largely drawn from The Hub, the first laptop band, some members of which were my teachers at Mills College in Oakland California. I saw them perform in the mid 1990s, while I was still an undergrad and had an opportunity then to speak with them about their music. I remember John Bischoff telling me that they did their own sound creation patches, although for complicated network infrastructure, like the Points of Presence Concert in 1987, Chris Brown wrote the networking code. (Cite comments from class?)

One of the first pieces in BiLE’s repertoire was a Hub piece, Stucknote by Scott Gresham Lancaster. This piece not only requires every user to create their own sound, but also has several network interactions including a shared stopwatch, sending chat messages and the sharing of gestural data for every sound. In Bischoff and Brown’s paper, the score for Stucknote is described as follows:

“Stuck Note” was designed to be easy to implement for everyone, and became a favorite of the late Hub repertoire. The basic idea was that every player can only play one “note”, meaning one continuous sound, at a time. There are only two allowable controls for changing that sound as it plays: a volume control, and an “x-factor”, which is a controller that in some way changes the timbral character or continuity of the instrument. Every player’s two controls are always available to be played remotely by any other player in the group. Players would send streams of MIDI controller messages through the hub to other players’ computer synthesizers, taking over their sounds with two simple control streams. Like in “Wheelies”, this created an ensemble situation in which all players are together shaping the whole sound of the group. An interesting social and sonic situation developed when more than one player would contest over the same controller, resulting in rapid fluctuations between the values of parameters sent by each. The sound of “Stuck Note” was a large complex drone that evolved gradually, even though it was woven from individual strands of sound that might be changing in character very rapidly. (http://crossfade.walkerart.org/brownbischoff/hub_texts/stucknote.html)

Because BiLE was a mostly inexperienced group, even the “easy to implement for everyone” Stucknote presented some serious technical hurdles. We were all able to create the sounds needed for the piece, but the networking required was a challenge. Because we have software diversity, there was no pre-existing SuperCollider Quark or MAX external to solve our networking problems. Instead, we decided to use the more generic music networking protocol Open Sound Control (OSC). I created a template for our OSC messages. In addition to the gestural data for amplitude and x-factor, specified in the score, I thought there was a lot of potential for remote method invocation and wanted a structure that could work with live coding, should that situation ever arise. I wrote a white paper (see attached) which specifies message formatting and messages for users to identify themselves on the network and advertise remotely invokable functions and shared data.

When a user first joins the network, she advertises her existence with her username, her IP address and the port she is using. Then, she asks for other users to identify themselves, so they broadcast the same kind of message. Thus, every user should be aware of every other user. However, there is currently no structure for users to quit the network. There is an assumption, instead, that the network only lasts as long as each piece. SuperCollider users, for example, tend to re-compile between pieces.

Users can also register a function on the network, specifying a OSC message that will invoke it. They advertise these functions to other users. In addition, they can share data with the network. For example, with Stucknote, everyone is sharing amplitude values such that they are controllable by anyone, including two people at the same time. The person who is using the amplitude data to control sound can be thought of as the owner of the data, however, they or anyone else can broadcast a new value for their amplitude. Typically, this kind of shared data is gestural and used to control sound creation directly. There may be cases where different users are in disagreement about the current value or packets may get lost. This does not tend to cause a problem. With gestural data, not every packet is important and packet loss is not a serious issue.

When a user puts shared data on the network, she also advertises it. Users can request to be told of all advertised data and functions. Typically, a user would request functions and shared data after asking for ids, upon joining the network. She may ask again at any time. Interested users can register as listeners of shared data. The possibility exists, (currently unused), for the owner of the data to send its value out on to registered users instead of the network as a whole.

In order to implement the network protocol, I created a SuperCollider class called NetAPI (see attached code and help file). It handles OSC communications and the infrastructure of advertising and requesting ids, shared functions and shared data. In order to handle notifications for shared data changes, I wrote a class called SharedResource. When writing the code for Stucknote, I had problems with infinite loops with change notifications. The SharedResource class has listeners and actions, but the value setting method also takes an additional argument specifying what is setting it. The setting object will not have it’s action called. So, for example, if the change came from the GUI, the SharedResource will notify all listeners except for the GUI. When SharedResources “mount” the NetAPI class, they become shared gestural data, as described above.

Kinect and OSC Human Interface Devices

To make up for the boring title of this post, lets’s start off with a video:

XYZ with Kinect a video by celesteh on Flickr.

This is a sneak preview of the system I wrote to play XYZ by Shelly Knotts. Her score calls for every player to make a drone that’s controllable by x, y, and z parameters of a gestural controller. For my controller, I’m using a kinect.

I’m using a little c++ program based on OpenNi and NITE to find my hand position and then sending out OSC messages with those coordinates. I’ve written a class for OSCHIDs in SuperCollider, which will automatically scale the values for me, based on the largest and smallest inputs it’s seen so far. In an actual performance, I would need to calibrate it by waving my arms around a bit before starting to play.

You can see that I’m selecting myself in a drop down menu as I start using those x, y and z values. If this had been a real performance, other players names would have been there also and there is a mechanism wherein we duel for controls of each other’s sounds!

We’re doing a sneak preview of this piece on campus on wednesday, which I’m not allowed to invite the public to (something about file regulations) but the proper premiere will be at NIME in Oslo, on Tuesday 31st May @ 9.00pm atChateau Neuf (Street address: Slemdalsveien 15). More information about the performance is available via BiLE’s blog.

The SuperCollider Code

I’ve blogged about this earlier, but have since updated WiiOSCClient.sc to be more immediately useful to people working with TouchOSC or OSCeleton or other weird OSC devices. I’ve also generated several helpfiles!
OSCHID allows one to describe single OSC devices and define “slots” for them.
Those are called OscSlots and are meant to be quite a lot like GeneralHIDSlots, except that OSCHIDs and their slots do not call actions while they are calibrating.
The OSC WiiMote class that uses DarWiinRemote OSC is still called WiiOSCClient and, as far as I recall, has not changed its API since I last posted.
Note that except for people using smart devices like iPhones or whatever, OSC HIDs require helper apps to actually talk to the WiiMote or the kinect. Speaking of which…

The Kinect Code

Compiling / Installing

This code is, frankly, a complete mess and this should be considered pre-alpha. I’m only sharing it because I’m hoping somebody knows how to add support to change the tilt or how to package this as a proper Mac Application. And because I like to share. As far as I know, this code should be cross-platform, but I make no promises at all.
First, there are dependencies. You have to install a lot of crap: SensorKinect, OpenNi and NITE. Find instructions here or here.
Then you need to install the OSC library. Everybody normally uses packosc because it’s easy and stuff…. except it was segfaulting for me, so bugger that. Go install libOSC++.
Ok, now you can download my source code: OscHand.zip. (Isn’t that a clever name? Anyway…) Go to your NITE folder and look for a subfolder called Samples. You need to put this into that folder. Then, go to the terminal and get into the directory and type: make. God willing and the floodwaters don’t rise, it should compile and put an executable file into the ../Bin directory.
You need to invoke the program from the terminal, so cd over to Bin and type ./OscHand and it should work.

Using

This program needs an XML file which is lurking a few directories below in ../../Data/Sample-Tracking.xml. If you leave everything where it is in Bin, you don’t need to specify anything, but if you want to move stuff around, you need to provide the path to this XML file as the first argument on the command line.
The program generates some OSC messages which are /hand/x , /hand/y and /hand/z, all of which are followed by a single floating point number. It does not bundle things together because I couldn’t get oscpack to work, so this is what it is. By default, it sends these to port 57120, because that is the port I most want to use. Theoretically, if you give it a -p followed by a number for the second and third arguments, it will set to the port that you want. Because I have not made this as lovely as possible, you MUST specify the XML file path before you specify the port number. (As this is an easy fix, it’s high on my todo list, but it’s not happening this week.)
There are some keyboard options you can do in the window while the program is running. Typing s turns smoothing on or off. Unless you’re doing very small gestures, you probably want smoothing on.
If you want to adjust the tilt, you’re SOL, as I have been unable to solve this problem. If you also download libfreenect, you can write a little program to aim the thing, which you will then have to quit before you can use this program. Which is just awesome. There are some Processing sketches which can also be used for aiming.
You should be able to figure out how to use this in SuperCollider with the classes above, but here’s a wee bit of example code to get you started:




 k = OSCHID.new.spec_((
  ax: OscSlot(realtive, '/hand/x'),
  ay: OscSlot(realtive, '/hand/y'),
  az: OscSlot(realtive, '/hand/z')
  ));

 // wave your arms a bit to calibrate

 k.calibrate = false;

 k.setAction(ax, { |val|  val.value.postln});

And more teaser

You can see the GUIs of a few other BiLE Tools in the video at the top, including the Chat client and a shared stopwatch. There’s also a network API. I’m going to do a big code release in the fall, so stay tuned.

Strategies for using tuba in live solo computer music

I had the idea of live sampling my tuba for an upcoming gig. I’ve had this idea before but never used due to two major factors. The first is the difficulty of controlling a computer and a tuba at the same time. One obvious solution is foot pedals, which I’ve yet to explore and the other idea is a one-handed, freely moving controller such as the wiimote.
The other major issue with doing tuba live-sampling is sound quality. Most dynamic mics (including the SM57, which is the mic I own) make a tuba sound like either bass kazoo or a disturbingly flatulent sound. I did some tests with the zoom H4 positioned inside the bell and it appeared to sound ok, so I was going to do my gig this way and started working on my chops.
Unfortunately, the sound quality turns out not to be consistent. The mic is prone to distortion even when it seems not to be peaking. Low frequencies are especially like to contain distortion or a rattle which seems to be caused by the mic itself vibrating from the tuba.
There are a few possible work arounds. One is to embrace the distortion as an aesthetic choice and possible emphasise it through the use of further distortion fx such as clipping, dropping the bit rate or ring modulation. I did a trial of ring modulating a recorded buffer with another part of the same buffer. This was not successful as it created a sound lurking around the uncanny valley of bad brass sounds, however a more regular waveform may work better.
At the SuperCollider symposium at Wesleyan, I saw a tubist (I seem to recall it was Sam Pluta, but I could be mistaken) deliberately sampling tuba-based rattle. The performer put a cardboard box over the bell of the tuba. Attached to the box was a piezo buzzer in a plastic encasing. The composer put a ball bearing inside the plastic enclosure and attached it to the cardboard box. The vibration of the tuba shook the box which rattled the bearing. The piezo element recorded the bearing’s rattle, which roughly followed the amplitude of the tuba, along with other factors. I thought this was a very interesting way to record a sound caused by the tuba rather than the tuba itself.
Similarly, one could use the tuba signal for feature extraction, recognising that errors in miccing the tuba will be correlated with errors in the feature extraction. Two obvious thing to attempt to extract are pitch and amplitude, the latter being somewhat more error-resistant. I’ve described before an algorithm for time-domain frequency detection for tuba. As this method relies on RMS, it also calculates amplitude. Other interesting features may be findable via FFT-based analysis such as onset detection or spectral centroid, etc using the MLCD UGens. These features could be used to control the playing of pre-prepared sounds or live software synthesis. I have not yet experimented with this method.
Of course, a very obvious solution is to buy a better microphone. It may also be that the poor sound quality stemmed from my speakers, which are a bit small for low frequencies. The advantage of exploring other approaches include cost (although a tuba is not usually cheap either) and that cheaper solutions are often more durable or at least I’d be more willing to take cheaper gear to bar gigs (see previous note about tuba cost). As I have an interest in playing in bars and making my music accessible through ‘gigability,’ a bar-ready solution is most appealing.
Finally, the last obvious solution is to not interact with the tuba’s sounds at all, thus creating a piece for tuba and tape. This has less that can go wrong, but it looses quit a lot of spontaneity and requires a great deal of advance preparation. A related possibility is that the tubist control real-time processes via the wiimote or other controller. This would also require a great deal of advanced preparation – making the wiimote into it’s own instrument requires the performer to learn to play it and the tuba at the same time, which is rather a lot to ask, especially for an avant guarde tubist who is already dealing with more performance parameters (such as voice, etc) than a typical tubist. This approach also abandons the dream of a computer-extended tuba and loses whatever possibilities for integration exist with more interactive methods. However, a controller that can somehow be integrated into the act of tuba playing may work quite well. This could include sensors mounted directly on the horn such that, for example, squeezing something in a convenient location, extra buttons near valves, etc.
I’m bummed that I won’t be playing tuba on thursday, but I will have something that’s 20 minutes long and involves tuba by September

WiiOSCClient.sc

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

First BiLE Performance

BiLE, the Birmingham Laptop Ensemble, had it’s first gig on Thursday, just six or eight weeks after being formed. We played at the Hare and Hounds in Birmingham, which is a well-known venue for rock bands, as a part of the Sound Kitchen series. There were two pieces on the bill, one called 15 Minutes for BiLE by BiLE member Jorge Garcia Moncada and we did a cover of Stucknote by Scot Gresham-Lancaster, which was a piece played by The Hub.
As a first performance, I thought it went rather well. There were the usual issues where everything sounds completely different on stage and the few minutes of sound checking does not give anybody enough time to get used to the monitor speakers. And time moves completely differently in front of an audience, where suddenly every minute gets much longer. But there were also the performing-with-a-computer issues: computers get terrible stage fright and are much more prone to crash. A few people did have their sound engines crash, so the first piece had a high pitched squeal for a few minutes, while messages flew on the chat window, reminding people to be quiet during the quiet parts. Actually, there was quite a lot of panic in the chat window and I wish I’d kept a log of it. (Later the audience said we all looked panicked from time to time. I always look panicked on stage, but it’s not cool.) In the second piece, I forgot to tell my programme to commence sound-making for a bout the first three minutes. I haven’t heard the recording yet, but I bet things sounded ok. Considering that most of us had never done live laptop performance at all before and how quickly we went from our first planning meeting to our first gig, I think we got a good result.
Jorge’s piece was complicated but Stucknote seems deceptively simple, so we did not try running through it until the day before the gig. In retrospect, this was clearly an error, because the piece, like all structured improvisation, does require some practice to get the flow down. Of course, we’d all spent the requisite time working on our sound generation and I’d coded up some faders for me and the other SuperCollider user, with Ron Kuivila’s Conductor quark, which is a very quick and dirty was of making useful GUIs. I’d tried out my part at home and it worked well and the sound I got was interesting, so I felt confident in it until I got to the practice and it crashed very quickly. I restarted SuperCollider and it crashed again. And again. And again. Half the time, it brought down the other SC user’s computer also. And it was clobbering the network, causing the MAX users a bunch of error messages and a few moments of network congestion. MAX, usefully, just throws away network messages when there are too many of them, whereas SC does not seem to.
I could not figure out where the bug was and so, after the practice, I sat down to sort it out. And there was no sign of it. Everything was fine again.
Fortunately, this provided enough of a clue that I was able to figure out that I had created an infinite loop between the two SuperCollider programmes. When I moved a slider in the GUI, that sent a message to the network which effected the sound on the target machine and also caused Shelly’s programme to update the GUI. However, the Conductor class always informs listeners when it’s updated, no matter who updated it or how, so it sent a message back to the network informing everybody of it’s new value, which caused my GUI to update, which sent a message to the network, ad infintum until I crashed.
I came up with a fix using a flag and semaphores:

                   Task({
                             semaphore.wait;
                             should_call_action = false;
                             cv = con[contag];
                             cv.input = input;
                             should_call_action = true; 
                             semaphore.signal;
                     }).play;
 

While this fix mostly works, it does bring up some interesting questions about data management across this kind of network. If we’re all updating the data at once, is there a master copy of it somewhere? Who owns the master copy if one exists? In this case, as one person is making sound from it, that person would seem to be the owner of the data. But what if we were all sharing and using the sliders? Then we all own it and may all have different ideas of what it might actually be.
I’m writing a class for managing shared resources which holds a value and notifies listeners when it changes. The object that’s changing it passes itself along to the method, so when listeners are notified, the changer is not. I haven’t finished the class yet, so I don’t have sample code, but I’m pondering some related issues.
Like, should there be a client version of this class for a local copy held on the local machine and a master version for the canonical copy on the network that everybody else is updating? Should a master copy of some data advertise itself on the network via the API and automatically listen for updates? Should they specify a way to scale values so it can also accepted changed inputs from 0-1 and scale them appropriately? If it does accept inputs/values in a specified range, should there be a switch for the clients to automagically build a GUI containing sliders for every master variable on the network? I think that would be quite cool, but I may not have time to code it soon, as our next gig, where we’ll be playing a piece of mine, is coming up very soon on 29 of April and then there’s a gig in May and then I suspect probably one in June and one in July (although not scheduled yet) and in August, we’re going to NIME in Oslo, which is very exciting. Bright days ahead.

Semaphores are awesomesauce

Imagine, if you will, that you are a programmer and somebody has asked you to write an application that counts cars in intersections. You have webcams mounted on top of the traffic lights and it sends you a message when it sees a car. You have saved somewhere a count of all the cars so far. So, when it tells you it sees a car, you go find that number, add one to it and write down the new number. There is more than one camera in the intersections, though and while some cars are travelling north, others are travelling south at the same time. What if two cameras see different cars at the same time?

  1. Camera one sees a car and the programme listening to it goes and finds the count of cars so far, which is 75.
  2. Camera two sees a car and the programme listening to it goes and finds the count of cars so far, which is 75.
  3. Camera one’s programme adds one to the total and gets 76.
  4. Camera two’s programme adds one to the total and gets 76.
  5. Camera one’s programme saves it’s new total.
  6. Camera two’s programme saves it’s new total.
  7. You go to look how many cars have been through the intersection and the number recorded is 76.

Camera one and camera two are operating separately from each other at the same time. They are sperate threads. when two of them are trying to change the same resource at the same time, you get something called a race condition. Will the first thread finish before the second thread clobbers it’s changes? The race is on!
Fortunately, there is a solution to this problem: semaphores! Lets’ say you are trying to update your traffic count with SuperCollider:

(
 var traffic_count, camera1, camera2, semaphore, action;

 traffic_count = 0;
 semaphore = Semaphore.new(1);

 camera1 = TrafficCounterCamera(north);
 camera2 = TrafficCounterCamera(south);

 action = { // this will be called when a car is seen
  Task({
   semaphore.wait; // only one thread can get past this point at a time
   traffic_count = traffic_count +1;
   semaphore.signal; // relinquish control of the semaphore
   traffic_count.postln;
  }).play;
 };

 camera1.action = action;
 camera2.action = action;
)

You need to make a new Semaphore before you use it. By default, they allow one thread through at a time, but you can change the argument to 2 or 3 or whatever number you want.
When your code encounters a semaphore.wait, the thread will pause and wait until it’s turn to procede. Only one thread will be allowed past that line at a time. If both cameras update at the exact same time, one of them will have to wait until the other says it’s good to go ahead.
semaphore.signal is how that thread says it’s good to go ahead. The code in between those lines can only be accessed by a single thread at a time. the traffic_count.postln line is outside the seamphore because it’s not making a change to anything, so it’s safe to read it outside of the semaphore.
So when you have two seperate threads trying to change something at the same time, semaphors can help you out! This sort of situation can arrive with GUI objects, or with OSC messages, HID objects or anything with an action method.
Be thread-safe!