soldering is such a nice relief from coding. for years i've had an old pc-joystick laying around (thank you abe). i knew i wanted to build something from it - something that would produce lovely noise - and yesterday i finally got around to hack it. the joystick now contains a slightly modified micro_noise synth circuit (based on a design by SGMK mechatronicart.ch). it also holds a 9v battery and the pc-connection cable now serves as sound output cable with standard 1/4 jack.

micro_noise_joy from redFrik on Vimeo.

i used the switches and potentiometers that the joystick had and it was very quick to build and cost me virtually nothing. i just cut some cables and soldered them onto a tiny circuit board together with a few components. see the schematics below. the only visible change is the jack output and a the led i mounted in the case.

this is a tiny project from about 1 year ago. i wanted to add extra ir-light for my dvcamera's nightshot mode. very useful when playing in dark and smoky clubs.
i bought 10 osram high power ir leds (SFH4550) and found 5 small resistors (47ohm). i run it off two 1,5v batteries
below a picture and the schematics.

today i built yet another micro_noise2 synths. this time inside a slightly strange bottle case. (thank you ap&bi)

absolut_micro_noise2 from redFrik on Vimeo.

[updated 090703: code examples updated for sc3.3.1 and swingosc0.62]

Audiovisuals with SC

Fredrik Olofsson

In this article we will investigate the built-in graphical features of SuperCollider and how they can be used artistically, in combination with the sound synthesis server. Different techniques for audiovisual mapping are presented along with some more personal reflections on the relationship between sound and graphics. My hope is that this text, together with the code examples, will provide inspiration for composers to work simultaneously in both the aural and the visual domain.

1 Introduction

It is clear that presenting any kind of visual stimuli in relation to music severely affects how we perceive the music. Often our experience is altered in more radical ways than we would like to acknowledge: "...one perception influences the other and transforms it. We never see the same thing when we also hear; we don’t hear the same thing when we see, as well" (Chion 1994, xxvi). Our goal as audiovisual composers should be to wisely utilize and direct these transformations. They become our material (Chion 1994; Collins and Olofsson 2006; Alexander and Collins 2007).
    Successful audiovisual pieces have the audience believe that sound and graphics truly exist in the same context. This is what Michel Chion calls the audiovisual contract (Chion 1994). How can we establish these contracts in our own work?
    As we will be coding both music and visuals, the most obvious way would be to share parameters between the sound and the graphics. So we do not just match sounds with visual events in time, but rather take the parameters that generate the graphics and let them also control aspects of the sound—or vice versa.

now using drupal 6.8. (prev 5.7). no stable audio module for 6.x just yet, so all my mp3s are hidden atm. in a few days i hope.

081219 edit: should be back up again now

We all know how fantastic the open-source movement is. How wonderful it is with all these people that distribute their code, schematics, data, ideas etc. for free and in such a spirit of openness. We gain so much from it and it is all really great.

But seen from the contributor's point of view, one could ask the questions: why share your hard-earned knowledge? What are the benefits and why spend a lot of time helping unknown people - often without even a thanks in return? Why give away code that you care about and that have taken lots of effort and hours to write - for free? Is it for personal fame? Is it the communal spirit or some political beliefs? Or the lack of interested commercial companies?

My personal and perhaps slightly provocative answer is that I share because of egoism / self-interest. I found that by making something public, I force myself to write more reusable and understandable code. Publicising means I will proof-read, add comments and help-files and perhaps cross platform support. Sharing also makes me reluctant to drastic change and help fixate things like interface, protocol and functionality. So after uploading code, I feel responsible to maintain it for the future throughout system and program upgrades - whether other people depend on it or not. It is the knowledge that someone _might be using it that is enough to put in that little extra effort and spend a few additional hours.
So for me as an independent software developer / artist, open-source is mainly a vehicle for caring about my own work. And it is the simple act of making it open and public that is so extremely helpful for me.

a fantastic present from tn8. thank you so much.
attached is the sc class to go with them.

{RedFrik.ar(2008)}.play   //noise socks!

during a recent gig i suddenly felt a need to crossfade between two songs/patches (strange as it seems). as i'd coded my music using RedMst and it in turn makes heavy use of class methods, starting up a new song would disrupt the current music playing (tempo, current index, etc). i also had some master effects running on bus 0 and 1 (ReplaceOut) that belonged to a particular song and i didn't want those for the new one.

so how to isolate patches? i got the idea of running two copies of the supercollider application at the same time. they'd be identical, use the same soundcard and share class library. having two apps running would also be good for safety reasons. if one crashed i could keep on playing with the other. it turned out to be quite easy. the trick is to use the internal server and find a way to visually tell the two applications apart.
dan stowell helped me by implementing thisProcess.pid and i got some great tips from cylob. he used a similar setup for his live performances. here's my take on it... (you'll need a recent version of supercollider (>30oct '08)

1. put the code below into your startup.rtf file. it'll make the secondary app green and shift windows to the right - this only so one can tell them apart.
2. go to supercollider application folder and duplicate the program file (cmd+d). rename the copy "SuperCollider (green)". remember to duplicate again when you've updated your main sc app.
3. important: from now on use internal as the default server in your code. localhost will crosstalk when running multiple apps.

RedMst, RedTrk, RedTrk2 and RedSeq are a set of supercollider classes that i now finally cleaned up and released. i wrote them about a year ago and have been using them for live performances since then. they function as sort of a timeline and the basic idea is to sequence code in a very simple way.
the master keeps track of when some tracks should play and then switches them on/off with .play and .stop at the right time (next quant beat, default= 4). a track can be any code that responds to these two messages (pbind, bbcut2, pdef, routines, etc).

redMst is distributed as a quark. see Quarks helpfile for more info on how to install.

Quarks.checkoutAll
Quarks.gui

i have constructed a wireless sensor system for my performance costume. it has 2 accelerometers (3-axis adxl330, sparkfun - same as in the wii remote i believe) and 4 switches (digital). both master and slave uses a microcontroller (atmega8, atmel) and a transceiver (mirf v2, sparkfun).
below is a short video, some pictures, supercollider classes and also the schematics and the complete firmware if you want to build the thing yourself.

redUniform-hardwareWireless from redFrik on Vimeo.

the avr programmer (usbtinyisp kit v2.0) and the electronic parts needed...

the master and slave...

sensors sewn in...

081008 update: slave firmware and slave schematics updated - added 2 more switches (pd6 and pd7)
081010 update: also attached the supercollider class RedUniform.sc with helpfile