Max4Live CPU usage shenanigans

[VT2]

Update: oh wait. After switching cpu meter to "Current" (instead default "Average") a see that wild spikes too (exacty with 64 buffer).

I missed that bit of info, and I also only tested right now... which brings me to one question:
do you actually hear audio dropouts?
I can also see the spikes when I set Live's CPU meter to Current with a 32/64 buffer size BUT I'm not getting any audio dropout.

One advice: don't use the Current CPU meter mode unless you're trying to find out what's going wrong in a Set. It's mostly distracting imho, especially with Silicon machines. You can often think that things are not going good because of it while never experiencing any problem. Mine is always set to Average, and I'm never getting any bad surprises.
That being said, it was worth reporting as it's nonetheless surprising (but that might just be because the whole CPU measurement logic is more complex than what it seems).

Ok
For now for more clear testing i did use 4 Expressive Chords devices in row lol (+ stock Analog synth)
Yes it make dropouts (do you mean short glitches in sound i suppose), in 64 buffer. But, for first (again, as i already described) - my soundcard is barely relevant applicant at low buffer. And secondly - during this test cpu meter (in Current mode) shows really wild values lol (like 200% +, up to 400).

Whereas, when i did the same with 512 buffer (init buffer value for work in Ableton, right), i did get no dropouts, all goes smooth. (With 4 devices)

Then, logically, for make sure if spikes in "Current" mode can reproduce dropouts with normal buffer value, i make 8 Expressive Chords in row with 512 buffer. So as result - yes i reach dropouts from Expressive Chords in, can say, normal environment example. (Do 8 Expressive Chords in row is normal though ? haha).
But actually, with that i finally achieve behavior when being not observe high cpu usage in "Average" mode (about 14%), but we get dropouts anyway. You can see it in video #3. (But in "Current" we still see huge peaks yes).

So, considering probability of specificity of my audio card, all to you decision.

Here videos:
1) 64 buffer \ 4 Expressive Chords
https://www.mediafire.com/file/jji5u7op ... t.mp4/file

2) 512 buffer \ 4 Expressive Chords
https://www.mediafire.com/file/was198rm ... t.mp4/file

3) 512 buffer \ 8 Expressive Chords (dropouts even despite not high cpu load by Average mode)
https://www.mediafire.com/file/1jq0nspq ... t.mp4/file

Upd: Certainly one thing we can say for sure - m4l MIDI devices can be cpu hungry. Whether do this really normal ? (for such devices type) IDK
Upd2: and also - We can has dropouts even with displaying relatively low usage (during Average mode)

[[jur]]

Did you ever report to Support?

[VT2]

Did you ever report to Support?

(If this question was for me)
For me personally, demonstrated behavior has not obviously reason for reporting. Since it may be correlation between potencially properly cpu consumption of certain m4l device with my certain PC config.
Scondly because Ableton not my main DAW.
By this examples i rather wanted to helps to @ian_h figure out what happens.
In general - yes, i had experience of conversation with Ableton support once. (Coincidentally, right about m4l issues).
But regarding exactly topic starter issue, if this worry only me, and not interests for anyone else, ill'pass lol.

[ian_h]

I did file a support request, I haven't heard back yet. I'll update here when I do

[ian_h]

I heard back from support (quite a while ago, I just never got an email about it):

Point taken, reproduced and forwarded to the Max for Live Team for potential improvements.

Context from their input:
What might look as a simple MIDI processor, can easily be much more under the hood. The mentioned devices do not only process MIDI/MPE data but have quite a lot of complexity and DSP processing at audio rate despite producing only MIDI/MPE data.
Comparing the efficiency of native devices with Max for Live ones is not entirely fair. C++ code will always be more efficient than Max objects, even when these are coded themselves in C++. The flexibility and power of Max comes indeed before its performance
32 is a small number, and just the 5th power of two. With my audio interface, Live has 3.5ms to deliver a buffer of samples. A CPU usage of 50% would indicate that Live takes 1.75ms to do so. 100% 3.5ms. Live's CPU meter has nothing to do with usage, rather a time ratio.

Nonetheless, we're investigating and hopefully find ways to further optimize Max when running low-buffer sizes.