different behaviour of qwerty and midi cc/note

Has anyone else noticed how reaktor behaves differently when using qwerty keys to trigger midi note on/off messages as opposed to using a midi controller?

When I use my berhinger midi controller, or padkontrol to send either cc or note messages it can cause CPU spikes on certain functions. However when I use qwerty this doesn't happen.
The first time I experienced this was using clists beatlokup. If you try mapping one of the input / output sampling buttons to an external midi controller you will experience the cpu spike, but you wont get it when mapped to qwerty.

Does anyone know why this is? Surely qwerty is just sending note on / note off messages? Is it something to do with latency from using external midi perhaps?

Any help would be appreciated

Ed

 

I have never noticed this.

However, the computer keyboard sends MIDI notes at a constant velocity.

A MIDI keyboard can send lots more MIDI data - after touch, note off velocities, etc.

Get a MIDI monitor (either a Reaktor ens or external software) to see if that is what is happening.

 

Thanks Jim. It's not velocity - I've tried using my midi controller on fixed velocity.
I will try a midi monitor as you suggest.

 

Hi megwatz, that's digging very deep into REAKTOR's framework. Controlling midi from computer keyboard uses only display update rate (25Hz); a nomal midi controller uses control rate (400Hz). Although you are using the same modules (midi pitch and midi gate) they show different behaviour using computer keyboard or midi controller. It is important from which source an event starts.
The CPU usage display doesn't show really true values especially in this case this depends on that, what happens behind the event.

ciao herw

 

Thanks herw. That would explain things. Using a midi monitor shows exactly the same behaviour for qwerty midi and midi sent from a controller. Do you know if there is any way to change midi sent from a controller to 25hz using reaktor? My midi controller does not give the option of altering the control rate of sent messages. The CPU spikes can cause little audio glitches in y ensemble which I'd like to iron out.

 

yes, you can use sample and hold (value module) to get triggered event by display update rate (system module) but that is not a solution.
The reason for the glitches may be from mixing event signals and audio processing. As i said in my last post it depends on that what is happening behind the event. You do never know whether some events acts within the same sample tick. So the only solution is to use events which are controlled by the sample rate (!). You can use the AtoE-perm module.

 

Interesting. I constantly use the qwerty for controls and didn't notice it was so much slower to react.
F.w.i.w., you can also lower Reaktor's control rate to 25 Hz in Settings/Control Rate

 

yes but there are three reasons against this:
1st the perfomance is very low
2nd the cpu usage is still different as the control rate is „part” of audio rate (sub audio rate, see REAKTOR 5.5 - Application Reference - p238)
3rd mixing of display-update-rate-datas and control-rate-datas is still happening although when using 25Hz for control rate. This is very misterious. Only NI's developers can tell you about it precisely (they call it thread safeness).

ciao herw

BTW: such interesting discussions should be part of a systematic knowledge forum here. Systematic means that there is a moderator who is able to direct such discussions into a knowledge database for creators. This should been supported by a developer of REAKTOR - this would be my wish for a new forum structure.

 

Thanks herw! Connecting the midi input to the value module clocked by the dclk to a step filter seems to emulate the way a qwerty key controls the same function.
I've got rd of the cpu spikes and the audio glitches.
It's still not ideal as it seems to effect my midi outs - appearing to slow down their control rate - but this doesn't effect my ensemble too badly.