VSTplug coalition white black vocal processor beta released (32+64VST2)

[DocSnyder]

It's rare to find VST's made by mixers and producers

Is it?

Yes, humbly it is.

Fabfilter, HOFA, vengeance, dada life, xfer, Slate, melda, refx, forward audio, Hamburg audio, TDR, all the artist lines e.g. from waves... ...just to name some of the ones I can immediately think of

[BlitBit]

And in that regard; the 64 bit version has an issue with phase; when using saturation. I've troubleshooted the issue; for those who work with flowstone, I needed to write My own selectors and multiplexers 4 64, IE:

Code: Select all

lout1 = left * ((bool==1)&1)

with DSP code. Worked well, though it got a bit convoluted after a time.

What's the intention of that code? To forward the left channel if bool is set to true? If that's the case then I think the following code would be much easier to read (in case Flowstone supports this syntax):

Code: Select all

lout1 = bool ? left : 0.;

It would also be more efficient because there is no useless multiplication involved. Although the compiler might be able to optimize the multiplication away in the original code snippet. It would be even more efficient if the boolean was only evaluated once per block.

[whyterabbyt]

It's rare to find VST's made by mixers and producers but I have seven years experience and countless errors in processing that have led Me to understand the craft with some integrity.

You still insisting that tape heads run faster because they have latency, that you 'oversample' tape to get a hotter signal, and that the government limited audio recording to 20KHz and under for WW2 propaganda purposes?

[BlueprintInc]

It would also be more efficient because there is no useless multiplication involved.

But you use a branch which is even less efficient, especially used in loops. The key to performance is to integrate conditionals into arithmetics, saves the jump. There are nice talks from Andrei Alexandrescu at cppcon about it.

[kingozrecords]

And in that regard; the 64 bit version has an issue with phase; when using saturation. I've troubleshooted the issue; for those who work with flowstone, I needed to write My own selectors and multiplexers 4 64, IE:

Code: Select all

lout1 = left * ((bool==1)&1)

with DSP code. Worked well, though it got a bit convoluted after a time.

What's the intention of that code? To forward the left channel if bool is set to true? If that's the case then I think the following code would be much easier to read (in case Flowstone supports this syntax):

Code: Select all

lout1 = bool ? left : 0.;

It would also be more efficient because there is no useless multiplication involved. Although the compiler might be able to optimize the multiplication away in the original code snippet. It would be even more efficient if the boolean was only evaluated once per block.

yeah, I don't add spaces to code; I used to work in css, php and javascript. But to answer your question it's a switch saying that if a boolean or int is 1 and not 0 it turns on. I was having problems with taking 32 bit code over, it solves that dilemma.

Also, interestingly; I replaced instances of stereo width with another method; I guess the nested calls caused a glitch. It's why the earlier version seemed like it had a steep hp.

It's rare to find VST's made by mixers and producers but I have seven years experience and countless errors in processing that have led Me to understand the craft with some integrity.

You still insisting that tape heads run faster because they have latency, that you 'oversample' tape to get a hotter signal, and that the government limited audio recording to 20KHz and under for WW2 propaganda purposes?

To whyterabbyt, I've always been impressed by cassette due to the fact that there is no heat generated, and due to the plastic gears, the tension about the same. As far as analog went, in cassettes there was less dirt because ultimately the surface of the tape didn't expand with the heat, or stretch due to tension and heat in unison. Saturation from heat is another matter, certainly.

Though there is scientifically no convention to back up My claim, the saturation I utilized sounds a bit more like cassette.

It would also be more efficient because there is no useless multiplication involved.

But you use a branch which is even less efficient, especially used in loops. The key to performance is to integrate conditionals into arithmetics, saves the jump. There are nice talks from Andrei Alexandrescu at cppcon about it.

And yes BlurprintInc, I follow the same method of thinking. I believe it is better to save memory with conditionals. I like things to gracefully turn off. Because though for vocals; this could be used for other things; and many times over.

