This might be an explanation, too, but I don't believe the hammer is not decoupled from the key on a keyboard that isn't supposes to emulate escapement. Anyone here who has disassemled the numa nero?

There is a side view schematic of the TP400 keyboard mechanism at http://www.fatar.com/disegni_grandi/TP_400.htm

The diagram is a bit confusing because it shows the key up and key down views superimposed. It looks as though the key presses down on the end of the hammer shaft and the hammer moves upwards. It isn't possible to tell from the diagram whether the hammer shaft is physically connected to the key or whether it's just kept in contact by the weight of the hammer on the other end of the shaft. If it's the latter case then it might be possible for the key to lose contact with the hammer during fast repetitions. Maybe sigasa can judge whether this is happening from the 'feel' of the key ?

regards,
John

I think the particular explanation above is unlikely. A 'tick' is just the interval between two successive scans of the keys. The duration of a tick is almost certainly controlled by a hardware timer in the microcontroller which controls the keyboard scan. There is no reason why different ticks would be of different durations (unless the software which scans the keyboard does not complete within the duration of a tick, causing the next scan to start late).

Thats what I think, too. There has to be a really sloppy designed firmware to explain it.

The first thing that comes to my mind is that the contacts may be a little loose so that during "sloppy repetitions" some contacts may open accidentally for a short time. The only thing one can do against it is clean them. That's why i don't like that rubber contacts. Optical sensors are easier to clean.

This might be an explanation, too, but I don't believe the hammer is not decoupled from the key on a keyboard that isn't supposes to emulate escapement. Anyone here who has disassemled the numa nero?

Edit: welcome to the board johng

I've just read this on a post on the KVR Forum:

       "Actually you just have to count ticks between the
two events of the two sensors per key(either switches,
or photoelectric sensors with a barrier moving
in between). Those ticks should be with high enough resolution that
you can then convert them down to 127 different MIDI
velocity values. You could either scale the counted
values down linearly or apply some logarithmic curve,
or you might make this function configurable to have
different velocity response curves..."

I think these ticks may have been calibrated badly by Fatar. This would explain the fast repetitions causing the sensors to send sudden loud/max velocities wouldn't it?

I'm new to this board but have been following this discussion with interest. Like sebion, I have designed and built my own midi sensor strip, in my case installed in an upright acoustic piano, so I have some knowledge of the design issues involved.

I think the particular explanation above is unlikely. A 'tick' is just the interval between two successive scans of the keys. The duration of a tick is almost certainly controlled by a hardware timer in the microcontroller which controls the keyboard scan. There is no reason why different ticks would be of different durations (unless the software which scans the keyboard does not complete within the duration of a tick, causing the next scan to start late).

Is it also worth considering whether the problem could be mechanical in origin ? You mentioned elsewhere that this problem usually occurs during 'sloppy repetitions'. I note that this keyboard does not emulate a true escapement mechanism, but is the 'hammer' free to bounce away from the key at any point in the cycle ? If this could happen, for example during a fast repetition, it would momentarily decrease the effective mass of the key. This would cause the key to accelerate faster than normal when a specific impulse is applied, causing it to reach a higher velocity and therefore produce a higher than normal midi velocity.

       "Actually you just have to count ticks between the
two events of the two sensors per key(either switches,
or photoelectric sensors with a barrier moving
in between). Those ticks should be with high enough resolution that
you can then convert them down to 127 different MIDI
velocity values. You could either scale the counted
values down linearly or apply some logarithmic curve,
or you might make this function configurable to have
different velocity response curves..."

I think these ticks may have been calibrated badly by Fatar. This would explain the fast repetitions causing the sensors to send sudden loud/max velocities wouldn't it?

Is there a way of using midi-yoke to re-calibrate the midi signals going to PianoTeq. I don't have any programming experience, but can follow written instruction if anyone has a clue how to do this with midi-yoke and is willing to help me? Alternatively, is there a Fatar compatible alternative midi brain I can put in the Nero that is ready to go (Herman indicated that Doepfer had solid electronics? - just plug in to the keybed? It would be a heck of a lot cheaper than the optical strip!

