keyboards (RE: crap Synth idea-DIY)
jdm at synthcom.com
Thu Feb 29 14:39:56 CET 1996
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?
> Will it increase patch storage?
> 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
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
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
> 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
Unison - N Notes Played/N Voices Used, Voices are divided between
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
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.
More information about the Synth-diy