6502.org

I built a modular synthesizer years ago and built an analog keyboard for it using a Pratt Read keyframe. I recently decided to update it and use it in my new jazz/fusion band. I found six surplus keybeds that were supposed to be used in new Roland synths but were sold off because of a broken end key which was easy to fix. They are 76 keys. Anyway I designed an interface using the 65C02 to scan the keyboard and output a 6 bit note to a DAC which is then sent to a VCO on the modular. My modular isn't setup for polyphony so my problem is getting the 65C02 code to play a note and if another is held down to turn the previous note's gate off and output the new note to the DAC. So far I've only been able to program it to play one note priority when I need something like next note priority. I've successfully programed a Pratt Read two buss keyboard to output MIDI following Hal Chamberlin's code in his Musical Applications of Microprocessors, but it's for a polyphonic keyboard. Has anyone programed a keyboard scan similar to what I'm trying to do? Thanks for any help!

If I'm understanding correctly, you could use a 76-bit state buffer (10 bytes, or 76 bytes if you have plenty of space) to remember the keys that were pressed during the prior keyscan, plus 1 byte to remember which note is currently playing (if any). If in the next keyscan, a key is pressed that was not pressed before, then the old note can be stopped, and the new key starts and becomes the currently playing note.

Do note that there could be multiple new keys pressed in a scan, and you'd have to decide how you want to tie-break that. You really don't want to abort the keyscan on the first found new key, because you want the prior keyscan results to always be a complete comparison.

If you wanted to be able to let go of the new note and have it return to the old note if it's still held, then you'd need to implement a more dynamic stack. It'd at least be limited to max 76 entries, though, but would require cleaning up mid-stack key releases so they can be re-pressed properly.

You might think about building some sort of event system, where the keyboard scanning sends key up and key down events to the main generator. That would put your logic into the generator but easily allow you to return to a previous note if e.g. a grace note is played. Or by ignoring release messages from a key not currently playing, you would simply cut off previous notes when a new note is played, which sounds until its matching release message.

As I recall keyboards from years and years ago, many had a double switch which allowed the setting of volume by detecting how hard (strictly, how fast) a key was pressed. That would be an easy extension into the message system.

Neil

Thanks White Flame! That's my problem I just want the keyboard to be monophonic right now. I have the 74AS250 16 to 1 multiplexer and a 74LS138 forming an 8 bit key scanner where when a note is down D7 is high. When a key has it's D7 set high the program decodes the address to know which key it is and sends the data to the DAC. The first key on the 76 key keyboard is $00 and the top key is $4B. I tune my OSC to A above middle C (A440). I'll have to try your suggestion which is similar to John Simonton from PAIA's keyboard encoder.

Thanks Barnacle, I'll give that a try

It's not clear to me how that's wired up electronically, could you post a schematic?

Yeah, a schematic would help a lot. Or even, just to start with, a description of the pinout of the cable coming out of the keyboard. And add a description of how you've hooked this up to the '250 and the '138, if you can manage that. And then how these are connected to the PIA.

I'm guessing that it's a fairly standard matrix system, but with the addition of a diode for each keyswitch because for piano-type keyboard (and 76 keys kinda screams "piano") you just can't have the phantom keypresses you get without the diodes; no musician would put up with random notes he's not pressing appearing just because he was holding down a certain key combination.

And also, I would not be surprised to see two switches per key so you can do velocity sensing: when you're spending all that money to get a full 76 keys, you'd probably want that as well.

Aside from getting us a good description of the hardware, you also need to explain how you want to be setting up key priority. I seem to recall from my long-ago days as a musician and recording engineer that my monophonic synths all used highest-key priority, which was ok, but you might want to consider order-priority (i.e., the most recent keypress takes priority, but when released it goes back to the next most recent key that was pressed and is still being held down).

Thanks and your idea of order priority is exactly what I'm trying to achieve! My analog Pratt Read keyboard used the single switch buss which gave the highest key priority. The keybeds I have have the standard dual bubble contacts per key but for now I'm just using only one of the set, later I plan on using the second for velocity sensing since I have six of them. The electronics isn't the problem I have the board already stuffed from a board house that made the board for me. It's getting the program to do the order-priority like you mentioned. I'll post the schematic of the board and key switches which the keybed already has diodes incorporated in it soon. I'm an old long haired musician so I don't move too fast but not too slow. lol

No need to get super fancy with messing with your stack for this.

The sequence would look something like this:
1) Pop note off stack
2) Stack empty?
Yes -> Turn off sound, exit
No?
3) Is top of stack still pressed?
No -> Goto 1
Yes -> Set note, exit


Really don't see you getting too far down your stack, most people I know don't have more than 10 fingers for playing notes on a keyboard. ;P

