signalsmith-audio / signalsmith-stretch Goto Github PK

I tried using the "process" method to change the time and all that happens is an array of zeros in the output.
It could be due to the fact that it uses GNU G++ as a compiler and not CLang.

            float** insamples = new float*[1];
            insamples[0] = new float[decodedSF.size()];

            for(int i = 0; i < (int)decodedSF.size(); i++){
                float copysample = ((float)decodedSF[i]) / (float)32768.0F;
                if( copysample > 1.0F ) copysample = 1.0F;
                if( copysample < -1.0F ) copysample = -1.0F;

                insamples[0][i] = copysample;
            }

            float** outputBuff = new float*[1];
            outputBuff[0] = new float[decodedSF.size()];

            stretch.configure(sampleChannels, decodedSF.size(), decodedSF.size()/4);
            stretch.process(insamples, decodedSF.size(), outputBuff, decodedSF.size() - 100);

            stretch.reset();

"decodedSF" is a sf::int16 vector.
"outputBuff" only returns 0 regardless of the size required in the output.
"sampleChannels" is 1.
"decodedSF.size()" é normalmente 320.

Thanks a lot for providing this. Do you know how it compares to other libraries (such as rubberband) in terms of cpu load? As in, how much slower/faster is it to transpose a 1s sample by 12 semitones for example.

Normally, when working with (a stream of) samples, the channels are interleaved (L1R1L2R2...LnRn).
Your library expects all the samples of one channel to be contiguous (L1L2...LnR1R2...Rn).

Now, in order to know where the first right channel sample is located, we need to account for the length of the buffer.
With interleaved samples, we always know the offset of any sample+channel with just the requested sample number and channel index.
So if we have a buffer of samples which is filled over time by an input device, we can't just keep adding samples to that buffer and sending it to the stretcher whenever we want. Either we have to sort the samples by channel or have a weird buffer filling strategy.

AFAIK, it is industry standard to interleave samples of different channels, so now everyone needs to adapt their buffers when interfacing with your lib.
Of course this can be remedied by creating a class which defers the sample access from a buffer to a function which switches the arguments of the subscript operators. However, instead of forcing this on devs, I think it's better to adopt the common style in this lib.

Aside from this, awesome job on this project! It's very cool that we have now have a open source stretcher competing with the quality of paid alternatives!

When working with multiple channel data, the variables "inputSamples" and "outputSamples" reflect the number of samples in one channel, not the total number of samples being used by the algorithm.

This is not documented, and in my opinion, counter intuitive.
I would suggest adding this information in the documentation.