lost in ruby (mono to float)

[nix]

hmmm,
nice method.
maybe i will make a pulse osc or something in Ruby.
Yeah, it is still a bit wonky, and is affected by computer events,
as you say. Is the handling called DPC?
It is much better than the old tickers though.
There was talk of Ruby sycing to MIDI by RDSP,
but I am not sure that it does 100%.
I have found it usable for things like sequencers and audio capture.
The sequencer runs to a usable accuracy,
and the array resampling pitch shifter has no discontinuities in small host projects.

Yes- we cannot gaet a hifi float stream generally speaking(or at all).
I hope the methods here might do though.
Probaly they are fine for UI updating, while the plugin is actually using a stream ideally.

[Spogg]

Regarding the fine details of thread handling and such I'm not the one to ask.
This needs one of the wizards to jump in.

I came across the limitations of green a long time ago having started off with the assumption that everything would behave like analogue electronics but it doesn't!

Anyways, it was very interesting to discuss this

Cheers

Spogg

[tulamide]

To de-mystify Ruby a bit:

Plain Ruby runs with a internal clock that allows for 100 Hz. That does not mean you can rely on getting 100 exact timed pulses per second. It not even means you can rely on getting 100 pulses. It only means that the interpreter is getting control to do something for a maximum of 100 times per second.
So, each pulse (or frame, as I prefer to name it) has a window width of 10 ms. If the task that is currently in work takes more time, say 15 ms, a pulse is lost. If it takes 22 ms, 2 pulses are lost. And so on.

It should be clear that this leads to inaccuracies. You can hide quite a lot of it by using interpolation, but still it is not reliable in terms of audio.

That's why DSPR added an option to synchronize to streams. If you do so, you have to work buffered. Everytime, the streams send a new buffer to audio out, this buffer is sent to Ruby and you have the option to change the buffer data. Since it is a buffer, you have some more time to deal with it, but here as well it is important that the work Ruby has to do does not exceed the buffer time. If you can manage to do so, you can rely on sample accurate timing.

Regarding graphics, again, Ruby is not pulse-reliable. Ruby is a self-managed language, which means, it does some work in the background that you are not aware of. One of it is garbage collection (freeing RAM from objects that are no longer needed). The gc is lazy, but when it comes to action, other tasks have to wait. Also, commands are pipelined. Say you have a method like that

Code: Select all

def foo
    @a = 2
    redraw
    @a = 3
end

some of you might expect to have @a at 2 when the redraw starts (@a may be drawn in the draw method), but that's wrong. the command redraw waits until the method has done its work and only then starts to draw. Even worse: Say, you have two of those methods, that you call one after the other. Now "redraw" won't take action until both methods have been worked through.

The best approach therefore is to not mix calculations and drawing commands. Instead imagine the calculations as a football game and the drawing as the cameras. You are not aware at what time the camera actually records nor what target the camera films. So make just sure the football game runs smooth while ignoring the cameras.

[payaDSP]

hi
thanks for all your posts, sorry for late answer (just coming back home)
i will look your schematics
i have try another way (for LFO only)
i use oscillator based on text wave table > extract directly the float
it s a little better
but i believe ruby is the best way
regards
paya

[payaDSP]

@nix
thank for your schematics
i have also tried to increase sample rate, but always with steps in result, and loss of accuracy in higher frequencies.
(for the ticker i did not achieve to make it in ruby as you do)
seems SLIDE (i did not notice this exits in FS) makes approx the same thing that other smoothers in DSP

@Spogg
i think there is an bias with the way float are refresh on the screen, and in scope. this amplify non accuracy of green
according the SCOPE you use, the results are not the same (steps always present, but with more or less regularity)

i look for a way to get smooth LFO float signal (under 20-25 Hz i know higher frequencies are out of reach)
the nearest result is in my last post: using wave table osc (increasing details of text table is a good option), missing now adding "real" blue signal at the same frequency

thanks to all
regards
PAYA

[tulamide]

I thought it was about making it in Ruby. If you are only interested in LFOs, there are already DSP-optimized (assembler-based) LFOs by Martin. Just search either the user section or have a look at Flowstone Guru.

[payaDSP]

@ tulamide
i try with your link, i get (again) awfull steps (even with low freq):
ruby is the answer (far from my knowledge)

[tulamide]

Hey paya,

the more I see of your attempts the more it confuses me. So let me ask

1) Is what you are looking for a way to display the generated data from the LFO?
2) Are you aware that a table of floats can only be continous in green if you buffer a lot of them?

You might want to have a look at the Signal Analyser Prim. Also, have a look at the Mono To Graph Prim. You can also look inside the oscilloscope of your example fsm and from there into the module Graphsx4 B to see how data is continously buffered and displayed.

[payaDSP]

Hi tulamide
thanks to your interest
my whishes are not ambitious
i look a way to use LFO to control knob and XY pad (witch are coded with float or ruby, as far i know)
i can do that, but when you look carefully the result there are always steps in the LFO final signal when it is converted to float to be understood by "effectors" . so the result is not so smooth i wanted.
i understand this is difficult because it is 2 different worlds, but every parcel of GUI is float dependent.

I have already look into many scopes who DO convert float to continuous (visual) "signal" but i did not manage to get fluid float out of them

my workaround N°1: use wave table in array, with high sample rate, then read it. it generates directly famous float ready to use.

my workaround N°2: use LFO directly to modulate other signal and intercept process somewhere to get something visible on the GUI. this eliminate the sequence LFO> signal to float (bad) > GUI > float to signal modulation (where the errors in 2°step are increased in subsequent steps)
we have instead LFO >signal modulation>signal to float (bad) > GUI (where the consequences are "only" in the GUI and not in the signal treatment) ... BUT with less interaction from user

i know that all this is due to my lack of knowledge of ruby
please be indulgent with my poor English (and my schematics )
regards
PAYA

[tulamide]

paya,

your workaround N°2 isn't a workaround. It is how things are done, not just in Flowstone, but in every VST. Even on the most advanced CPUs you will only get a few dozen of frames per second (the speed at which the GUI is drawn), but you will get 44100 pulses per second on the signal. This makes pretty clear that you can never get the same resolution between GUI and signal. One will always suffer, so logically you will let suffer the GUI. You just interpolate between the snapshots of the signal at GUI rate.