[BlitBit]

It would also be more efficient because there is no useless multiplication involved.

But you use a branch which is even less efficient, especially used in loops. The key to performance is to integrate conditionals into arithmetics, saves the jump. There are nice talks from Andrei Alexandrescu at cppcon about it.

The original code by kingozrecords will also create a branch because the condition

Code: Select all

(bool == 1)

will not be evaluated magically to true or false, i.e. 0 or 1. You can see this by feed the following code to Compiler Explorer:

Code: Select all

float select(float * left, bool value) {
    return *left * ((value==1)&1);
}

float select2(float * left, bool value) {
    return value ? *left : 0.;
}

The result when compiled with gcc 9.2 and the option "-O2" is:

Code: Select all

select(float*, bool):
        movss   xmm0, DWORD PTR [rdi]
        test    sil, sil
        jne     .L1
        mulss   xmm0, DWORD PTR .LC0[rip]
.L1:
        ret
select2(float*, bool):
        pxor    xmm0, xmm0
        test    sil, sil
        je      .L4
        movss   xmm0, DWORD PTR [rdi]
.L4:
        ret
.LC0:
        .long   0

So as I have said the original code still has a multiplication (mulss) and it also has a conditional jump (jne). The more readable code with the explicit condition (je) only has a move (movss). And as already mentioned if you are working on block or buffers you will only need to evaluate the boolean once per block and then it will boil down to either copying (moving) the input buffer to the output buffer or to resetting the output buffer to 0. No costly multiplications involved here.

[BlueprintInc]

I wouldn't use either, but probably something like this:

Code: Select all

float select3(float * left, bool value) {
    return *left * value;
}

Anyways I'd benchmark the cost of a simple multiplication which can already be combined with other operations vs. the 50% chance of a failed branch prediciton and the jumps.

[vurt]

It's rare to find VST's made by mixers and producers but I have seven years experience and countless errors in processing that have led Me to understand the craft with some integrity.

You still insisting that tape heads run faster because they have latency, that you 'oversample' tape to get a hotter signal, and that the government limited audio recording to 20KHz and under for WW2 propaganda purposes?

tell me more! sounds like the kind of information i need to know!

[whyterabbyt]

It's rare to find VST's made by mixers and producers but I have seven years experience and countless errors in processing that have led Me to understand the craft with some integrity.

You still insisting that tape heads run faster because they have latency, that you 'oversample' tape to get a hotter signal, and that the government limited audio recording to 20KHz and under for WW2 propaganda purposes?

tell me more! sounds like the kind of information i need to know!

he used to post as wolverine6. had a 'psychic method' of recording.

viewtopic.php?p=6301194#p6301194

[vurt]

cheers!

[vurt]

quick skim!
i think im in love

[whyterabbyt]

quick skim!
i think im in love

i think he thinks he was Lee Perry.

[vurt]

quick skim!
i think im in love

i think he thinks he was Lee Perry.

someone had to have been...

[BlitBit]

I wouldn't use either, but probably something like this:

Code: Select all

float select3(float * left, bool value) {
    return *left * value;
}

Anyways I'd benchmark the cost of a simple multiplication which can already be combined with other operations vs. the 50% chance of a failed branch prediciton and the jumps.

This gives the following by the way (again with -O2):

Code: Select all

select3(float*, bool):
        movzx   esi, sil
        pxor    xmm0, xmm0
        cvtsi2ss        xmm0, esi
        mulss   xmm0, DWORD PTR [rdi]
        ret

I cannot imagine that a multiplication is cheaper that the simple moving of data. Also if the boolean does not change often or randomly then after several executions the branch prediction should make sure that the current correct path is taken every time. But I agree that profiling is a good idea anyway.

[jochicago]

that the government limited audio recording to 20KHz and under for WW2 propaganda purposes?

I don't want to derail this thread further along, but I'm trying to understand. What would be the propaganda advantage of low-passing at 20khz? What's the expected psychological impact of removing inaudible frequencies?