Hopsize as a float?

Can the hopsize of FluidBufSTFT be a float, like 2.568 or something? It doesn’t seem it, but I don’t see why not.

sadly, and @weefuzzy will confirm 100%, our STFT is only sample-accurate, not subsample-accurate.

That is not what I am asking. A decimal hop would be necessary to implement Nessy’s and my TimeStretch using Fluid stuff (it rounds to the sample, but hops to the decimal). But since I would have to go into the source to make new objects anyways (for custom windowing between frames during resynthesis), it is fine if this feature does not exist. Love looking at the source btw. It is real pretty!

1 Like

It is clever beyond reckoning. @weefuzzy and @groma (and @a.harker for some bits) have done quite a framework… expendable and flexible… as @balintlaczko was telling me yesterday, there is quite a lot we can already do - but even more to come!

1 Like

Sounds like you want some framelib in your life

I think Harker felt this wasn’t possible with FrameLib. We have it working with SC and python. But a straight up c++ implementation would be so dope (and so much faster).

indeed. the library is not yet easy to use in (let’s say) openFrameworks but it is on my next year ambitions for myself to understand enough the code under the hood to do it - so you could do your OLA there and the nmf with our tools in C++ and a cute interface :slight_smile:

Ah…I was under the impression you could do sub-sample timing but maybe not for the FFT itself.

The idea if @spluta recompiles is that the accumulator of the time passing (in hop) could be in float and then round off to the nearest sample (in int) to take the window in order to avoid having to resample/interpolate the content of the window. That way the accumulator does not accumulate error and if one wants more precision, one can oversample the FFT by zero-padding the window (which we already offer)

Now, going deep inside the code to get hop to behave as float is not something light :scream:

I think if one were to do this, the way would be to make a new client type that has a floating point stretch parameter that can be used to deduce the synthesis hops. I certainly wouldn’t try and mess with the FFT settings object.

1 Like

Do you have the algo source around on github? i’m interested…

I was just looking at it, funnily enough


Ah yeah, ive gazed on this before.