Bomes CPU load a factor in such a program?

I'd like to implement a program which would check to see if any one of the 96 faders on my midi control surface has moved, and if one has moved, do an action in Ableton Live. The MT program would also thin out the stream of messages going to Ableton (as I describe below) There's quite a lot going on in Ableton, and the CPU load is substantial already.

My question is whether there would be much of an additional load created by MT as it did the many evaluations of "flags" necessary to make such a MT program work (at least the way I designed it).

The alternative is to let each fader, as it is being moved, generate a continuous stream of midi CC messages, mixed in with a continuous stream of Mouse absolute positions, mouse button downs and mouse ups, mouse relative movements, and mouse button clicks generated by MT - all flowing to Ableton live.

I don't know how much of a CPU load this kind of midi message activity generates as it's received and processed in Ableton. But if I don't try to control the activity by using MT, this activity would only happen when I actually moved a fader or joystick. So there would be infrequent, but heavy bursts of midi activity when a fader (or faders) is/are moved...and then relative calm. This might be worse, than what I propose in the paragraph below.

By contrast, if I were to use MT to thin out the flow of such messages, MT itself would be continuously testing "flags" to see if any fader had moved. Once a fader moves, it's allowed to send a series of mouse commands to Ableton - but only once. Once the commands have been sent, a flag is set which prevents any additional mouse commands from being sent until the flag is reset. The CC messages are still sent since I am using them to move the virtual faders in Ableton. The flag is reset when any other fader moves.

This is a simplified explanation of what I'd be doing with MT. There are many translators doing other things at the same time, and even what I've described above is more intricate than I've said.

So the question is whether it would be worth it to spend the time to implement the program in MT. I'd hate to do it and then find that the CPU load caused by using MT in this fashion is more of a problem than the CPU load caused by having Ableton receive and process bursts of midi messages. Generally Ableton seems to be keeping up with these bursts, but I plan on increasing the number of samples being played and effects being used by Ableton, and that might leave it more vulnerable to increased CPU load.

Hope you can make sense of my rather convoluted explanation of my potential problems as I see them.
Gabriel

Hi Gabriels,

MT does not have a limit on the number of presets and translators, and rules so it is kind of hard to say how much impact MT has on a CPU.

What I can say is that MT's MIDI processing engine has been designed with the best possible performance in mind. It is multi-threaded, minimizes context switches, and the code is optimized as much as possible.

In practice, it's rare that MT has any noticeable impact on CPU. I know of presets with thousands of translators and tens of thousands of rules -- operation on a normal PC still shows 0% CPU in the task manager.

Of course, it also depends on how you create the preset. MT offers different ways for optimizing a preset. Once you've created a first version of your preset, post it here and I can look over it and see if/how it can be optimized. As rule of thumb, every "step" in MT can be regarded as taking the same amount of CPU: one preset, one translator, one rule all add up. So it will not help to use two translators instead of one in order to save one rule. Well, thinking of it, rules are more efficient in general.

Last but not least, nobody can tell you how it compares to Ableton's processing engine, so I wouldn't think you will get around trying it...

Thanks,
Florian

Florian,
Thanks. Your response motivated me to try to optimize my code somewhat, which, in any case, was unnecessary. My computer didn't blink an eye while running the MT code.
Gabriel

good to hear