View source for Led-n-sound-toy

Imagine a kind of 'toy' that works like the 'Reactable' device that was famous a few years ago, but then created purely from physical objects.

The idea being that you have a number of physical blocks (cylindrical in nature) that can be moved into proximity of eachother to have them create inter-relationships that manipulate/alter aspects of a cooperatively created rythmical soundscape.

The devices would inter-connect using an IR-based protocol; a pulse-train of data forwarded from one block to the next in a rythm determined by the parameters of the pulse-train a particular block receives.

It all would start with a 'sequencer' block which would have a BPM setting and would (by default) have a 16-position 'sequence-loop' setting before it'd start afresh.

It would output a dataframe via IR that'd contain 'BPM' and 'sequence-number'

The dataframe gets received by a set of 'position' blocks. The position-blocks 'receive' the incoming IR-train on their left, they 'forward' it on the left.

The forwarding of data is instantaneous through the whole chain; but carries info added by the position-block that matches the '$current_block' about which 'instruments' are enabled on that position. Think of 'drum' 'synth' 'hi-hat' etc.

At the end of the chain is the 'receiver'. It catches all the data and turns it into sound, somehow. Most likely this is done by turning it into a midi-frame that's forwarded to a PC; but could be implemented in a physical block with a speaker (or jack) too.

The 'instruments' could be set on the position in a number of ways. One could imagine that you could use a toggle-button, a lever-switch , etc, on the 'position block'. However, it is envisioned to have these be 'tangible' too. This could work in the following way:

When a frame is received for $current_pos, the $current_pos+1 block sends a frame out through a reserves RX/TX IR-path either 'above' or 'below' the block in question by which it does an inventory of which blocks are aligned there, and what their settings are. A first 'ping' gets relayed until the last block in the chain doesnt get a response back and starts to cascade data back down the chain towards the $current_pos+1 block. This block then knows what instruments are associated with it and what their settings are; making it ready to send that data through to the receiver by means of forwarding the data through the chain when it's time comes.

This mechanism could also be made to work asynchronously. That is, the chain doesnt actually 'forward' the data for each position only when it's needed, but does so continuously but the receiver knows when it is time to play any particular note on it's own. This will require some manner of synchronization between sequencer and receiver, of course.

This would work by having a continuous cascade of data flowing from the first positional block to the last; containing all the data of all the intermediate positions and the instruments (and settings) aligned with them. the position-blocks would be doing an inventory of the elements aligned with it on their own time, as well.

This latter method could also make it possible to have the receiver and sequencer be the same block; though this will prevent the 'position blocks' from being able to give any kind of indication of which one is being played at that particular moment; unless some kind of bi-directional mechanism is employed; making things slow down because of the half-duplex nature.

Each instrument would require:

Battery
mCU
2 x IR-receiver
2 x IR-diode
optional buttons/knobs/actuators for pitch/drum-selection/etc

Each position-block would require
battery
mCU
2 x IR-receiver
2 x IR-diode
LED-indicator for position

Sequencer would require
battery
mCU
1x IR diode
BPM-guage
Rotational setting
Button for 'reset' (optional)

Each receiver would require
battery
mCU
1x IR receiver
Audio/Midi output


A simpler model might work with:

A BPM block (the initiator)
Position blocks with buttons for each instrument (plus rotation-setting for pitch of synth)
A receiver, playing the notes of $current_position.

This mechanism would require less blocks (and less batteries/complexity) while still allowing for variable position-count, etc.