Keyboard controller

[Guest JimCook]

Is MBHP suitable for developing a keyboard controller?  I'd like to experiment with a keyboard with continuous key position sensing much as Hugh Le Caine did in his "Electronic Sackbut".  I believe most MIDI keyboards simply sense velocity by timing between two switch transistions.  I'd like to try linear Hall Effect sensors or photoreflective sensors to provide a analog signal proportional to key position.  The key position information could then be used to create MIDI messages for velocity, volume, resonance, release, etc.  Like the electronic sackbut, this might make for some very expressive playing!

It would also be handy to have a programmable "speaking" point in the key dip.  For example, an organ speaks fairly early in the motion of the key while a piano doesn't react until the key is nearly depressed.  My Yamaha P150 has organ voices that "speak" at the same point as when a piano voice is selected.  Very unrealistic and definately affects the technique!

Lets say that 0 is the key fully up and 127 is fully depressed (or maybe aftertouch plays in here somehow, say 100 = fully depressed).  An organ voice might speak at 25, an harpsichord at 33 and a piano at 66.

Any comments?

Jim

[TK.]

Hi Jim,

if you know a circuit to convert the sensor signals to a control voltage between 0V and 5V, a MIOS based application could help to realize this project.

Depending on the number of "keys" (==used analog inputs) and the required latency, you possibly need more than one core module in order to optimize the  realtime behaviour. How much sensors should be handled in parallel?

By using a conversion table before sending out the MIDI event you will be able to define different response behaviours.

Best Regards, Thorsten.

[Guest JimCook]

I assumed that I would have to convert key position to 0 - 5V.  There are a lot of ways to sense position but they have to be cheap enough to implement, oh say, 61 keys.  Latency?  Hmmm, let's say over the entire range of 61 keys let's assume that no more that eight keys are pressed simultaneously.  Let's also assume that Note On, Velocity are transmitted on each key press.  After Note On, at least two other CC parameters dependent on key position will be transmitted.   On key release, Note OFF, Release Velocity (not supported very often but part of the MIDI standard) and the reset of the two CC parameters are transmitted.

I would have no problem with even one core per octave but how could all the possible messages be merged properly?  My hands can span an octave easily so with one octave per core I could be transmitting on four cores at the same time.

Thanks!

Jim

[TK.]

Hi Jim,

as you want to have the minimum latency not only for the last "changed" inputs (which is great for a MIDI controller), but for all keys, it makes sense to disable the "Dynamic Priority" feature (-> MIOS_AIN_DynamicPrioSet) so that you have the best latency for all inputs.

This would result to:

best case latency: 200 uS (microseconds)

worst case latency: number of inputs * 200 uS

For 61 inputs: 12.2 mS

Divided over two cores: 6.1 mS

which is already ok when you take the latency caused by the MIDI protocol into account - Note On + 2 MIDI controllers, optimized for "running status":

9n NN VV Bn C1 V1 C2 B2

makes 8 bytes * 320 uS = 2.5 mS

Multiple cores can be chained by using the integrated MIDI merger. See also Concepts->MIDIbox Link->Introduction.

The additional latency can be ignored, as the MIDI In/Out streams are buffered and handled in background.

Best Regards, Thorsten.

[Guest JimCook]

Thanks for the latency analysis, TK!  I'm glad I don't have to use six or seven cores for a keyboard...  You don't need to respond to what's below.  I'm just trying to clarify what I'd like to experiment with...

I would want the Note On/Off, Velocity/Release messages to have the highest priority with the CC messages generated by the key position to have lesser importance.  However, the latency must be quick enough to account for several changes in position in the keydip.

For example, a string voice would probably be more realistic to the performer if the attack was more or less constant but the individual volume of each note (or channel volume, this would probably be easier) depended on key position.  For a slowly rising string chord, the performer slowly presses the keys.  At some point quite soon in the key motion the voice sounds at a volume (and resonance?) porportional to the depth the key is pressed towards the keybed.  As the performer continues to depress the keys, the volume increases.  Slowly releasing the keys likewise causes the volume to slowly decay.

