Designing a Patchable Modular Synthesizer with Memory

[The Old Crow]

** 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 
respond.

  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.)

    Regards,

      Scott

/* Christopher S. Rider -- "The Old Crow" -- http://www.mcs.com/~syzygy/  */
/* PAiA Fatman VCF LFO mod: http://www.mcs.com/~syzygy/webdoc/lfomod.html */