« Andy Schmeder : micro-OSC | Back to frontpage | Sukandar Kartadinata »

Session 2: Modern Sensor Interfaces

Ahhh… A rainy day in Amsterdam - perfect excuse sitting inside a cozy STEIM concert room with music tech peeps! Me myself, I woke up a bit late for free breakfast at the hotel - typical - but it gave me a good excuse to walk around a bit in the morning, finding a decent coffee shop. The flower shops on the canal bridges are selling pine-scented things a plenty, and the rain seemed to amplify the wonderful smell… Anyhow…

Woot woot!! STEIM jamboree in session!

Sukandar Kartadinata (Instrument Designer, Gluion Developer)

Sukandar Kartadinata

First up - Sukandar Kartadinata. Sukandar develops and sometimes actually uses his own glui. This interface, STEIM’s Sensor Lab and the Arduino are his main reference points for classically architected sensor interfaces, i.e.: Where there’s a bunch of data being fed to a computer for multimedia control or similar. He spent some time working through justifications for FPGA sensor interfaces and economic justifications for this interface or that. I thought the most interesting thing he alluded to was that technologist working in this sphere are increasingly finding that their role is one of facilitator, or more ‘relational’ to the work being created. Hopefully this outlook will help avoid all-to-frequent discussions within the community about generalized electronic interface superiority or motivation. There are no perfectly generalizable technologies for artists - never have been. Only technologies which serve a context and purpose at a given time.

  • FPGA strategies for sensor and hardware output. Microcontrollers vs. FPGA
    • E.g.: Massive number of PWM outputs for motor control, where the arduino gives you a set number of outputs, with fixed resolution. So, how to do this? Could buy a bunch of microcontrollers, but could have an FPGA do this easily - as long as it fits into the FPGA chip.
    • There are things you can get from FPGA you can’t get from microcontrollers, and microcontrollers also have more functionality than necessary for sensor interfaces (e.g.: APU, for loops, etc., are ). Mostly, for Sukandar, one only needs the interface to spit the data out to a computer, where the main processing is done. (Historical note - back when there were bandwidth issues between the interface hardware and the computer, we had to do more processing on the hardware, e.g.: with MIDI - but now we have high-bandwidth USB)
  • The FPGA argument: Precise definition of the system
    • Precision (ADC and sampling frequency)
    • Concurrency (PWM don’t hold the process)
    • Fine-tuning
    • Unique functionality (by the way - FPGAs are programmable microcontrollers)
    • Portability (Across FPGAs development can be transfered across newer devices)