(12 if you wanna get fancy with one of those foot keyboards they have for pipe organs!)

I suppose you could mash your arm on the keyboard, but I doubt you'd fill up a stack with just 76 total keys.

Ah! Well, then even though I've (thankfully :-)) forgotten most of my musician stuff, I think your issue is actually the same as we fast typists have: we need n-key rollover. And I happened to be working on that just the other year for the Hitachi Basic Master, when I finally figured out why I couldn't type at normal speed on it. (It wouldn't register a keypress until all previously pressed keys had been released. Nightmare for a fast typist. BTW, the Commodore 64 has the same issue, and you can see it easily in VICE if you're a fast typist.)

So, if I can recall what I was doing for the Basic Master (I never completed it, though this might inspire me to), I think the plan was to keep a list of the four or most recently pressed keys and generate a key-down for the newer ones once the older ones were released. That works for typing, but is probably the opposite of what you want for playing, and also you'd want to fall back to the earlier key down if it's still down when the later one is released, which you definitely don't want when typing.

Thanks everyone! Lots of ideas to work with. I'll post the schematic soon and if it will help the assembly code (I'm too old and lazy to learn any of the higher languages)

Press A (push), press B (push), release A (no pop, it's not on top), press A (push), release B (no pop), press B (push), release A (no pop), press A (pop).... blown stack with just 2 keys, if you don't clear out the middle.

VICE is actually WAY worse than the c64 in this regard. The real machine is fairly good for normal fast typing.

Possible yes, but probably not likely to happen. With the 6502 stack you'd have to manage to push all the way past the end of the 8-bit stack pointer, so you'd have to reliably do that 256+ times while playing a song. Yea, maybe you could do that deliberately, but I'm betting it doesn't happen that often.

Or you make your own stack similar to what the p-machines/fourth do; but that's kinda sluggish to do on a 6502 as I understand it.

Messing with the stack programmatically almost certainly will lead to problems and code complexity though.

Consider doing so will require looping through all values in the stack and then shuffling them around so that only the still currently pressed keys are still on the stack.

With a single note that would require a read -> compare -> shuffle all remaining values back one
If you release two at a time you'd have to do that twice! (Or three or four times if you're releasing a chord!)

With up to 10 (9?) keys to check that could become pretty expensive and laggy while trying to do something near real time like making sure that notes get played when you actually press/release keys.

Effectively I'm seeing that you'd probably need a couple of nested loops and those start to add up quick in terms of time cost.

Maybe you could come up with a way to make one loop follow the other which wouldn't be bad, but I highly suspect you'd have gaps in the stack (Released, Released, Held, Released, Held), and would require you to make multiple passes to get them compacted back down correctly.

If I'm understanding the problem correctly, the way I'd do it would be to maintain a doubly-linked list of currently held keys. When a key is pressed, it is inserted at the head of the list. When released, it is removed from the list. That's two arrays of 76 bytes: one holding the "next" pointer for each key, the other holding the "previous" pointer. And one more byte pointing to the head. The head of the list will always be the most recently pressed key.

The special cases that you normally have to deal with when the item you're deleting is at an end of the list can be avoided by having two special items that are always at the head and tail. So an empty list is represented as Head<->Tail, and one containing two items is Head<->A<->B<->Tail. To find the real head of the list, just look at Head's next pointer. If it isn't Tail, you have a key to play.

If I press and hold A, my list will be Head<->A<->Tail. Start playing A.
Press and hold B, and the list becomes Head<->B<->A<->Tail. A was previously the head, so stop it and start playing B
Release A, and it's now Head<->B<->Tail. A wasn't at the head of the list, so don't do anything more.
If I now press A again, I get Head<->A<->B<->Tail. Stop B and start playing A.
Release A, and it's Head<->B<->Tail. This time A was at the head of the list, so stop playing it and start/continue playing B.

In the last step, you want to play B not because it was the key just pressed, but because you've removed A and B is now at the head of the list. If the instrument can distinguish between "start playing this note" and "continue with this note after another interrupted it" (maybe by skipping the attack phase of the envelope and jumping straight to sustain), this structure gives you an easy way of knowing which is needed.

Using the 6502 S-pointer stack is not at all right; that's for something completely different (calling subroutines) and is small enough and difficult enough to access that you shouldn't even use it for subroutine stack frames.

And a stack is not the right thing here. You need a list of currently held keys. But you don't need any non-held keys in the list, nor does it need to be doubly linked. Just make it an array of key codes large enough to handle as many keys as you care to have rollover for, perhaps ten in this application.

When you start your keyboard scan, for each key that's not pressed you check to see if it's in the list and remove it if it is. For each key that is pressed, you remove it from the list if it's already there, and either way add it to the head of the list, removing any key at the tail if the list is full.