Latancy question

[Guest nomadicWhale]

A question about latancy.

I started the md64 project a few months ago, quikly moved to mbng because of the extended features it has and the fact that it is "software" extendable.

The thing is that I read that the latancy might be 100 milisecond.  As far as I understand it means that the elapsed time from rottating a knob until the message is sent to the computer is 100 milisecond.

As far as I know this is a long time.

Can anyone comment on this? can this time be reduced somehow?

BTW, is it true that mb64 has lower latancy?

nW

[Nomical]

I also want to know if this is true.....

Would be very nasty if there were a latency of 100ms, this would resemble old (for example Soundblaster) ISA cards without ASIO drivers or anything. And that would be very bad in my opinion.

That's also the reason why i think this info is wrong, because who would want such a big latency, certainly not Thorsten i guess!!

[TK.]

Who brought up this rumor? I spent a lot of effort to minimize the latency and I'm very sure that the PIC16F as well as the MIOS implementation is faster than most of commercial controllers (I tried some during the last AES in munich and was very surprised how slow the M-Audio controllers are... ;-)

Every 200 us (microseconds, not milliseconds!) the AIN driver samples an analog input. Since V1.2 MIOS comes with the same "dynamic priority" feature like the PIC16F firmwares - the two last moved pots/faders are sampled more often than the other pots. This decreased the latency from 12.8 ms (at 64 pots) without this feature to less than 2 ms (64 pots) with dynamic priorities.

The latency of all 128 digital inputs (also rotary encoders) depends on the "update cycle", minimum and default value is 1 ms!

Best Regards, Thorsten.

P.S.: a lower latency makes no sense, as the transmission of a CC (3 bytes at 31250 baud) takes ca. 1 ms

[smashtv]

Hehe....

From my experience that the MB has the lowest latency of any MIDI control surface or controller, and that's one thing I notice on every surface I play with.  It's even has a faster feel than a lot of the automated mixing consoles out there, like the 03D/02R/01V, even the Ramsa DA-7.

The only thing that even comes close is the Peavey 1600x, and the midibox is not just faster, it spanks it.  8)

This is just another advantage the MB has over the high priced alternatives!

Have fun   ;D

SmashTV

[Guest nomadicWhale]

Dear T.

Didn't mean to spread any "rumors". Just an inocent question. I got confused with milli and micro.

I really appriciate the contribution and effort you are making to this community.

nW

[TK.]

It's ok :)

Best Regards, Thorsten.

[pay_c]

I can just repeat myself: Fast, faster, TK !!! ;D

[stryd_one]

Hah!!

If TK moved any faster, he'd start leaving trails of fire and zoom back into the 17th century or something  ;D

Hey TK, give a MIDIBox to Vivaldi for me while you're doing the rounds ;) heheh

[zap25]

Who brought up this rumor? I spent a lot of effort to minimize the latency and I'm very sure that the PIC16F as well as the MIOS implementation is faster than most of commercial controllers (I tried some during the last AES in munich and was very surprised how slow the M-Audio controllers are... ;-)

Every 200 us (microseconds, not milliseconds!) the AIN driver samples an analog input. Since V1.2 MIOS comes with the same "dynamic priority" feature like the PIC16F firmwares - the two last moved pots/faders are sampled more often than the other pots. This decreased the latency from 12.8 ms (at 64 pots) without this feature to less than 2 ms (64 pots) with dynamic priorities.

The latency of all 128 digital inputs (also rotary encoders) depends on the "update cycle", minimum and default value is 1 ms!

Best Regards, Thorsten.

P.S.: a lower latency makes no sense, as the transmission of a CC (3 bytes at 31250 baud) takes ca. 1 ms

I was looking into a way of connecting upto 256 buttons to a single DINX4 module. Instead of connecting a button to each pin one could arrange the buttons in a 16 row x 16 column matrix.

Is it possible to adapt the code in such a way that the button matrix gets read faster? I think a 1ms latency would suffice if the buttons are pressed after eachother, but a lower latency would be desirable in this case.

Herman

Zap25

[stryd_one]

I was looking into a way of connecting upto 256 buttons to a single DINX4 module. Instead of connecting a button to each pin one could arrange the buttons in a 16 row x 16 column matrix.

Is it possible to adapt the code in such a way that the button matrix gets read faster? I think a 1ms latency would suffice if the buttons are pressed after eachother, but a lower latency would be desirable in this case.

Herman

Zap25

From what I've seen it wouldn't be difficult...

I'm heaps interested in this 256 button business of yours :) What's the story?

[zap25]

From what I've seen it wouldn't be difficult...

I'm heaps interested in this 256 button business of yours :) What's the story?

I'm working on a design for a customized Midi controller specifficaly for VJs. I want to be able to control effects for multiple (3-4) "layers". With 35 buttons per layer and another 35 overall buttons I go well over the current max of 128.

Especially when there's also a couple of jogs and (motor)faders planned in the design.

In hardware it's possible. I don't know if there's any change necessary in the software to handle double the number of buttons.

[TK.]

Hi Zap25,

in theory you could change the time base (1 mS) of the shift register handler to any other value, just only the timer1 period register of the PIC has to be modified. But in this case also other routines like the encoder handler, the auto-repeat for buttons, the display message timer, the global timer, etc. would be called more often and this makes the solution incompatible to any other application (bad re-use).

Also the CPU load would be significantly increased.

Last but not least it has to be taken into accound that MIOS loads the DIN and DOUT shift registers in parallel, this makes it difficult to use the same driver for handling with a button matrix (since for this method the digital outputs have to be preloaded before the digital inputs will be sampled). There is also no reserved memory for more than 128 buttons in the system, so the whole driver cannot use the standard hooks like USER_DIN_NotifyToggle

In fact it would make more sense to write a dedicated shift register driver for such a matrix and to connect the registers to spare pins (if available). This driver could be hooked to the USER_Timer (the only standard timer provided by MIOS). The registers which are necessary to save the state of the buttons and maybe also the debouncing timers have to be located into the memory region which is reserved for the application.

Best Regards, Thorsten.