Software Pianos / QBas Scan Matrix

MIDIfication
1

I am looking seriously at building a pc based digital piano.  There is a very large choice of programs including

4Front Technologies True Piano

Best Service Galaxy 11

Bluethner Digital Model One

Modartt Pianoteq

National Instruments Akoustik Piano

Sampletekk various simulations

Steinberg The Grand 2

Synthology Ivory

Vienna Symphonic Library Bosendorfer Imperial

At present I am studying QBas 16 X 16 scan matrix that is based on Thorsten’s work for both scanning and velocity sensing.  It is hard going for me but I am beginning to understand the assembler code.

I have read that with velocity sensed keybeds there is a difference between the relative velocity (loudness) between the black and white keys.  I think that this will be the case for Fatar keybeds.

I hope to be able to compensate for the velocity difference with a change to the assembler code. 

Could QBas or anyone else confirm the black/white key problem.

Hopefully, I will eventually be able to understand the program sufficiently to provide additional comments to make the code more understandable to others.  I am retired from work and have more time than most.

Robin

2

I have read that with velocity sensed keybeds there is a difference between the relative velocity (loudness) between the black and white keys. 

I’ve never seen such a thing. It’ll vary from one keybed to the next I guess.

I hope to be able to compensate for the velocity difference with a change to the assembler code. 

Yes you will :slight_smile:

3

Hi guys,

I`m interesting in polishing code  of scan matrix with velocity.

I have idea how to find value(s) of difference between black and white keys:

Since I don`t know way how to calculate in realtime values of “velocity_curve”, only by predefine LU table. So it is no problem to create different table (s) for black and for white keys.

Earlier I tried to find values for this table (and additional parameters like timer)

manually, but this is no good way, and now I come back with new idea:

Creating in pd small enviroment for converting values from keyboard (raw values of time in sysex format) into our note on/off with velocity_table_curve_for_black + the_same_but_for_white.

Benefit is because we can change parameters in realtime, not in asm file.

So this way will give us many different pairs (for black and white) of curve_tabeles.

Of course if we no need different velocity table for black keys, this way (with pd) will help find better (more human) touch feeling of keyboard.

If somebody have better idea please say it now (if my post is understandable).

thanks

QBAS

4

Hi QBAS :slight_smile:

I think it would be a shame to lose the standalone midi capability of the keyboard and rely upon a PC.

Some ideas I had:

Have an algorithm calculate the velocity rather than a table. As we know, doing arithmetic on PIC is not superfast :wink: , but if we have a good algorithm then it is quite easy to hardcode… As an illustration of what I mean; if you wanted to do a division… you could have a ‘divide 16bit X, by 16bit Y’ algorithm, but if you know that Y will always be 160, then you can make a special algorithm that only does ‘divide 16bit X, by 160’. This would be much faster. There are plenty of good examples of this theory at the piclist site :wink:

