question about dezippers

trogluddite · 31 Mar 2012

Not quite sure I'vegot my maths head on, but I think you there may be a limit of a few minutes IIRC, the de-zipper makes a linear ramp between old and new values - so there must be a 'Step' parameter determining the change per sample. As it is usable in poly/mono4, the maths is all presumably 32bit float. If the current value is very large, and the step very small, the step may be too small to effect a change on the value. If the current value is near maximum=1 then the step can be no smaller than 2^-24 as float numbers have 24 significant digits (bits). If rising from zero, a smaller value would work for a while, up to a point where it reached the 2^24 ratio, and then stall. Alternatively, you could keep a counter of elapsed time and scale accordingly - but there would still be similar resolution limits, and integers have much more limited min/max. If I'm right about the floats, there would be about a 6 minute max' time to go from 0 to 1.

oddson · 31 Mar 2012

There's likely no point in smoothing something that much.

Smoothing is needed because even small amounts change in a green value can show up as an audible jump in a data stream.

The reason you can choose the rate is that very fast smoothing may be appropriate for some uses but sound glitchy in others while a slow rate (1000 ms) will take too long to stabilize and not follow the control signal quickly enough.

If you used tens of seconds it's unlikely the output would ever catch up to the control value.

On the flip side I just tried with 1 million MS (2.8 hours) and it seems to work (although I'm not waiting to see if it goes all the way to the new value!).

(D'oh! Trog beat me... but did he try to test?!)

oddson · 31 Mar 2012

trogluddite wrote: so there must be a 'Step' parameter determining the change per sample. As it is usable in poly/mono4, the maths is all presumably 32bit float.

That's likely right as very large numbers just seem to stall. I did my test shifting for 1 to 0 from an integer feed -- but with realistic values (hundredths or thousandths) then the limit will be much less.

oddson · 31 Mar 2012

Check this:

trogluddite · 31 Mar 2012

oddson wrote: There's likely no point in smoothing something that much

Yes, for very long ramps, two stages may be better - a "green" section, low update rate but able to be accurate time-wise by reading the System Time primitive; possibly followed by a de-zipper to hide any stepping in the green signal. That should be able to give modulations over millenia if required!

tester · 31 Mar 2012

I made a random/irregular oscillator using greens (for smoothing between triggered random values - dezippers; they produce output 0-1 stream for further scaling), and now placed this gen also in the sloooow modulation section which modulates parameters of other modulators; time = in seconds (max c.a. half hour expected there?). I used dezippers because this seemed to be the simplest way and was under my hand. So in essence it does not have to be very accurate, it should be just in time-dependent motion. Alternatively I probably place few random triggers per one "modulation cycle" because this is randomness anyway (cycles represent rather relative ratios).

I decided to use this kind of gen, because is very fast, I have no issues with code (behaves irregularly stable), and at least i understand what I do on greens 😉.

I'm trying to decode what you are saying about alternative for dezippers, but my english seems not follow. Are the dezippers fine here or should they be replaced by what?

oddson · 31 Mar 2012

tester wrote: I'm trying to decode what you are saying about alternative for dezippers, but my english seems not follow. Are the dezippers fine here or should they be replaced by what?

dezippers - if needed at all -- are likely fine with small values for duration. The green oscillator with dezip is the two stage solution. But the green works at the very long time scale so the dezip doesn't have to. It can just get rid of jumps in the movement between green increments.

tester · 31 Mar 2012

I read you but don't understand you (or your english syntax).

In my schematic (see other post below about random gens) - green produces jumping/random values, dezipper prodcues smooth transition between them. There is no oscillator after dezipper; dezipper with green is the oscillator. So there is needed two stage solution here, but my original question was - if not dezipper, then what (so simple and effective like that) ? But if dezipper can handle longer durations, then it's fine. Besides as I said - inside I can put few triggered steps, and still control "relative ratio" in such produced randomness.

oddson · 31 Mar 2012

I think the lack of understanding is mutual. 😉

Let me know which of these are true or not true.

1) You have some sort of module that has slowly changing data remaining in green format (not a stream at sample rate). 2) the output from this is used as input for some purpose: a) at stream rate and the float changes from green data is too jumpy b) as green data but the output from the first part is too jumpy

If it's not 1) then you have to re-ask the question. If 2a) then a dezipper between the green generator and the input will get rid of any nasty jumps If 2b) then you need something like a green-dezipper -- try the slide primitive

If I'm still not getting it try me again. 😇

tester · 31 Mar 2012

Sometimes I have difficulties to get the context from what I'm reading; weird - understanding words and having no clue what is it about. Algorithmic methods always work 😉 Thanks for "slide" module, I was not aware of such thing there (or that this will be under such name). Regarding the topic itself. I'm using this design (random generator.osm) - connected to several parameters as a modulator. And still thinking whether redesign it or not. Generally the concept on slow modulator is to make something opposite to regular/periodic behavior (i.e. smooth iregular unrepeatable but pattern) - to have both options.