keyboards (RE: crap Synth idea-DIY)

[J.D. McEachin]

On Thu, 29 Feb 1996, Clive Jones wrote:

> I don't want to be involved in a flame war on this point - *I* prefer to   
> do stuff discreetly, sure I could write most of the analogue functions in   
> code - but *I* would much rather do it in hardware.

I didn't want a flame war either.  In fact, I was hoping you had a clever 
reason for doing this in hardware.  I happen to like both hardware AND 
software, and try to choose the one more suitable for the job.

> I have to ask this somewhat Ironic question based on your initial   
> response to my post - why are you re-writing the JP6 firmware? 

16 months into the project, I have to ask myself that same question. ;-}


> Can we see   a spec on the firmware? 

http:\\www.synthcom.com\

> Will it increase patch storage? 

No

> Correct me if I'm wrong but I heard it was to improve the MIDI spec - is *that* worth the   
> time and expense?

That depends on how useful an analogue synth w/ MIDI control over every 
parameter is to you.  If only 2 people were benefitting from this, 
probably not.  Since 100's will benefit from it, most definitely.

Besides, it's a way for me to get the arpeggiator I always wanted. %-)

> I was contemplating updating the DSX to include MIDI,   
> an 8 channel MIDI - CV converter and a MIDI interface for Obie's with the   
> Computer Interface, but, after looking at the project from all angles, I   
> can say that I don't really think it's worth it. I published the draft to   
> AH sometime in November if my memory serves me correctly.

Yes, I remember your proposal.  I recommend doing it only if you don't 
like to sleep and are very driven.  Having a business partner to motivate 
you when you reach the inevitable low points helps.  I'd say the biggest 
considerations are: 1) does the DSX have enough CPU power to do what you 
want and 2) can you do the upgrade cheaply enough that a DSX owner will 
want it, adn 3) are there enough DSX owners who will buy it to justify 
giving up a major chunk of your spare time?

> I'll let you into a little secret. I saw a couple of days ago an IC   
> specifically designed to scan keyboards, it's fully polyphonic and has a   
> serial interface that outputs MIDI data - the only external device needed   
> was the clock oscillator - this is fabricated on a single chip!

Oi, now the truth be known!
 
> You didn't read the original post correctly, the idea was to limit uP   
> overhead using a self scanning keyboard to write the results to RAM - uP   
> access would follow in the blanking period to read the results.

Yes, my 1st post mentioned that I had missed out on why you were doing 
this.  I'd like to point out that reading 8 bytes (1 bit X 61 keys) takes 
an insignificant portion of the CPU's time.  If you're doing velocity it 
may take longer, but still well within an 8 bit microcontroller's 
capabilities.

You may want to take a look at some Service Manuals for ideas.

> Can we let this thread die now? It's all about opinions and we could go   
> on forever about this. Let me just make one point clear - my original   
> post was an *idea* - some people may have obtained some ideas from it. I   
> *do* get post from people saying that it's given *them* an idea to do   
> something in a different manner, so in that respect it worked.

There's nothing wrong with ideas, as long as they're worth defending.

> 'll let you into another secret - I wouldn't do it like this either - I'd   
> just make the keyboard scanning matrix part of the uP memory map and scan   
> it during interrupt blanking - but *alot* of people on this list cannot   
> design 8 or 16 bit CPU systems or write code - ever thought of that????

Yes, I've thought of that.  That's why I'm here to spread the gospel - to 
get people to consider whether it's better to do something in hardware or 
software.  There doesn't have to be this analogue/digital divide.  I like 
both.


On Thu, 29 Feb 1996, Haible_Juergen#Tel2743 wrote:

> Let me say Oberheim 8-voice, Emu polyphonic keyboard (ok, the same
> one, almost, I admit!)

Oops.  I thought Oberheim invented the CPU scanned keyboard.  Or was that 
Emu?  

> Unfortunately, my schematics of the n-voice scanning logic are barely 
> readable, so I haven't figured everything out. So once again, every
> information about the logic behind different assign modes (regardless
> of a CPU/non-CPU implementation!) is highly welcome! I encourage
> you to share all you know about this topic!

These are all the Voice Assignment Modes in the JP6:

Solo       - 1 Note Played/1 Voice Used, last note priority

SoloUnison - 1 Note Played/N Voices Used, last note priority

SoloRotate - 1 Note Played/1 Voice Used, Voice assignment rotates, last 
note priority

Unison     - N Notes Played/N Voices Used, Voices are divided between 
Notes played.

Poly1      - N Notes Played/1 Voice Used per Note.  Voice assignments are 
rotated to play the voice that has been released the longest.  Useful to 
preserve the Release portion of envelopes. 

Poly2      - N Notes Played/1 Voice Used per Note.  Voice assignments are 
made in order notes are played, starting with 1st voice.  Useful for 
polyphonic glides.

Steal      - A superset of the other polyphonic modes.  Normally, when 
the N+1th note is played, it is ignored until one of the original N notes 
is released.  At this point, the voice is reassigned to the N+1th note.  
With Steal mode, the voice that belonged to the 1st note gets 
reassigned as soon as the N+1th note is played.  If the N+1th note is 
released before the 1st note is released, then the voice is reassigned 
back to the 1st note, IN THE SUSTAIN PORTION OF ITS ENVELOPE.  This is very, 
VERY nice for playing chords.

The other two assignment modes I know about, but chose not to implement, 
are Solo w/ top note and Solo w/ bottom note priority.

> (And yes, I have considered building a discrete (i.e. MSI CMOS)
> polyphonic keyboard scanner myself, now and then. But I still
> lack the information I need for this!)

I'm not sure how you'd go about it w/ hardware.  It would require one 
hell of a state machine.

My software required 3 lists - a list of Notes played (in order played), a
list of Notes currently assigned to Voices, and a list of the order of
Voices released.  What makes things difficult is when some notes are
played and released while the first notes played are still held. 

I thought it was an easy problem until I started writing the code.  
There's a lot more subtlety there than you think.  The Unison mode was 
especially difficult, forcing me to try 3 different algorithms.  Adding 
to my headaches was a bizarre internal command scheme to turn on voices, 
and a non-symmetrical 6/4/2 voice split architecture.

JDM