That's basically the idea behind engines like zbmod. Or, more relevantly, when talking about pulse interleaving, octode2k16. Interleaving of the various pulse trains is abstracted into an actual calculated output weight. So far, so good.
However, there are side effects. If the channel weight is kept near the maximum for consecutive loop iterations, the speaker membrane will build up additional pressure because there is not enough time for it to return to it's rest state. You can hear this clearly in o2k16, when all or almost all channels are busy. I tried to abuse this effect as an engine feature, but it is very hard to control.
When doing actual interleaving, this problem is much less pronounced, since most often there will still be long enough periods for the speaker cone to retract even at when channel weight is high. So by interleaving two "binary trees" (like in pytha, for example), we can mitigate the "ramping" issue, while still maintaining a sizeable number of possible channels. However, this also has side effects, as demonstrated here: http://randomflux.info/1bit/viewtopic.p … 1396#p1396 I still haven't figured what exactly is causing this phenomenon. My guess is that possibly the common assumption about using 8t alignment to mitigate IO contention is not correct, to start with. But probably that isn't the whole picture either. I do want to investigate further with a "perfectly aligned" engine at some point, though. Just need to find some time and motivation for it.
... I always put a bit of EQ on as well. TI isn't like, say, Gameboy, where you can have good sound pretty much out of the box.
