lost in ruby (mono to float)

[payaDSP]

Hello;
Im trying to make a LFO with float output to use this for commanding knobs.
seems obvious but...
i monitor the result with scope (cf shematic)
but with classic signal to float i get an awful stepped curve
with signal to float + (various) de zipper-smoother I get stepped curve with less visible step, but loss of the amplitude, and phase decay (anyway not a smooth suite of float)
searching forum i saw (approx) "mono to float is known to be approximative, but it is easy to make ruby conversion"

well it is not easy to me...
if someone could help
(or if there is something else to make without ruby)

Thanks
paya

[nix]

Hi there!
I had a go at it->

mono to float LFO_0.fsm

(162.98 KiB) Downloaded 954 times

I wonder if this device is intrinsically quantized in FS.
The only way to not quantize discernably I can think of is
that maybe it can be done with 'mono to frame' in Ruby

Welcome!

I can keep trying if this doesn't work well enough

[nix]

I think you need something like this, but I can't get it to output anything->

how to code the ruby_query_.png (35.65 KiB) Viewed 23436 times

RUBYfloat smooth.fsm

(354 Bytes) Downloaded 931 times

Cheers

[Spogg]

The basis of the problem, as I see it, is that once you enter the GREEN world you lose any timing accuracy. Green isn’t an audio rate process and is only dealt with when the STREAM world has allowed some time to be available.

If you look carefully at the waveforms out of the M2F prim, at higher LFO rates, each individual converted wave is different, due to the green process not being in sync with anything. No amount of “smoothing” in the green world can deal with this properly; garbage in, garbage out!

In my own mono LFOs I go into the green world in the same way, use a stock de-zipper prim then back to poly but I have to limit the upper LFO frequency due to this effect. It does work over a reasonably useful LFO range though.

However you generate your LFO, if you want the wave to get into the green world you’ll hit the problem at higher LFO speeds.

If I’m wrong or there is a way to do this I’d love to see the method!

Cheers

Spogg

[nix]

have a look at the first file I posted,
the 'slide' prim does something trick, at faster than tick100 it seems(using a ms).

In digital audio we are always quantized,
but green data is particularly iterated, working on a trigger system.
the mono always needs to be read from a tick-
which is limited to 500hz within usable CPU.

Like I say- a float array can be delivered 'by mono to frame', but it's a hectic problem to get it to stream.
We still end up reading the mem or float array with a samplerate counter.

[Spogg]

Hi Nix.

Here is a scope trace directly from your example. You can see the sample time period from green is inconsistent. As I undertand it whenever you go into green you'll ht this issue. You can see the conversion from the 2 positive-going edges are significantly different as a result.

Cheers

Spogg

[nix]

I am certainly not arguing that the floats are hifi,
they are 500hz.
Here is the higher samplerate realized by turning slide on,
which is surprising IMO-->

less float quant from slide.png (18.93 KiB) Viewed 23409 times

[Spogg]

Nix, I understood that the max rate of green was typically about 65 Hz and it varies quite widely, not 500 Hz. Maybe tulamide or someone can confirm that .

I got similar results just using the stock de-zipper. If you increase the "slide rate" it performs like a filter with phase shift, as per your trace, which looks like about 90 degress. I tried putting in a HUGE time for smoothing then amplifying the output also by a huge amount but the result is still steppy at the higher frequency end. I assume it's still steppy because the green timing is unstable.

I don't do Ruby but I can't at present see how to get around the Green timing barrier, if the final result has to be output in green.

It would be nice be wrong on this one

Cheers

Spogg

[nix]

Ruby has allowed us to break the tick 100 limit,
also allowing a greater steadiness in periodicity.
Here is the 500 hz:-

500hz tick-heavy CPU.fsm

(1.06 KiB) Downloaded 908 times

Is there a stock green dezip?
I only have the blue one atm.
I can reconstruct an approximate sine probably in blue, after the m2f

edit- here I have made the Ruby simpler,
do any of you think it could use less CPU somehow?-->

simple tick_1.fsm

(858 Bytes) Downloaded 905 times

[Spogg]

No green de-zipper prim; you have to use slide as you did.

I agree your counter runs at 500 Hz but the problem comes when you look at the stability of the counter output. I've added a basic scope and copied the Ruby ticker to reset the counter every 1 second. This produces a repeating ramp for the scope.
If you capture a ramp by pausing the scope you'll see unevenly timed steps in the ramp. Also note what happens to the counter Integer display with the scope running or paused. You can see how uneven the count is. As I understand it this is due to the increased green activity within the scope itself.
The implication is that no matter what Ruby can do you won't be able to get around this green behaviour and the OP wanted his LFO to output in Green.

Cheers

Spogg

EDIT: maybe that green counter prim is a bit special