Legatos: “Legos” for Sound
Physical Modular Sound Blocks for sound and music
user will plug various blocks together using cables. The “end” block will
plug into the serial port of a computer. The computer will poll the networked
blocks to find their configuration. Based on the configuration of the blocks,
the computer will create the resulting sounds and music.
will communicate using UART (if easy calibration of multiple blocks is
possible) or I2C (if asynchronous communication is too “iffy.” I like the
idea of I2C because it means I don’t need calibrate chips. This might allow
for cheaper implementation in the future.)
the user’s perspective, blocks have multiple inputs signals and one output
signal. An output cannot be
plugged into another output and vice versa. Internally communication goes
both directions. Typical communication would proceed as follows:
computer would query the “end” block by sending a signal to the block’s
the “end” block would query the blocks connected to it.
every block in the system would have been queried
it is possible to have circular relationships.
the querying reaches an end point i.e. a start block, the start block returns
information to the block that queried it. Information would be:
- An ID #
representing what type of block it is
values if appropriate such as with
- Knob and
receiving information from the block before it, each block in the
until it has received information about earlier blocks from all of its
through its outputs:
it received on its inputs
input it received this information on (so we know how previous blocks
are networked to it.)
own ID#, parameter values, etc.
is there a way to do this without requiring memory storage internally
w/in the block?
each block really have to wait to hear from all connected inputs
before sending information from the blocks before it?
recursive query/response would continue through the network until,
eventually, the computer would receive a description consisting of each
block’s ID, parameters, and how it is networked to the other blocks.
will be several different types of blocks:
- Start blocks:
- No input jacks
- Knobs and switches: user dials parameters
- 4 digit LED readout
- switch has 3-position scale multiplier (x10,
- knob: mechanical encoder
- PIC 18F2520? ATTINY26?
- Light, ultrasonic, etc.
- Sends parameter values based on its
- Unsolved problem:
- The audio HAS to come from the computer. So
how does it appear to be plugged into the block while really being
plugged into the computer?
- Microphone, track loops, etc.
- Unsolved problem: how do we remember the
purpose of each start block? Can we mark them in some way?
- Type “A”:
- Standard block will make up the bulk of most
of the blocks
- Up to 3 inputs, each with its own jack
- 1 output shared by 2 output jacks.
- An ID code identifying what function it has
- An ATTINY13 (or ATTINY11?) controlling the
inputs, outputs, etc.
- Block functions:
- Sine wave
- Logic ops (and, or, xor, not)
- Arithmetic (+, -, /, *)
- Mathematics (differential, integral,
- Filters (high-pass, low-pass, band-pass,
- Control: (if, compare, max, min)
- As many inputs as possible
- One output shared by at least 2 jacks
- Polls a network of blocks and assumes the same
behavior as the network polled.
- Allows for a way to internalize a network
into one block --- necessary for complicated networks.
- First prototype: better to upload the network
into the computer, then download it to the clone block?
- Other types:
- Y adapters:
- Branch one output into 2 etc.
- This is just cabling.
- USB Type A and Type B
- Mouser: Kobiconn
- 154-2742 $.52
- 154-2442 $.58
- Mechanical Encoders:
- 4 digit LEDs
- Capacitive plates good enough?
- Type “A”: ATTINY13, but design to be
compatible with ATTINY11
- Input “start” blocks: PIC18F2520
- Basic components as found on an efe board.