timestamps

I've got a Behringer CMD PL-1. The unit has 8 endless encoders which send values of 0x41 when dialing clockwise, or 0x3f when dialing counter cw, no matter how fast I dial. The only thing changing on slower/faster dialing is the time stamp difference of midi events.

I now want to have these encoders "accelerating" depending on how fast I dial.

I got it working with a timer which is fired @ 20ms intervals, however, this seems to put quite some stress on the cpu. I got around it, by only firing the timer if "necessary", however, as long as I dial an encoder the timer needs to be fired, there's the cpu stress...

So, my idea to work around this is this: I measure the time difference between two subsequent midi cc events for a dedicated encoder and calculate an accelerated value depending on the delta, so no need for timers.

However, I can't seem to get the time stamp of a midi event, can I?

If you haven't already found a solution,I can help you. Just post here

Need help

Thanks

can you please attach your project file?

TabSel wrote:Need help

Thanks

Give me a day! The concept is counting the messages on a short period of time. The timer should stop immediately after that time if no midi message arrives and reset the counter.

Like Florian asked ,upload the project file.
It is very strange that a single timer causes cpu spikes. In the past I had a cheap netbook for calculating positional sensing in e-drums ,using many timers (2 per strike) and never had any problem.

I recently sold my TriggerFingerPro and realized I don't have an endless rotary!
I used a virtual controller ( Ctrlr ) and used BE 0B pp as an example.
It really depends to what you want to do, so this is just a (working) example

The concept is
Start a counter (ga) on the desired MidiMessage and trigger once ,a timer with 100ms delay (you can use shorter time)
If the counter is > 1 you don't have to start another timer but wait for 100ms and keep counting (ga=ga+1)
When the time comes (100ms) you reset the counter to zero (<1)
The last translator outputs the value of the counter and I used that to see if it's working (I dumped the midi out to MidiOX)

Thanks.

My implementation was a bit more complex. I needed an undelayed immediate output as soon as the encoder is dialed, and it took direction changes into account: dial cw fast, then dial ccw... But based on a similar technique. Also, I stored 8 acceleration values in one variable ga. May be these calculations have been the reason for the CPU...

Unfortunately I deleted the translators, as it didn't work without CPU hit...