Designing a Patchable Modular Synthesizer with Memory
The Old Crow
oldcrow at Access.Mountain.Net
Thu Feb 22 02:13:01 CET 1996
** note ** LONG message. You have been warned. :)
On Wed, 21 Feb 1996, Clive Jones wrote:
> Perhaps we can throw this into an open arena - list members can put
> forward their design ideas. Even list members who are not very good with
> soldering irons should be encouraged to come forward with their own ideas
> - some good designs usually come from forums like this. Sorry Stefan -
> maybe I was too hard on you earlier - you see I'm having a bad hair day!
> (don't ask).
I have constructed a line of 1/4 DIN digital process controls for our
company that have the ability to communicate with each other and handle
complex control tasks in group fashion. I would almost suggest a similar
sort of approach for patchable synth modules in regard to communicating
individual module status to a host processor.
Consider a rank of modules, each with an RS-485 serial interface. A
microcontroller (say, the Z86E08--an 18-pin chip that costs about $3)
could, on each module, be responsible for reading its own knob, switch &
pin jack states, as well as setting control voltages and logic states for
circuit parameters. (This is what the microcontroller in one of the
process controls does. Of course, it is also programmed with formulas to
perform closed-loop control, but that is not relevant here.)
Like the contollers, the synth modules in combination with a host uP
would be smart enough to figure out how to talk to each other, even if
different configurations (numbers/types of modules) are frequently
introduced. Each would have an dipswitch settable ID, in addition each
type of module (VCO, VCF, etc) would have an embedded "type" code so that
different module types could use the same ID codes and not collide. This
would allow 240 of each type of module :) to be logged in for use by the
host uP. (Not 256, explained below)
Status messages would take the form of:
$<type byte><ID byte><opcode byte><param# byte><param value><checksum>
(Again this is much like the process controllers do their thing.)
The '$' ascii byte is the "attention all units, message incoming" and syncs
up the module uP's state machine for processing the message. <type> &
<ID> single out the destination module (except in special cases, see below).
<opcode> is the action the module is to take; either set a <param#> to
<param value> or request the module return a module status. <checksum> does
some low-level error-checking to minimize corrupted messages from setting
things up improperly.
The module would then return a string of data if so instructed (as in
reading the module's controls) and in all cases an end-of-message byte
would be sent to notify the host uP the transaction is complete.
I might note that the eom byte would be returned as one of two possible
values: ACK or NAK. ACKnowledge indicates everything went off fine. A
Negative AcKnowledge would be returned if the was a problem, such as a
checksum error. The host uP could then re-issue the message or whatever.
As with the process controllers, a few special "global" command messages
would be implemented. A command to ALL modules, such as a "master reset"
action would use one of the 16 (in the range of 240-255) available <type>
values to indicate a "regardless of type# or ID#, do the action". For
a command common to a module type (such as all VCOs), the appropriate
<type> number (0-239) is selected and a special ID code (240-255) is
asserted to indicate a common message to these modules. Error checking
on these special commands would be limited; drop-line I/O such as RS-485
allows I/O collisions, so in these special cases either the host uP
(which knows how many modules there are and of each kind) will have to
ask each module if it understood, or only one module would be allowed to
Note: these data sizes are arbitrary. It is highly unlikely 240 unique
module types will exist, although variations of similar modules may
warrant unique type codes. The message structure can be varied to
accomodate whatever actions are required. It could even be implemeted
using MIDI data structures.
By the way, there is a second way to do this; it is quite similar. The
backplane cards would need to be wired to allow detachable token-ring
plug-in boards, but this is not hard. Then, each module is serially
linked to its neighbor with the end modules connected to the host uP. The
commands are passed down the line from module to module until the intended
one reacts. One advantage of this kind of network is that the modules are
auto-addressable, with each assigned an ID by the host up as it determines
how many modules there are. Running status can be implemented by use of a
2nd attention character (such as `~') to select the module then the normal
`$' attn char to send messages to that module. Also, error-checking is a
little easier as units cannot contend on the I/O bus.
Host uP: it could be a standard PC, it could be a panel-mounted
dedicated device with keypad and display, or even both could be used
interchangably. It would be programmed to learn the module
configuration, learn each module's settings and save these data for
retrieval. It would also take care of overall synth housekeeping.
Hardware: how to build this thing? Build the module uP and
digitizing/CV setting section as one universal circuit that plugs into
the various module cards. Then when the module uP is programmed it will
know how to use its I/O hardware on a per-module basis. The synth circuitry
would be built on a card that plugs into a backplane, with the module uP
plugging into the synth card.
A final word: This may seem like a lot of overhead for implementing a
'programmable' modular synth, but once it is done everything else becomes
a lot easier. Since the module has its own intelligence, it does not
have to rely on a single uP to provide all of the digitizing/state
memorization. Each module does this for itself, making the data available
in a prepared format to the host uP. The host uP would only have to
organize the 'patch memory'.
Sorry I got so long-winded, but this would be fun to build. :)
(And doubtless there are concerns I did not address, but they would
doubtless be handled when found.)
/* Christopher S. Rider -- "The Old Crow" -- http://www.mcs.com/~syzygy/ */
/* PAiA Fatman VCF LFO mod: http://www.mcs.com/~syzygy/webdoc/lfomod.html */
More information about the Synth-diy