Adding Polystreams

[tulamide]

Since I only read rumours about it, I would like to get a definitive answer (MyCo? Martin?). Two screenshots below, and it is only about the wiring. So please ignore that you see three times the same osc, or that they all are at the same frequency. Just assume different oscillators or different frequencies. The question is if either of these are valid connections? If not, please explain why not. This question is important for me, since I will have a whole bunch of oscillators that will produce sound on the same midi input, and will all share the same effects. I magining that I would have to build a seperate filter for each oscillator, etc., until I convert to mono streams is horrifying.

Is this a valid connection of streams?

streams_01.PNG (29.56 KiB) Viewed 35861 times

And what about this? Still valid?

stream_02.PNG (26.98 KiB) Viewed 35861 times

[adamszabo]

Yes its perfectly valid, but using it like that, you are just adding three different waveforms together producing a new waveform. On that pic, it will simply become a three times louder sine.

[tulamide]

Yes its perfectly valid, but using it like that, you are just adding three different waveforms together producing a new waveform. On that pic, it will simply become a three times louder sine.

Thank you, Adam! I really needed this confirmation. I will be playing around with 30-40 oscillators, so that was a big issue of uncertainty for me!

Regarding your objection, please notice that I said:

So please ignore that you see three times the same osc, or that they all are at the same frequency. Just assume different oscillators or different frequencies.

[adamszabo]

So please ignore that you see three times the same osc, or that they all are at the same frequency. Just assume different oscillators or different frequencies.

Hehe, yes I am well aware of that, I just wanted to explain what would happen if you would use that pic to actually create your synth. If you were to have one of them as a square, then a saw, then a sine. it would be like creating a new waveform adding all of them together, and that waveform goes into the filter.

[Nubeat7]

I remember that in the old sm forum there was a recommendation to use the add primitives. But i cant remember why and i normally don't do it.

btw. When you plan to put some parts into asm for optimizing it can be very helpful to use the add primitives, like this it is easier to translate it to code.

[tulamide]

I remember that in the old sm forum there was a recommendation to use the add primitives. But i cant remember why and i normally don't do it.

btw. When you plan to put some parts into asm for optimizing it can be very helpful to use the add primitives, like this it is easier to translate it to code.

I wouldn't be able to do any assembler code. But if I find somebody willing to do it, it might be helpful for that one to use the primitives. Thanks for the heads-up!

So please ignore that you see three times the same osc, or that they all are at the same frequency. Just assume different oscillators or different frequencies.

Hehe, yes I am well aware of that, I just wanted to explain what would happen if you would use that pic to actually create your synth. If you were to have one of them as a square, then a saw, then a sine. it would be like creating a new waveform adding all of them together, and that waveform goes into the filter.

I see. Yes, that's my intent. I'm playing around with additive synth. The uncertainty came from reports I remembered, where we got warned never to cross the individual streams. That gave me a headache, since it would prohibit the purpose of additive synthesis.

[KG_is_back]

I remember that in the old sm forum there was a recommendation to use the add primitives. But i cant remember why and i normally don't do it.

It might be because with add primitive you can parallelize the adding. If you just use plain connections the resulting code is equivalent with: out=((a+b)+c)+d
With add primitives you can arrange the additions into a tree: out=(a+b)+(c+d)
processor can then execute (a+b) in parallel with (c+d). However, the improvement will be rather insignificant - you save about as many CPU cycles as you have connectors, since float addition is only 2-4 cycles to begin with...

[tulamide]

I remember that in the old sm forum there was a recommendation to use the add primitives. But i cant remember why and i normally don't do it.

It might be because with add primitive you can parallelize the adding. If you just use plain connections the resulting code is equivalent with: out=((a+b)+c)+d
With add primitives you can arrange the additions into a tree: out=(a+b)+(c+d)
processor can then execute (a+b) in parallel with (c+d). However, the improvement will be rather insignificant - you save about as many CPU cycles as you have connectors, since float addition is only 2-4 cycles to begin with...

That's some interesting info I wasn't aware of. Thank you!

[stw]

It might be because with add primitive you can parallelize the adding. If you just use plain connections the resulting code is equivalent with: out=((a+b)+c)+d
With add primitives you can arrange the additions into a tree: out=(a+b)+(c+d)
processor can then execute (a+b) in parallel with (c+d). However, the improvement will be rather insignificant - you save about as many CPU cycles as you have connectors, since float addition is only 2-4 cycles to begin with...

Are you sure?
Parallel processing on poly stream is always acting on the packed 4 mono streams and not on doing equal operation from different places. In fact using add prims is introducing some overhead because it has to store the interim results and therefore should be slightly slower (as you can see in the image).

capture.png (45.78 KiB) Viewed 35771 times

[KG_is_back]

Are you sure?
Parallel processing on poly stream is always acting on the packed 4 mono streams and not on doing equal operation from different places.

Modern processors use pipeline. Each instruction is executed in stages. Processor can start executing next instruction before the last one has finished, unless the next one expects input from the last one. Also, they load instructions in chunks and execute them in the most favourable order, to maximize the usage of the pipeline.

In fact using add prims is introducing some overhead because it has to store the interim results and therefore should be slightly slower (as you can see in the image).

Yes you are correct about that one. I forgot that flowstone does that...