Gerhard Fiedler wrote:

> I guess I don't understand what you want to do.  If you want to store
> organ setups (that's what I meant you meant with "state" :), the keys
> are irrelevant, and the setups change rarely enough to be stored in
> eeprom (even if you accompany the player's actions with the stops in
> "real time").

  That's the "piston" memory, performed in the console itself and
entirely separate from the MUX between console and loft.  Curiously
enough (it is quite recent) it uses what I consider a "serious"
microcomputer - a 6809!

> if you want to store play sequences, that is everything the player
> does, stops and keys (including time information), you of course need
> a different and much bigger memory -- that would be almost something
> like a (midi) sequencer.  But in this case i'd probably go with an
> off-the-shelf midi sequencer (or a pc) and use the pic only for
> translation of the organ-internal signals into midi. which needs no
> storage at all in the pic (except for some buffer).

  That's exactly what I am describing.  The first buffer has to store
the instantaneous "state" of the organ as it appears down the serial
interface, comparing the current to the last and encoding changes as
they are seen.

  It may however be that more than one key/ stop alters from one "sweep"
or "strobe" to the next, so that you are faced with either accepting
only one change per "sweep", which would be very poor, or storing a
"current" and a "previous" sweep and using a separate process to
compare the two, encoding differences to MIDI and updating "previous" to
match "current" as these are interpreted.

  Very much like a debounce algorithm.

  In "conversation" with John Payson, he has suggested that there may be
300 or so (305 in his example) bits of data representing the organ.
This feels about right to me - I haven't actually counted the pins on
the MUX - and at the 8 kbit/S data rate I believe I measured on the CRO,
would be 26 sweeps per second, perhaps 20 or so allowing for synch.

  In 1/20 second, you can fit quite a few MIDI commands, so this would
seem the way to go.  A FIFO buffer for MIDI output data would probably
not be necessary.

  The reverse would probably need only one buffer, written by MIDI on-
the-fly, and simultaneously read back to the serial datastream.

> without a rather complicated user interface you'd be limited to record
> a sequence and then play it back, and that's it...

  As I said, a "reproducing organ"!

  BTW, there are auxiliary control lines in the MUX-DEMUX set, eight of
these presently control the swell gate servo in "bargraph" mode.
Obviously could be expanded/ lines reclaimed by conversion to 4-bit
Gray code in a PIC!
--
  Cheers,
        Paul B.