mono4 and stock oscillators (bug)

[tester]

If I understand correctly, mono4 packing makes the oscillator work in 4 separate channels (like 4 independent units).

So why this sechematic shows, that all 4 channels work only on data coming from the first channel, and other channels are ignored?

[MyCo]

The Sine Osc primitive in the Snowflake release is broken. That's already been reported, so a it'll get fixed in the next release.

[tester]

Thanks.

Curious when the next release will be.
Hopefully not in 2014

One thing that makes me curious about stock sine is this. In my design I use mono (1 stream) oscillators. Today I did some test on translating them into mono4 (stereo2mono4 --> oscillator --> mono42stereo, to be precise), expecting that the general app pefrormance will increase. To my surprise - it seemed that it worked a bit worse (similar speed, but sluggish work - glitches on switches).

I can only guess, that I probably would notice some performance difference - if the streams (stereo channels) were different from each other, but I'm not sure about that...

[trogluddite]

Today I did some test on translating them into mono4 (stereo2mono4 --> oscillator --> mono42stereo, to be precise), expecting that the general app pefrormance will increase. To my surprise - it seemed that it worked a bit worse (similar speed, but sluggish work

For a very short mono4 section, like a basic sine osc, that's quite normal - packing and unpacking the data has some CPU overhead of its own, and extra memory read/write etc. (and the toolbox prim's always pack/unpack all four channels even if you only use a couple of them).
Generally, the more modules or lines of code/assembly you can chain together without conversion, the greater the proportion of CPU saving. So its effectiveness will depend a lot on your design - if your synth needs lots of unpack->routing->pack in between very small "shared" sections, then it may not necessarily be worthwhile (and adds a lot of complication to the routing).
If you take a look at my old "Trogz Toolz" kit over at the SM site, you'll find hopped versions of the pack/unpack that can also help a little bit - e.g. when packing 'slow' green values from controls for input parameters. Swapping the stock ones for those can save a few % if you have lots of parameters to pack.

The nature of the code inside a module also has a part to play. For example, the stock oscillators all use look-up tables of some sort. Depending what the PC is doing at any given time, it can sometimes be accessing the data from memory that is more of a bottleneck than running the instructions themselves. This caught me by surprise when I was coding the delays from the same "toolz" - changing the maximum buffer size affected the CPU load more than many of the instruction optimisations I attempted.
This can lead to some weird "oscillating" CPU loads sometimes if many routines are trying to access the same lookup table, but out of phase with each other, and may also partly explain why the oscillators show little improvement...
If you use a single mono osc, it is really still running all four channels - but they are all sychronised, and therefore all reading from the same memory address in the lookup table. The moment you have four different frequencies running, the read pointer for the lookup will be bouncing around all over the place, making potentially four times as many 'page requests' from memory - and that would happen whether you used four mono osc's or a single mono4.

[tester]

...and what is the relationship between using multiple mono4 (16x3x2... okay, let say 16x8 or more) for calculations vs multiple selectors/multiplexers (normal vs 2x less, c.a. 2-4x greater amount?) instead?

I ask, because I just recompiled my sound engine, preparing it for mono4 when sine stock are repaired. A lot of selectors and links (plus some primitives) are removed due to mono4 appearance, but there are more mono4 instead (the minimum amount possible however).

p.s.: I'm still thinking to replace stock mono/mono4 converters with yours, but quick question - what would be performance difference (ratio; rather real percentage) according to your knowledge? I ask, because I noticed in the past, that some optimizations sound cool in theory, not under higher load