plugmon wrote: ↑
Sun Mar 14, 2021 6:56 pm
I don't really wanna be involved in this kind of topic either but just for the honor of the synth I sincerely love :
Thank you so much!
Developers are always confronted with comparisons of their products to that of others. There is never a good answer to these, since pointing out strengths of one's own product might seem like bagging someone else's products. So we can't really make such a video ourselves.
I have actually become very careful in how I mention other synthesisers since I've been accused of bullying for saying out loud that I disliked the factory presets of a certain vintage hardware synthesiser (Alesis A6, if you need to know).
Anyhow, what you show is a good example of what I meant to say about optimisation. It is only really worth investing considerable effort when the result is obvious and foreseeable enough. If, say, an 8x unison oscillator uses, say, 10% CPU while 4x unison uses 5%, I would assume that 1x goes down below 2%. That's an optimisation I would certainly go for, since it scales proportionally. But if 8x uses 10% while 4x uses 8%, I'd assume that the step from 4x to 1x may be too minimal to pursue. In fact, the logistics behind the optimisation itself may make things worse.
Now for some technobabble: Optimizing Hive's oscillators for 1x/2x unison may involve templating and specialising the algorithm. This leads to duplication of code blocks with little variances. This in turn means that memory access for executable code multiplies, as multiple version of the algorithm may need to be loaded into memory. This may be good for laboratory settings, but in the real world it easily degrades performance overall.
To further fuel things, it is our experience that SSE-like parallelisation ("4 at once") really only ever halves CPU. That is, we "get 4 for the price of 2". Therefore, there may only be a path to ever optimise for 1x oscillators as 2x will already perform exactly like 4x, and the outcome will be nowhere near 1/4 of the CPU. The fact that unison does not scale proportionally means that there isn't only time spent on actual playback - there is also time spent on logistics behind shared parameters, such as tune, modulation and mixing. Factoring this in, I think a 1x Hive oscillator would probably consume 0.12% instead of 0.16% which is nowhere near the 0.04% that one would naively expect.
These are some of my thoughts in regards to further optimisation of Hive. Not processing an oscillator at all
if it isn't selected in a filter input is a separate topic, and one that I might actually pursue.