How could I use system info CPU meter to limit voices? (Voice stealing)

The built in voice stealing seems like the ideal compromise to me - the user sets a fixed maximum voice count that they can tune in combination with their audio buffer size until they don't get dropouts.

EDIT: what about the built in 'Automatic Voice Reduction' ?

I understand that you want this to be automatic, so the user doesn't need to make choice. That's an attractive idea for sure. But it has the potential to make the instrument less predictable in use. You might hit a cpu spike and lose the bass, or the melody note, or some other important note for the harmony, and with an 'automatic' approach, the user has no control, At least with a fixed voice count, they can experiment and find a voice count/ latency combination where they never have problems.

There is also the potential problem of the cpu meter being reactive, so what might happen (and this could vary per system too) is that any time there is a cpu spike, you still get dropout glitches before you get the change in cpu load%, and then afterwards, a couple of voices drop out... then come back in, then more glitches etc. Not sure if you can ever guarantee to drop voice quickly enough. If that's the case, then you would have to set the threshold pretty low, so why not just have a fixed max voice count from the built in system? Needs lots of testing for sure.

If you had a few synths working this way, you could get some interesting results - one synth overloads the cpu, but if they are all running on the same cpu core, they would all react and drop their voice count, then cpu load would go very low, so then they would all push up their voice count.. and you would get an instant overload... You could maybe at least partially account for this by having a shared event table and some (complex) logic so all synths using your 'system' can talk to each other asbout who gets to increase vocie when there is spare cpu... but you would probably need a slow release on the throttling to prevent oscillations. It depends on the latency of the cpu load reporting.

I suppose if you go for a lower maximum like 30% or 40% it might work, but even then you could still get spikes and glitches that overload the cpu.

You would need hysteresis too, otherwise you would get situations where the cpu load is fluctuation around the threshold, and some noticeable voice is constantly switching on and off...

It should be possible to set up a clock gating system, but managing the voices will be pretty tricky.

so lets say you have 20 voices, and the throttling says only 5 should be active, how do you tell which of the 20 are the most recent 5 voices - they could be any 5 arbitrary voice indices. So some means of tracking them would be necessary.