Since the key position input is analog, perhaps it would be possible to calculate Note On velocity by timing between two positions, say 1mm and 3mm (10mm of keydip or about 1/2" is pretty common in pianos and organs).  The Note On and Velocity message is sent after the key reaches 3mm and the volume or resonance messages are proportional to the keydip from 3mm to 10mm.  

Perhaps, to avoid a huge number of CC messages, it would be best to "Hammondize" this function by only allowing the key position of the first key pressed to adjust channel volume (The percussion on a B3 only triggers on the first key pressed.  To cause percussion to trigger again, all the keys must be released.  This works great on lead riffs and block chords but obviously has limitations otherwise.)

Jim

[d2k]

Hey guys...

Today i got hold of a old commodore music package that included a big ol 5octave keyboard and a FM 'Sound Expander' module (contains YM3526 chip). I was hoping to also make a controller keybrd outta this and use MIOS to add further functionality...

I came across thishttp://atlas.csd.net/~rjwsoft/keybrdcontroller.html - could this be used in conjuction with MIOS ye? Would such features as velocity sensitivity (to start with) be acheivable?

Best...

Dan

PS: Is that YM chip of any use - tracked down the datasheet for it, seems to be the first Yam OPL chip...pretty basic, but mebbe summin init...ya never know :P

[Guest cem3340]

Just been reading through this thread and thought I could offer some knowledge on the subject. As you mention Jim, velocity of a keypress is usually obtained by measuring the time taken by the changeover of a set of normally closed/normally open/common switch contacts for any given key. The theory being that when struck quickly, the time taken is shorter than a key which is pressed slowly. I am unaware of any other method that is reliable enough to do this. I do know that on some of the high end 80's synths that used "real weighted piano keys", a true piano (wooden keys overlaid with plastic) mechanism was fitted with a modified hammer mechanism. This hammer then actuated a pair of contacts as described above but I have also seen a complex system that used a light beam/detector type arrangement. The theory of operation was the same as above, but the hammer swung between 2 light sensors. (very complex) The industry thought that it would sell more synths to "traditional" pianists if a true weighted keyboard was fitted.

As to the rest of your description, I gather what you are describing is known as "Aftertouch" on synths fitted with it. I had an old analogue poly synth which used aftertouch, but the after touch was not available to individual keys. In other words, any aftertouch was global to all keys. The method of obtaining the aftertouch signal was quite simple. Running under the full length of the keyboard was a long strip with 2 connections to it. The strip was constructed of 2 strips of thin yet flexible metal with a compressable rubber/foam material sandwiched between them. the whole thing was about 1mm thick. This device was simply a capacitor thats value would change when any part of of was compressed. (the action of the keypressed down on to it) This capacitor was in turn connected into a simple oscillator based upon a NE555 timer.

When a key was pressed, it was detected and velocity detail determined. At this point, the synth's CPU also would look at the frequency of the aftertouch oscillator and determine the aftertouch amount. You can see that if further pressure was applied to a key, this frequency would vary and thus aftertouch was being applied. Sadly due to the complexity of using the above system on each individual key (it was a 5 octave keyboard) it was applied globally across all key's currently pressed, giving some unusual results. (sound wise)

I think you could obtain similar results using Thorsten's design. It would require 16 digital ins and 8 digital outs with the keys connected in a matrix to them. 2 digital ins and 1 digital out for each key (if connected in matrix scanned fashion). This would allow for 4 octaves of keys.

Finally, a single digital in could be used for reading the square wave output of the aftertouch oscillator thereby determining the pulsewidth (frequency) of the aftertouch oscillator. How you then apply this information is entirely up to the user. It may be that a seperate core be used to do the keyscan/aftertouch function.

I hope this info has shed some light on what you are envisaging.

Cheers

Richard

[Guest cem3340]

I've just been sitting pondering how they achieve a similar result using "modern" keyboard construction techniques. Most modern keyboard mechanisms do not use individual sets of metal switch contacts. If you have ever had one apart, you will find the plastic keys press down onto a rubber membrane which has a small conductive rubber protrusion which in turn is pressed down onto a PCB set of contacts. I asked myself, "how then can you obtain velocity AND aftertouch from souch a simple arrangement"?. I think I may have the answer (one way at least :))

One of the properties of conductive rubber that makes the above possible is the fact that the rubber has a resistance that varies depending on how much you compress it. Using this knowledge, you could create a simple capacitor/resistor timing function at the crosspoint of the scanning matrix. The speed at which any given key is struck would be measured by timing how long the capacitor at the matrix junction for the key takes to discharge. Soft/slow press causes the conductive rubber junction to have a high resistance therefore causing the capactor to take longer to discharge. A hard/fast press would be the opposite.

After touch would be measured in a similar fashion. With any matrix scanning, output pins are brought to a known value (high or low) then a series of inputs are read to see corresponding values. As this is done via a programming loop, the capacitor on any matrix junction is continuously going through the charge/discharge cycle for any key which is being held down. When you sense a key has been pressed, you could keep a bit flag set within an array of 8 bytes. each loop through the keyscan not only checks for new key down/ key releases but also measures the pulsewidth of "held" keys. The current pulsewidth of any held key will in fact correspond to that keys current aftertouch. This value again could be shifted into an array holding each keys current aftertouch value.

Sorry for the long replies but i hope I have explained things in a way that can be readily understood

Cheers

Richard

[TK.]

Hi Richard,

thanks a lot for the input!

Could it be possible to re-use such rubber membranes which can also be found in common (ASCII) keyboards, or are those membranes used for musical instruments special constructions which provide a higher resistance range (as function of the pressure)?

Best Regards, Thorsten.

[Rowan]

Hi Richard

Thank you for the insight.

It will be useful.

Rowan

 

[Guest JimCook]

I think that while Richard may be correct about the current construction of commerical keyboards, I feel that it may be a bit difficult for a hobbiest to implement.  It is far easier to find microswitches with a common and a normally open and a normally closed contact and simply time between the contact switching for velocity.  This has been widely used in the past with the now obsolete E510 integrated circuit to provide the keyboard scanning and velocity sensing.

I know that there are several commerical contact replacement systems for organs that use hall effect sensors to eliminate any contacts.  However, to the best of my knowledge, these all use hall effect switches not linear hall effect sensors.  Reflective photosensors are typically not used as linear sensors but many do have fairly linear outputs, especially over the range of 1 to 10mm.  

My goal is NOT to replicate a piano keyboard.  Velocity sensing is barely adequate for an expressive synthetic piano and was, from the beginning of the MIDI specification, a compromise.  Aftertouch only triggers addition CC messages as the keys are pressed HARDER into the keybed.  The key position barely changes on aftertouch.

I'm looking for a keyboard that will be more useful for sampled orchestral instruments not just the piano.  As I noted earlier, imagine a string voice which slowly builds in volume as you ease the the keys down and slowly decays as you back off the keys.  Or a trumpet voice which speaks brighter and louder the quicker the keys are dropped to the key bed but will still fade out slowly if the keys are released slowly.  This just can't be done with velocity sensing or aftertouch.  Even though release velocity sensing is part of the MIDI specification on Note Off, it is seldom used.

For a truly impressive example of 1940's synthesizer technology, take a listen to this RealAudio recording of Hugh LeCaine's Electronic Sackbut:

http://www.spectrum.ieee.org/select/1297/sackbut.ram

If you're curious about this instrument, read more about it at:

http://www.hughlecaine.com/en/sackbut.html

[d2k]

Just thought, couldn't that tactex material be used? - as mentioned in this thread: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=misc;action=display;num=1060830910

Mebbe u could just place a strip of this under the keys for velocity sensitivity and aftertouch...?

Best...

Dan

[SounDuke]

I don't think that the rubber membrane is hard to find: lots of roland keyboards have them equipped in their matrix. Also, 1 octave rubber switch is available here in italy for 12 Euros

[Davo]

Something I was mulling over today was a reinterpretation of the keytar and this thread seems to be the right place to do a brain dump.  The MBHP seems like just the brain to run it.

Suppose we start with a wooden base (I like poplar).  Mount four or five octaves on it.  The neck would be a hollow aluminum bar bolted just behind the keys and is done so in such a way that it can be easily flipped around to make it left-handed.  The neck contains a ribbon controller, expression bar, buttons, dials, and so on much like the Roland AX-7.  Screwed over the neck and behind the keys is the control console.  Here are a numeric keypad, LCD display, and patch buttons, and perhaps some assignable sliders.

[Fear the Weasel]

I realise this is an old thread but I can see the merits of what Jimcook was talking about.  Keys that you can use to slowly bring a sound in and out. 

I'm looking for a keyboard that will be more useful for sampled orchestral instruments not just the piano.  As I noted earlier, imagine a string voice which slowly builds in volume as you ease the the keys down and slowly decays as you back off the keys.

Just happened to be looking at the E-Drum site and saw the design for the "Optical HiHat pedal".  [/http://www.edrum.info/hihat.html   (half way down).

Maybe something like this could be used (obviously not for many keys but...)

Just thought I'd chuck something in.  Could be interesting to try, unfortunately I'm a bit busy with other midibox projects.