Defining the problem as a kind of ‘analog inputs per dollar’ - bang for your buck - Sukandar notes that you can buy one Glui for the cost of 18 Arduinos. He also considers the idea that the Glui is not open source, and posits that its open source-ness is probably what made the Arduino so popular (as the technology is the same as what you get from a Miditron, CreateUSB, etc.

arduino glui

  • Projects
    • Sun Run Sun (gumsticks, Linux, PD)
    • Nagelsensortisch (IR sensor, keyboard as sensor interface)
    • MotorBeast (PWM, 32-channels for B.E.A.S.T.)
    • Zweite Konservatorisch Massnahme (IR-sensor,relays)
    • Savvy (Barcode Sensor)
    • Wormhole Dordrecht (iPhone, GPS, polyphonic sound)
    • eMotion (GST&heart reate-sensors)
    • Red PSI Donkey (acoustic camera (beamforming), piezos, ultrasound, Max/MSP)
    • Mantis Nautilus (optical encoder, navigation interface)
    • 3D-Wheel (arduinoBT, pressure+position sensors, general interface for

Sukandar’s activities are leaning towards the creation of bespoke projects - not developing interfaces in a general way. Nice to see more and more hardware developers coming to this general contemporary learning - that the very nature of the kinds of projects we make, pretty much precludes the idea of a generalized interface, as said. User-centered design (”usability”) is as a result not a big an issue for Sukandar’s work - as his role in the creative cycle is more in working directly implementing projects in collaboration.

  • Glui plans
    • CV output (PWM output can do this, but not very accurate)
    • more wireless
    • ADAT (for transfer to the computer)
    • Audio (output to the computer)
    • Gain and Offset control
    • Modular design


Andy Schmeder (CNMAT Researcher, Developer of uOSC)


 Andy Schmeder

Andy notes the technology/music strategy at CNMAT - the most elegant idea he put forward right off is that although technology is able to drive artistic innovation, music also provides a bunch of interesting problem sets to the technical community… Nice reminder of this symbiotic relationship, not often voice so well. Cheers Andy!

We then were presented with a rather stupifying diagram highlighting the big motivations for the larger project (which I’ve noticed Andy has just posted above - nice!).

Andy Schmeder
  • Cost minimization
  • Eliminate unnecessary difficulty - technical mumbo jumbo, time sensitivity problems
  • Eliminate microcontroller coding - its hard and stupid
  • User friendly interfaces - semantic models for intuitive sensor routing and mapping

Andy’s specifically interested in the micro-OSC piece of the puzzle - i.e.: USB OSC:

  • Implemented on a PIC microchip (PIC18F)
  • 13 Analog in
  • 16 Digital I/O
  • Support for
    • Olimex PiC - 60 bucks
    • CUI PIC - 50 bucks
    • Sparkfun “Bitwacker” - 25 bucks

We then heard about where the micro-OSC system sits in terms of system topology and functionality, as well as some serious detail about OSC message construction. Also we heard about some performance stats, and some strategies for time stamping the transfer to reduce jitter.

There was a bit of criticism of ‘throwing things together” , as being “not a very scientific way of looking at your data.” Andy figures that when you’ve spend more time with these sensor systems - you discover resolution and accuracy (in the engineering sense) are more and more important.

There were some questions at the end about OSC’s hardware - what used to be nice about it was that it was an ethernet based standard (better connectors, etc.). USB use does give the ability to have multiple devices on a hub…

Ahhh… A rainy day in Amsterdam - perfect excuse for sitting inside a cozy STEIM concert room with music tech peeps! Me myself, I woke up a bit late for free breakfast at the hotel - typical - but it gave me a good excuse to walk around a bit in the morning, finding a decent coffee shop. The flower shops on the canal bridges are selling pine-scented things a plenty, and the rain seemed to amplify the wonderful smell… Anyhow…

Woot woot!! STEIM jamboree in session!

Sukandar Kartadinata (Instrument Designer, Gluion Developer)

Sukandar Kartadinata

First up - Sukandar Kartadinata. Sukandar develops and sometimes actually uses his own glui. This interface, STEIM’s Sensor Lab and the Arduino are his main reference points for classically architected sensor interfaces, i.e.: Where there’s a bunch of data being fed to a computer for multimedia control or similar. He spent some time working through justifications for FPGA sensor interfaces and economic justifications for this interface or that. I thought the most interesting things he alluded to was that technologist working in this sphere are increasingly finding that their role is one of facilitator, or more ‘relational’ to the work being created. Hopefully this outlook will help avoid long discussions within the community about generalized electronic “interface” superiority and motivation. There are no perfectly generalizable technologies for artists! Only technologies which serve a context and purpose at a given time.

  • FPGA strategies for sensor and hardware output. Microcontrollers vs. FPGA
    • E.g.: The PWM output for motor control, the arduino gives you a set number of outputs, with fixed resolution. How to do this? Could buy a bunch of microcontrollers, but could have an FPGA do this easily - as long as it fits into the chip.
    • There are things you can get from FPGA you can’t get from microcontrollers, and microcontrollers also have more functionality than necessary for sensor interfaces (e.g.: APU, for loops, etc., are ). Mostly, for Sukandar, one only needs the interface to spit the data out to a computer, where the main processing is done. (Historical note - back when there were bandwidth issues between the interface hardware and the computer, we had to do more processing on the hardware, e.g.: with MIDI - but now we have high-bandwidth USB)
  • The FPGA argument: Precise definition of the system
    • Precision (ADC and sampling frequency)
    • Concurrency (PWM don’t hold the process)
    • Fine-tuning
    • Unique functionality (by the way - FPGAs are programmable microcontrollers)
    • Portability (Across FPGAs development can be transfered across newer devices)

Defining the problem as a kind of ‘analog inputs’ for your dollar - the engineer’s bang for your buck - Sukandar notes that you can buy one Glui for the costs of 18 Arduinos. He also considers the idea that the Glui is not open source, and posits that this open source-ness is probably what made the Arduino so popular (as the technology is the same as what you get from a Miditron, CreateUSB, etc.

arduino glui

  • Projects
    • Sun Run Sun (gumsticks, Linux, PD)
    • Nagelsensortisch (IR sensor, keyboard as sensor interface)
    • MotorBeast (PWM, 32-channels for B.E.A.S.T.)
    • Zweite Konservatorisch Massnahme (IR-sensor,relays)
    • Savvy (Barcode Sensor)
    • Wormhole Dordrecht (iPhone, GPS, polyphonic sound)
    • eMotion (GST&heart reate-sensors)
    • Red PSI Donkey (acoustic camera (beamforming), piezos, ultrasound, Max/MSP)
    • Mantis Nautilus (optical encoder, navigation interface)
    • 3D-Wheel (arduinoBT, pressure+position sensors, general interface for

Sukandar’s interests are leaning towards the creation of bespoke projects - not developing interfaces in a general way. Nice to see more and more hardware developers understanding this - that the very nature of the kinds of projects we make, pretty much precludes the idea of a generalized interface, as I said. User-centered design (”usability”) is not a big an issue for Sukandar’s work - as his role in the creative cycle is more in working directly implementing projects in collaboration.

  • Glui plans
    • CV output (PWM output can do this, but not very accurate)
    • more wireless
    • ADAT (for transfer to the computer)
    • Audio (output to the computer)
    • Gain and Offset control
    • Modular design


Andy Schmeder (CNMAT Researcher, Developer of uOSC)


 Andy Schmeder

Andy notes the technology/music strategy at CNMAT - the most elegant idea he put forward right off is that although technology is able to drive artistic innovation, music also provides a bunch of interesting problem sets to the technical community… Nice symbiotic idea, not often voice so well. Cheers Andy!

We then were presented with a rather stupifying diagram highlighting the big motivations for the larger project (which I’ve noticed Andy has just posted above - nice!).

Andy Schmeder

  • Cost minimization
  • Eliminate unnecessary difficulty - technical mumbo jumbo, time sensitivity problems
  • Eliminate microcontroller coding - its hard and stupid
  • User friendly interfaces - semantic models for intuitive

Andy’s specifically interested in the micro-OSC piece of the puzzle - i.e.: USB OSC:

  • Implemented on a PIC microchip (PIC18F)
  • 13 Analog in
  • 16 Digital I/O
  • Support for
    • Olimex PiC - 60 bucks
    • CUI PIC - 50 bucks
    • Sparkfun “Bitwacker” - 25 bucks

We then heard about where the micro-OSC system sits in terms of system topology and functionality, as well as some serious detail about OSC message construction. Also we heard about some performance stats, and some strategies for time stamping the transfer

There was a bit of criticism of ‘throwing things together” , as being “not a very scientific way of looking at your data.” Andy figures that when you’ve spent more and more time with these sensor systems - you discover that these things are more and more important.

There were some questions at the end about OSC’s hardware - what used to be nice about it was that it was an ethernet based standard (better connectors, etc.). USB use does give the ability to have multiple devices on a hub…




Leave a Reply

        Login here to post. If you don't have a login yet, contact admin [at] steim [dot] nl.