DSP Robotics Support

Run it at 10BPM for example:



as you can see in the picture: INDEX it is not 5 yet, but it has already read the values from stream at index 5. They seems unrelated.

I guess index 0 is the first sample and index 44 is the 44° sample from stream? Or is here where am I wrong? Using fast speed you won't notice this, but in fact at slower speed its pretty clear.

I think it's a floating point error. In fact, if I look at the Float outputted from DSP code:


and catched by M2F, I get values such as this:

7.82008
5.39003
8.08009
since I increment it by 0.01, I can't have floats with 5 digit after the dot. What's happening on this increment?

So, I've place some fixed float value as i. And I've noticed that it reads the samples in a very "strange" way.
These are the results:

fixed i between [0.00, 0.50] => it reads Sample 1
fixed i between [0.51, 1.49] => it reads Sample 2
fixed i between [1.50, 2.50] => it reads Sample 3


for me those values makes no sense at all For example:

1 - why second value occurs after 0.50 instead of 1 at the beginning? (this is a huge problem, because it introduces an heavy offset).
2 - why the limits are sometimes 050, sometimes 0.49? (even if this is almost irrilevant; its only an approximation I guess).

How can I make this reading robust?

Yeh, it's always missing the first sample here.
The "nix" idea sounds good now....use Ruby frame to get control of each sample.

billv wrote:Yeh, it's always missing the first sample here.

Uhm, it is not missing the "first" sample honestly. Its that between first and second and second and third the reading timing its different. In fact it reads all the samples. So, I can't rely not even in stream timing?

billv wrote:The "nix" idea sounds good now....use Ruby frame to get control of each sample.

nix or tulamide? Do you mean this one? viewtopic.php?f=2&t=3831#p21170

I don't know how I should implement it, but I guess I can't do it with Ruby, since it runs at very low clock As I said, calling ruby every 0.001 (1ms) eat lots of CPU resources. That's why stream looks good.

Or maybe I'm confusing what you are saying?

I read about Mono to Frames on the Manual, but I don't get the point. It says: "The Mono To Frame component takes Mono stream data and delivers it one frame at a time in precise sync with the stream".

But stream itself is async (as shown in my topic above). Let says my audio card/asio works with 256 samples per frame: every 256 samples on stream, I can manage that frame with Ruby.

But what's the point? I'm already "out of sync", since stream is.
I guess I need to don't use stream so? Also because I've the problem that Read at index 0.5 will always output the second sample

Going to "Frame Sync" paragraph: if I link Frame sync with Ruby use 9% of CPU doing nothing, so I believe that's not the suggestion.

Ruby frame from Float array? Please help me, I'm very confused

Sorry to have confused you Nowhk,
I will make the Fruity LFO with help tips next to each part.

You can rely on stream timing pretty much essentially.
It is fine for samplerate changes.

So in my example, I simply demonstrated the stream counter reading the same as the LFO's float array.
You can see they are perfectly synced. If you have the counter and reader running at the same time,
and left click a blank part of the schematic, it will pause and show you the same value.
The stream parts(not ppq trigger) change every 44100th of a second, much too fast to see.
The value climbs every sample.

The counter where you originally had .00001 as speed, I changed to 1. This means it counts at samplerate.

nix wrote:The counter where you originally had .00001 as speed, I changed to 1. This means it counts at samplerate.

Yes, but that's my problem.

I want to read my samples at "different speed".
If I use 1 as counter, as you said it is "sync" yes, but the reading of those value its too fast.
If I want to slow the reading speed, I just need to use float values as increment, so it does (at the same samplerate speed) more iteration, slowing down the reading of them.

But as I stated above, using this process and the "READ" module seems to sucks. Also in your example this problem happens (using 0.01 instead of 1 as step):


You can see that index is 0.61, and it has already read the second sample (i.e. value 1).

That's because the second sample it's readed at 0.51 instead of 1.00 (0.50 of gap between first and second sample).
Than the gap between reading the next sample is 1, not 0.50 anymore.

I know this won't be a huge problem working on a wave with 1024 samples, but if I've these troubles at the beginning, they would become precarious.

I want to understand why it reads the samples in this way, for my future applications.
Is it a bug? Or is it a sort of math approx?
Because if it's correct, ok I can use it now and forever.
If it will change in the future, that's would be a problem. Any clues?

P.S. I won't never stop to say thank you to everybody here, you are really helping me a lot these days! Thank you

Here is a screen where the LFO changes value every second at 44.1k->
http://imageshack.com/a/img907/2095/4hKA85.png
Here is the schematic->


So the counter counts to 10 seconds(441000),
which I have divided into 10, giving 1 second integer steps.

Cheers mate- IMO you will get this to do exactly what u want

nix wrote:Here is a screen where the LFO changes value every second at 44.1k->
http://imageshack.com/a/img907/2095/4hKA85.png
Here is the schematic->

schematic_1 second s&h.fsm

So the counter counts to 10 seconds(441000),
which I have divided into 10, giving 1 second integer steps.

Cheers mate- IMO you will get this to do exactly what u want

Well, I don't know the trick of /44100 and get 10 seconds (and I don't care right now), but what made the trick is that "-0.5" linked to the Read module: now the results seems correct.
In fact, it makes correct result even with my old code, using 0.00001 as increment inside DSP code.

Now please (pleaseee) explain to me: why there's that "0.5" offset in the Read module? Is it a bug or somethings that I don't get in any way?
Its a problem with my mind: I need to understand things

I really don't get why of that offset... shine me!!!

10 seconds is 441000 samples

The .5 was needed because of the way the reader receives a stream integer,
even though it is just a blue mono dot. There are only polyint connector types.
The stream needs to be reduced by .5 because of a rounding error on the integer(whole number) conversion,
you know, like .6 rounds to 1, but .4 rounds to 0

So nice it's working now! You just need to be able to set bpm and be samplerate independent

8D

nix wrote:10 seconds is 441000 samples

Uhm, but if Flowstone stream works at 44Khz, this means that it does 44100 operation in 1 sec. So 44100 samples should be 1 second.

nix wrote:There are only polyint connector types.

This is a new nice question to ask: if I put a "green" connector to a blu pin, it is always evalutate every time it got a new stream value? Or just one/first time? Because I know green is way slower than stream to be processed, this could make delay on processing stream itself (441Khz sync).

nix wrote:The stream needs to be reduced by .5 because of a rounding error on the integer(whole number) conversion, you know, like .6 rounds to 1, but .4 rounds to 0

Not sure about what do you mean with rounding error. You mean that every float (from 1.0 to 1.99) must always round to 1 as integer? But seems that FS works already this way

nix wrote:So nice it's working now! You just need to be able to set bpm and be samplerate independent

Yes it starts to be a plugin with some senses Thank to you, again!!!!!