Newbie question. Mixing Poly and Mono in schematics?

[R&R]

Going to detox from FlowStone:ing for a while...

But there lots to do on my plugin so I'll get back to it later

[R&R]

Fun fact

I'm still working on minimizing every modulation knob in my plugin... and are pretty much down to a poly multiplier and a de-zipper with only some greens preceeding them (for every modulation knob).

So naturally have been doing some testing aaaaaand...

It turns out that 450+ of your (MV's) hop:ing de-zipper from 2017 found here http://www.dsprobotics.com/support/viewtopic.php?f=2&t=8309&hilit=de+zipper&start=10#p33902 is blazingly fast...
The de-zipper doesn't reach 1 when moving from "x to 1.0" float during ongoing stream, but does hit 1.0 float if incoming value is already 1.0. It does however reach almost 0 down to n decimals (during ongoing stream).

The de-zipper always starts at inital of 0 on new streams... which makes it a bit tricky to use.
I've exchanged it's qRate calculator to poly, feeding that with yet another of the same MV de-zipper to deliver a float value of for example 40 (ms). This incoming upstepping qRate (hop-amount or "hop-matching increment", I guess) will be fed globally through poly to all 450+ de-zippers. This is so that all de-zippers will reach their
initial target value at first sample, or at hop(128) I don't know which doesn't matter as long as they overtake my envelopes... and the LFO doesn't matter that much if it outputs low inital value I suspect.
Lets see if this beats the standard de-zippers won't know until I have exchanged atleast 300+ de-zippers.

Theoretically it should outperform the standard de-zippers... since it did in my separate tests, using 600 de-zippers. But then the qRate wasn't fed through poly... only by the original green qRate calculator.

[Tepeix]

A little mod on the MV Dezipper, this one has a stage0 so when the shematic is set on it has the value of the knob then will dezip any change.

You want to change the ms value in real time according to some lfo ?

[Tepeix]

Now that i think, there's an easy way to change the speed of the dezipper in real time with almost no cpu cost.
A little more multiply inside the hop. (the green calculation could stay green then be multiply)
But it act in reverse, 0.25 means 4x slower, 2 means 2x fast. And it's better to not multiply to much or you end up with a zipper

[R&R]

Very cool Tepeix! This is excellent!
Thank you!

I did some testing with MV's original ones right before a 10 hour local power outage here...
There is quite a performance-boost compared with the original de-zippers (would never have thought I'd go so far as to replace the toolbox ones ever )

I haven't started testing your versions yet due to the power out. But i'm gonna get to it at soon as possible

The plugin still has a large CPU usage due to the sheer amount of knobs and additions at modulation destinations.
But it's alot better now than before

So there is now an improvement "despite" extra modules inserted... for example MV's oversample modules for the toolbox distortion. This is good sign...

[R&R]

Ok have now started some testing with the stage0 version de-zipper...

Very nice in more ways than one. The stage0 version might allow me to replace my envelope de-zippers as well, maybe even some LFO de-zippers. That's around 30 de-zippers right there...

More importantly the staging version also helped me expose a problem at some points in the schematic. At these points I cannot use other than original toolbox de-zipper... because of the hop probably. With the staging version it's easy to expose those problems because it unwantedly transitions, probably at set 40ms (I don't understand why though) the value when inserted at those points.

Not being able to replace some de-zippers might sound bad but i'd rather the plugin works more correctly than faster

The speed mod version seem useful and I think it might come in handy somehow

As a reference. My previous post http://www.dsprobotics.com/support/viewtopic.php?f=2&t=93611&start=90#p238435
After all optimized modules and overall reduction of the schematic, and even with the inserted distortion oversample and some other stuff I can now reach 40 voices with the same computer and preset (that only managed 24voices before). After that the plugin breaks up. So my goal is now set on unlocking voices 41-44

I will need all this perfomance gain to add the two extra "mini LFO's" and modulation of my auxilliary oscillator of course

The original plan from the beginning was that the plugins also should to have 3 modulation envelopes... but I think that is out of the question in regards to performance

[R&R]

After testing thru my presets I started noticing the stage0 mod has some strange issue which makes it unusable as is...

The first note (poly stream) fired off makes the dezipper give wrong value, but "holding/sustaining that note/polystream" makes all the subsequent polystreams played give the correct value from the de-zipper (or atleast a more correct value).

The original MV asm doesn't seem to suffer from this strange behaviour so it must be the stage part that causes some wierd interaction between the poly streams?

The problem might only manifest itself in my schematic I'll have to test in an separate schematic to see if I can recreate the problem...

Edit #2:
Ahh ok
The stage0 does indeed transition on first poly stream but then almost hits (depending on time between) target value on next subsequent poly streams If it already has hit target value by then...all polystreams after that will hit target value directly I guess...

Hmm... I'm a little bit hesitant in using the spmod version also, since the multiplier is not bound to sample-rate or is it? I have to be certain that the multiplication will result in the same slope at all sample rates.

But it looks like the "stage0 spmod" version doesn't have the same problem as the "stage0 only" version... That is weird
I'm going to try and use some of the spmod versions in my plugin and test...

Stage0_with_and_without_spmod_multiplier.jpg (32.85 KiB) Viewed 6412 times

[R&R]

Still...
Even if I can't get the stage0 to work (hopefully spmod version will work) in the plugin it was great help knowing where I should avoid placing even the original one within the plugin.

I'm a bit curious about "additions" since they cost quite alot when used in mass it seems... I saw you using some additions in ASM before Tepeix...

Do you, or anyone else know if there is a super-optimized SSE way of doing alot of additions? It only has to be fractions faster the a regular line-addition (without addition-prim)...

I tried altering the ones you used Tepeix, when testing adding buses together... But I only end up with wrong value in the other end when testing within the plugin... quite strange. Perhaps the same phenomena that's messing with the stage0 dezipper

Seems there are only 8 xmm memory registers? that can be utilized (at same cycle)?

Maybe the overhead of using ASM for addition is greater than just adding using connections anyway

[Tepeix]

Oups sorry, i did'nt think about this.. The stage 0 will reset with new note..
For the multiply it's ok for the sample rate, that are take into account in the green process.

Yep they are only 8 register.. This is sometime complex, we have to note which register need to be used from the end to the beginning (or a certain time), and which are not used anymore then could be used for something else.
(If we want to optimize and not reload them to much)

I'm really not sure you will get so much optimization using sse and addition. The problem is that an addition will not take so much cpu, but using sse you will need to add more code and more addition...
Also, if the addition are in poly white, you could not use sse. It's only possible with mono blue..

Normally, place where adding a lot of stuff might not be the better place where you could do optimization.
But it's hard to say where are the place that will give you the best result.

Did you use a lot of envelope ? Might be strange because they are hopped, but they take lot of cpu.
I think that optimized form exist but i didn't try them so much.
Or a lot of lfo that add together ? Maybe you could use hopped lfo, add them, then lowpass the result.
(I'm not even sure that the lowpass is necessary but like smoothing thing.)

Or maybe the best think to do is to isolate a maximum of part of your schematic.
Cut the volume with an amp and try to only take small part of the schematic to test the cpu cost.
Generally when i do that i could isolate one part of the schematic that do almost 2/3 of the cpu cost.


I'm surprise with the difference between the MV and prim dezipper.
I was thinking they was almost the same. And prim dezipper are reputed to take no cpu.
But seeing the code with the analyzer they are really different.
Also the prim will do more line where the MV do some curve. I prefer curve

[Tepeix]

For the spmod that do not reset that's really strange. (just seen your schematic)
But if you play more notes it begin to also reset like the stage 0.
Erasing the 3 first line after the float would be better.