mono vs mono4 question

[tester]

I'm doing some performance tests in "real life" conditions (i.e. there is specific point when I get glitches), and have one question regarding mono and mono4.

I noticed, that there is a performance difference between having single stream oscillators (let say two per stereo) and mono4 oscillators (let say 1 per stereo, 2 channels in use) running.

(yes, I'm aware, that in my schematics, there are many other parts running - either in mono or mono4, depending on version - that can be reason for noticable difference in what I said above).

But I noticed, that there is no difference mono4 mode between using only 2 channels of an osc or all 4 channels. However I also noticed, that this referes only to stock oscillators (my code based stereo fiters offer 2x performance difference). Both tested in on high-load designs, where should be huge CPU drop.

This leads me to the question regarding stock oscillators. Are they "recognizing" whether they act in mono or mono4 mode, and their perfomance relies on that switch?

[MyCo]

This leads me to the question regarding stock oscillators. Are they "recognizing" whether they act in mono or mono4 mode, and their perfomance relies on that switch?

No they don't, the code is always the same.

[tester]

Hmm... Any conceptual ideas/hints to consider, why (physically) removing multiple stock oscillators (sine, wavetable) from the schematic and redirecting their stereo streams through free channels (3-4 on remaining oscs) does not brings back any CPU? And I don't mean task manager readings only - I just have the same amount of switches (oscillators) that I can turn on to stay glitchless (and this of course depends on CPU - correct performance difference between different computers).

[RJHollins]

Not that I know ... but I would figure that an OSC has a certain CPU draw for each OSC.

Transferring streams through MONO or via MONO4, in and of itself, would not seem to be that much savings [just because of the routing ... however, there may be benefit with regard to processing a block of 4 rather than separating the processing with 4 individual routines.

I'm sure you understand it more ... as I would like too

[tester]

Well - it depends. I use a lot of oscillators... (numbers like 100, 200, 300, 400 per schematic), and it's not that they can be replaced by something else or hoped. While on my ~2GHz CPU's I can use most of what I need to get desired output (never use everything) - I can not have all running at once. It consumes 1 core for general work, and up to 20% of second core (this part increased here after ruby came into the game) via Windows sluggishness. I'm happy with what I have, but from time to time I think on what can I change in terms of performance.

If I could have 100 oscillators instead of 200 (and thus - some compromise on wavetables) in schematic - this should make a difference. But even removing 10 of them should give back the possibility to run at least 5-6 more in other sections. It does not works that way, so I try to analyze the paths. Trog saw the guts of some of my work some time ago and we spoke about certain aspects on how to optimize it, so it is not that my designs are wrong.

Among other things, I noticed, that when using all 4 channels for oscs - well, multiplexers (recompiling on on/off) don't like this (some oscs just partially hang, and switching is more glitchy, at least here).

[RJHollins]

I read that same 'critique' of multiplexers used in other aspect of a circuit. It was suggested to try and use the 'Selector' prim when possible.

I don't know the specific differences between the two ... other than they look to be 'mirror' images in looks and operation. I suppose there could be quite the difference under the hood though. Obviously, the consideration comes down to the needs of the circuit.

Back on the SM forum, one of the GURU's posted a type of 'circuit' tester [with probes] [might have been TROG]. I thought it might provide a method of analyzing parts of a circuit to aid in efficiency designing.

Only wish I could help provide some solid advice to you ... all I can do is follow along your threads with interest

[MyCo]

Hmm... Any conceptual ideas/hints to consider, why (physically) removing multiple stock oscillators (sine, wavetable) from the schematic and redirecting their stereo streams through free channels (3-4 on remaining oscs) does not brings back any CPU? And I don't mean task manager readings only - I just have the same amount of switches (oscillators) that I can turn on to stay glitchless (and this of course depends on CPU - correct performance difference between different computers).

Because your schematic is buggy? I don't know! SSE processes always 4 channels, no matter how much of them are in use.

[tester]

Don't worry MyCo - these schematics are not buggy. I'm not that stupid. You can't screw up a thing, that is made of dozens of stock oscillators. As I said - if it was buggy, Trog would point it in early stages of development, when the stream part was developed.

To confirm your not verbalized concerns. Yes, I can't place these schematics on public forum. Yes, the next iteration will have upgraded credits in "about" note; I was sure (due to your characteristic sweet avatar) that I had you there on the list... but it looks we did not exchanged yet at that time. You would like to be listed as "Master of..." or just MyCo?

I probably will return to this performance issue somewhere in the future (at least after gui cross connections are finished), but I was just curious if there are any tested FS/core related things to know right now. I can imagine that there is some "bottleneck" (in FS and SM) related to general amount of streamy items and their structure of connections.