Project: The Sound of Violence.
It is not over until it *is* over, but for “projects” it sometimes is not over even then…
The pedalbox volume-control and software is all working beautifully now that the pedals are “sprung” by the packing sponge. I have tested the pedalbox and software on Solaris 2.6 (SPARC), Solaris 2.4 (SPARC) and Solaris 8 (x86).
I will post a video of it in action as soon as I obtain an 2xRCA-to-3.5mm jack adaptor cable so that I can capture sound too – a silent video of the volume-control pedalbox would be pretty pointless!
It struck me that the pedalbox might usefully be employed for other computer-control purposes, not just audio-volume control. Thus the current “monolithic” software probably should be split into two parts: a portable (POSIX.1-1988) pedalbox-monitor program that emits bytes representing pedal events to standard-output, and a separate (system-specific) program that reads events from standard-input and sets the audio-volume accordingly. That latter program could, of course, be replaced by one that does something else.
Of course, it would be nice if such a responder program could be written in most any language – shell-script, ruby, perl, awk, C, FORTRAN, python, and so on. Such a wide range (esp. shell) requires that the encoding of the events/state should result in printable (plain text) ASCII bytes, so that text-only programs can join in.
However, the pedal state-encoding should also be a sequence of binary bit-flags so that C, FORTRAN, Pascal, etc can decode the bytes simply, associatively, and very efficiently.
So we need an encoding that is both plain-text ASCII (no control characters) *and* is a set of independant binary bit-flags, at the same time, and ideally is transparently extendable to (say) 1530 separate switches/pedals, but allowing detection of non-implemented switches, we have:
The Switch-State Reporting Protocol
First things first: if there is to be a protocol, it must have a name! In keeping with the amateur nature of the project, I have chosen “Multiple Encoded Switch State” – the MESS protocol. Just about sums it up 🙂
The state of all switches is encoded as a single line of printable ASCII characters (terminated by a single ASCII linefeed character).
Each data byte (7-bit, 8-bit or larger, depending on the host environment) encodes the state of four switches in the least-significant 4 bits, 1 bit per switch, starting from LSB for the first switch. For each switch, a 1 bit indicates “on/activated”, a 0 bit indicates “off/deactivated/not present”.
The 6th bit of each data-byte is always set to zero. The 7th bit of each data-byte is always set to 1. All more-significant bits are always set to zero.
Thus, for a three-switch pedalbox, the set of possible states gives:
|Switch 3||Switch 2||Switch 1||Data Byte|
So, for example, in C, the expression
is true if switch 3 is on, and false otherwise, whereas
is true if either switch 1 or 3 is on, and false if neither is on.
And so on.
Of course, the MESS producer will need a selectable option to provide state either
- only when a switch changes state, or
- periodically (ie: “autorepeat”)
and also an option to report state
- only for activations, or
- for both activations and deactivations
because those behavioural aspects are application-specific and need
to be selectable by the user on a case-by-case basis.
Now, the question is, does anybody have any ideas for other pedal-initiated computer-control purposes…?!