Have the ability to upload velocity curves via sysex, which would allow a great deal of flexibility, and also is inclusive of the pd environment (you could output the raw data in a sysex stream as you said, and  use that input to create the curve in PD… But it also allows it to work with anything that’ll send sysex.

Have a feature where you can set the output velocity for a given key-movement-speed… So like, you would go into the menu, and select velocity=10, and hit the key as hard as you think it should be for velocity=10…same for 20, 30, 40, etc… then interpolate the values (heading into the algorithm idea again) to create a curve… or link an incoming CC to the same, so you roll the modwheel up, while repeatedly pressing a key harder and harder each time. Each time you hit the key, you sample the speed of that, and the CC value, interpolate, and booyah, you got a curve.

Combine the above. For EG, you could upload/create a single velocity curve for all keys, and then process the keys with an algorithm that modifies the black keys output velocity in a desirable manner.

I dunno, I could spew ideas all day… My point is, I think it would be better to solve the non-realtime velocity curve setting problem, than to avoid it and move to pd. It’s such an excellent app man, one of the most ambitious IMO, don’t give up on it yet :smiley:

5

Edit: I can’t help but wonder though guys… Are you sure it’s not just that the black keys are shorter = leverage difference?

6

Well for me personally it seems that all the keys I don’t hit with my index finger have less velocity :wink:

7

Ahem, I was trying to avoid blaming anyone’s playing style :wink:

8

I have come across many examples where the black key/white key velocity  is cited as a problem.  I did not keep any of these references, however.  Sometimes it has been impossible to obtain maximum velocity.  It is due to the difference in the length of the the lever.  Doepfer who sell the Fatar keybeds correct for this in their interface.

I will provide some links to show that is a real problem.  The impression I have is that there is 10% to 15% difference in relative velocity.  There is one way to prove this, by experiment.

At the first level this could be done by hitting adjacent B/W keys with the same force. After that it could be made more scientific  using weights.  Those with Fatar type keybeds could try the first experiment.

I can’t – I have no keybed at present.

I agree with Stryd_One .  The correction should be implemented in Midibox and should be kept out of the PC

BTW Here is link to Pianoteq.  This demonstrates the extent of the software modelling of the latest software pianos.  It does not appear to have B/W key correction.

http://www.pianoteq.com/pianoteq_details.php#technology

Robin

9

Here is an extract from the manual of the Doepfer LMK2

Appendix C : Velocity-Response Reduction Factor for the Black Keys

Because of the shorter leverage the black keys have a slightly higher velocity response than the white keys with

pressure being equal. The LMK2 enables to reduce the velocity values of the black keys in comparison to the

white keys. To adjust the reduction factor you have to keep pressed the first button (PRESET) during power on. In

this case you will enter a special menu where a 3 digit number is to be seen on the display. The value can be

adjusted by using wheel 1 (not spring loaded type). A value of 127 corresponds to a reduction factor 1 i.e. no

reduction. Values below 127 reduce the velocity values of the black keys. The possible display range of 100…127

corresponds to a reduction factor of about 0.75 . . . 1.0. From our experience values between 110 and 120 are

meaningful. The factory value is 118.

Here’s the link

http://www.doepfer.de/pdf/LMK2_man.pdf

It looks as if we need a reduction factor of 0.9 to achieve the Doepfer default value.

Robin

10

Is this an unweighted board by any chance?

I don’t suppose they happen to mention HOW they apply that factor? :wink:

11

No, this is a weighted keybed.

See link http://www.doepfer.de/home_e.htm , click on LMK4.  You will see the reference to black key sensitivity.  The keybeds are Fatar TP10 type which are at the top of the Fatar range.  I believe that QBas has the TP10 Wood which I think is the version to use with digital pianos to give the most realistic piano feel.

How they achieve the compensation is is not made clear, except that is obviously electronic.

I have searched more today.  There are numerous references to the problem, some with white keys more sensitive.

Robin

12

Yesterday I try to answer you (both) but since you give me an additional ideas, I tried to check this just now, but it was too big task for my one evening.

First of all I agree that black keys are more sensivite.

Applying  correction into PIC code is no problem.

I would like to share my tought.

This topic is great response for my question:

http://www.midibox.org/forum/index.php/topic,6386.msg59979.html#msg59979.

I asked about possibilities of calculate velocity response in PIC, but until today I no receive an idea how to do this. Somebodys suggested me using tables with predefined values of velocity. If we go into tables then it will be easier to generate this tables by using computer`s environment.

If we go into reltime calculate in PIC – this is best solution, but I  don`t know now how to implement log scale and exponential.

I think it would be a shame to lose the standalone midi capability of the keyboard and rely upon a PC.

I agree that keyboard must be separatelly unit from computer.

I rather think about build (computer based) environment who give me values for build-in-PIC velocity table(s), by simple experiences with simultaneously:

  1. keyboard playing

  2. realtime tweak timer

  3. realtime tweak shape of curve in computer for getting enough good feeling during play (I`m tried this yesterday, but I need more time, so I will inform if you not give me better direction)

Like I said this outputted tables will be putted in to PIC for standalone using keyboard.

13

I asked about possibilities of calculate velocity response in PIC, but until today I no receive an idea how to do this.

There were three, in my post that you quoted :slight_smile:

http://www.piclist.com/techref/microchip/math/power/index.htm Could be interesting to you… That particular page is floating-point-focussed, but it should demonstrate that there are various ways to do exponents.

Of course, it needs to be *quick* to respond to a keypress (we don’t want to increase latency) so I think that a table is the way to go - the table should be small because you’ve only got 127 entries. Then, you could combine the table with a fast and rough write to the table** with a calculation to adjust the black keys, and you’re all set. Add a sysex implementation, and you will be able to upload stuff from a pd app (or whatever) as well, so you get the best of both worlds.

Regarding the black keys… … you said something about making it 90%. Of course there are lots of algorithms you could use, but this one is designed to show that you don’t have to use a divide function just because you want to divide, and that you can sometimes work backwards to your goal :wink:

Y = X - (X >> 3) means Y = 87.5% of X

Y = X - (X >> 4) means Y = 93.25% of X

Where Y is the output velocity and X is the original sensed velocity.

You could adjust this by adding or subtracting smaller fractions of the original such as X >> 5 (3.125%). This could be fast because you know you can safely use MULWF without overflow, but of course the more complex you make things, the slower it gets.

Re-reading that doepfer manual it sounds like it’s feeding that 7b value directly into a scaling algorithm like TK’s, where the minimum is always 0 and the maximum is the value you set (100-127). We already know that’s a good algorithm :wink:

In fact, now that I think about it… hahahha… I just wrote this long post and realized much of it may be pointless ahahaha! ;D I really should engage my brain before I type. :-X

You can convert the value as you write it into the table, before it is loaded and in use. That way, your algorithm can be as long and slow as you like, it just means that there will be a longer delay when you write a new custom velocity table or edit one - but it won’t effect latency at all :smiley:

14

I want to be sure that I understand the concept, Stryd_one.

Are you proposing a look up table that will scale the black note velocities?

Therefore in its simplest form this would be a linear scaling. eg any black note velocity midibox output = 0.9 X any keybed black note produced velocity.  And will the table method introduce less latency than one of your formulas ?eg

Y = X - (X >> 3) means Y = 87.5% of X

Doepfer seem to use a pot to alter the scaling factor during setup.

Other Items

There are other items which could be included.  The various piano pedals.  Keyboards Splits.  Some these items are appropriate to Pianos, some not. 

Robin