Regards,

Chris

EDIT: Correction...       MIDI-OX not midi-yoke!!! Sorry!

the Numam Neros sensor board does not have 3 switch logic. I'm not sure about the PNOscan I intend to replace it with either. I'll have to check that out. Mind you, with the optical technology, I guess it is programmable? I expect you'll know for sure!!! Any infirmation on the versitility of optical sensors would be greatly appreciated.

regards

Chris

Maybe when I have time i'll develop a test programm to check out delaying. If I do so I'll inform you.

Regards,

Chris

@sigasa:
of course that would involve some knowledge of windows programming.

Windows programming??????????? No Comprende!!!!!!!!!!!!

I ment LoopBe1: http://nerds.de/en/loopbe1.html
It's a virtual midi driver that can be used to redirect midi data. You could program a simple host application that would pick up midi messages from your actual midi hardware input, then let it be modified the way you want and it would then be output to the virtual midi driver using the virtual midi driver as input for pianoteq.

of course that would involve some knowledge of windows programming.

the sensor strip in the NUMA Nero is similar to if not the same as this one

http://www.proaudioe.com/pages/nord-tec...eybeds.php

Which virtual driver were you refering to to put between PianoTeq and Keyboard midi out?

regards,

Chris

@sigasa
A) Another thought is (I think you already mentioned this in another thread) that this latency you added should not be a constant but vary with the key velocity, e.g. the dalay would become bigger when you hit the key more gently, as in a real piano the hammer has to travel the last bit of its way decoupled from key movement and thus it would take more time when the key was hit more slowly.

B) That is why I tried to model that in the physics engine contained in my selfbuild sensor bar.

C) The only thing I really liked to have would be a real pianos action to play on with my sensor bar, but I don't know where I could get one that I can afford.

A) Absolutely Sebastian. I'm sure that could be incorporated in the mathmatical model(s). Stumbling upon this latency compensation thing has certainly has helped me create a perfectly synced  universally timed Knock/String-Hit, but it would be nice if Modartt would introduce a velocity related delay variable (delay amount/gradient preferably adjustable via a slider). You're right about the strike point in the keyboard itself, but really, in a piano I think ideally you want to feel that trigger point at the bottoming out of the key (unless we're adding escapement into the equation?). Having an escapement similating keyboard would be a different ballgame altogether not needing the delay compensation or altered trigger point. The reason for this is that on a real piano, as you say, the jack slips out (escapement) as the hammer is thrown (hammer throw) so mimicing this in a keyboard makes you think, at the escapement point, that you have triggered the hammer and at the key-bottoming-out-point, you have caught it with the check - meaning that the latter point (which is senor trigger point/keybottomingoutpoint on most keyboards) requires abosolute minimum latency. IN CONCLUSION. For those without escapement, PianoTeq is fine as it is (as long as you can minimise latency). For those without, Modartt, may we have some optional velocity related delay (slider + On/Off Switch)? Please?

B) I have decided to save up for the PNOscan Optical Sensor Bar. I will install it in my NUMA Nero. This will repalce the existing sensor strip with it's inherent midi velocity problems (inherent by design).

C) Check around your local Piano restorers to see if they can fix you up with a well maintained, well regulated action. You may find that some pianos involved in fires for example are scrapped because of casework damage, but the actions have survived. There are good preowned actions out there. Worth a try? Unless of course you were thinking new, which I can appreciate. I'll check out the internet and see what I can find out.

Kind regards,

Chris

http://www.youtube.com/watch?v=ny5SMQBwVmQ

here is the result of my latency timing (actually it doesn't sound as good after the YouTube processing )

regards,

Chris

EDIT: P.S. Watch in 720p HD if you can.

EDIT: P.P.S It's mono!