De-zipper code?

[Perfect Human Interface]

Hi! I hope some of you gurus are still hanging around here because I have a question about something.

The de-zipper is a primitive component but I'd like to be able to recreate it's functionality outside of flowstone. The de-zipper appears to smooth out transitions in a completely linear manner which is what I'm looking to recreate (vs. the low-pass method which creates a logarithmic transition).

Does anyone happen to know how the de-zipper code works? It would be great if you could enlighten me.

Thanks in advance!

[TheOm]

This is not exactly the same as the de-zipper but it limits the rate of change of a value, so it never changes more than the limit per sample. This will give you a linear transition with a time proportional to the distance of the start value and the target value. The Dezipper always takes the same amount of time, no matter how big the difference.

[Perfect Human Interface]

Oh thanks a lot. I can't read Assembly though so unfortunately that doesn't do much for me.

Also yeah, it is important to have the transition take a set (or settable) amount of time. I really need that exact behavior.

[Spogg]

Big thanks to TheOm for that.
Directly into my toolbox!



Spogg

[TheOm]

Here's a module that acts like the real dezipper.

[Spogg]

And another goal!

Many thanks for these. I usually use filters for stream control slewing so these are a great alternative.

Many thanks.

Spogg

[Perfect Human Interface]

Sorry for the late reply. Thanks a lot for the last example.

I shared the code with my partner (he's the "real" programmer), and he implemented something but I don't think we got it quite right. This is how he described his interpretation of it:

float new = new input sample
float old = previous output sample
float coef = smoothing coefficient


old = old + (new - old) * coef;
output = coef;

If there's something missing here could you let me know?

By the way, I discovered something interesting! With the dezipper, when the input value changes, it's smoothed to that new value linearly, but if the input is changing continuously, it appears to smooth logarithmically. I can only guess that the input changing continuously causes the algorithm to update at each step which manifests as a curve. I attached an example project to demonstrate.

By the way, the Assembler dezipper that TheOm provided above doesn't seem to work at all with the input changing continuously.

[Spogg]

I’m definitely not a code-head but, in the code example you show, I can’t see how constantly outputting the float “coef” would help. Surely you’d just keep getting the coef float value…?

Also my experience has taught me not to try and use the stock de-zipper in any a stream, to process the stream itself. You don’t get expected behaviour but instead lots of unpredictable audio crap somehow. I only ever use it as God intended, as an interface between green and stream. I don't think it helps that the input pin can be shown as a stream type.

Cheers

Spogg

[Perfect Human Interface]

I’m definitely not a code-head but, in the code example you show, I can’t see how constantly outputting the float “coef” would help. Surely you’d just keep getting the coef float value…?

Oh you're probably right. That's just what he wrote in an email so I'm sure he mucked it up.

Also my experience has taught me not to try and use the stock de-zipper in any a stream, to process the stream itself. You don’t get expected behaviour but instead lots of unpredictable audio crap somehow. I only ever use it as God intended, as an interface between green and stream. I don't think it helps that the input pin can be shown as a stream type.

Yes this does make sense, and I've completely forgotten that it was really meant for that. I've been using it this way successfully for a while. I think the only oddities with doing this are 1) what I described in the last post (values smoothed logarithmically), and 2) at very low transition times you get scratchy results. I'm still using it on modulation, not like audio or anything (ok yeah I've tried that It just sounds like a garbage low-pass).

Thank you for the input. This is all making more sense to me now. I was thinking about the linear/logarithmic behavior and I think the bandlimited square wave is a worst case scenario, where you get pretty drastically different behavior between the bandlimited and non-bandlimited square inputs even though the inputs are nearly the same.

Anyways, we're still just trying to recreate the behavior. It's important that the smoothing respects the amount of change and the transition time rather than always transitioning at the same constant rate so I think this is the only way to do that.

[tulamide]

I might be totally off, caused by misunderstanding, but in general the de-zipper is a form of linear interpolation.

Code: Select all

a + t * (b - a)
## where a is the previous sample, b the current sample and t the percentage (0.0-1.0) to move from a to b. Changing t over time makes the transition. For example, if you map 30 samples to 0-1, b (no matter how it changes) will be reached at the 30th sample. If you also change a per sample just like b, you still reach b at the 30th sample, but of course it will result in a more sensitive curve.

This is a strict linear approach. It means, no matter how far the distance between a and b, if t equals 0.5 you have exactly the midpoint between them.

But I'm not sure, what you are really heading for?