DSP Robotics Support

The manual says:

The schematic clock runs at 100 Hz. Unlike the Tick components which are not time precise due to
their use of Windows timers, the Events system uses a different timer which is much more accurate so
each 10 millisecond tick should occur precisely on time.

This means that if I call events under 10ms they might be not in synch? For example:


call an event every 1 ms. So 10 times between 2 clocks. They can be un-synch so? Occuring essentially not every 1 ms?

This could be a problem, since I'm making a LFO that change many values during the time, that will occurs around 1ms or less...

Any ideas?

I say try it and see if it sounds good enough.
Maybe as long as it has no discontinuities/doesn't click.
1000hz does stress the cpu use though.

There is one way to get a tick in samples. A frame can be used to trigger a frame.

I think the hint just uses 10 ms as an example.
If you want to test it, use mono to float and a stream.

This can be a problem for me in Flowstone so.
I make an LFO plugin that make random shape, and works on (max) 1280 discrete values, getting a smooth shape. This is a generated 500 values shape:


Once got it, I need to iterate these values; than output (index and the value in my case) at each step:


the output is "smooth" using @lfo_freq value >=0.01, and it doesn't requires too many resources (I'm about 2-3% of CPU).

But for this general purpose, the ouput is slow: It tooks such as 6-7 seconds for process all values (automating the linked controller, in FL Studio, in my example).

If I need to process the whole shape in (let say) 1 seconds, I got the problem.
Because using @lfo_freq = 0.001 for example, it will eat lot of resources: such as 45% Even if I remove all unused modules (draws, labels, and so on).

Is Flowstone heavy on resources? Or how usually plugin manage this huge amount of values? For a smooth signal, I guess 500 "samples" are required "at least".

But I see on some other app that I can process (speed) them quickly. Can I improve the whole mechanism?

You can't rely on exact steps in time. Never and nowhere. I could explain why Flowstone doesn't always get the system's attention at exactly the same time, but that's a long and boring story. To cut it short: That's not the way things work.

This was very apparent in game development, where continuous movements are key to the gameplay mechanics. So they started early to use indirect code, instead of direct one.
If you want to do something continuously you have to use deltatime, short dt. The system clock is the only reliable timing source you have. Therefore, dt measures the time between the last and the current step (in games called "frames") in system clock's ticks, converted to seconds.
When you add those deltatimes, you will always get to one second, no matter in how many frames. It guarantees a constant movement over time, instead of frames.

Say you have to move a sprite by 20 pixels over one second, and your application runs at 30 fps (frames per second). In the ideal case one frame would last 1/30th of a second, or 0.03~s. But in reality, the frames rather take something like 0.03, 0.03, 0.02, 0.07, 0.05, 0.03, etc.

Calculating frame-based would result in 0.66~px per step (this value multiplied by 30 results in 20), but if you compare it with the above sample sequence, you'll see that at the fourth step the duration is more than twice as long. Which makes the movement at this step half as fast as it should be.

The solution is deltatime. Since you know how long each frame is, instead of adding a fixed portion of the distance on every frame, you add a relative portion which is the distance times dt:


Now the distance per step will vary, but therefore be constant and continously over time.

Read more about the concept of delta-timing on the net to make yourself comfortable with it

Why don't you use stream? The CPU hit is not that bad.

oh sorry,
yes-
if you can use stream.
The 'wave read' prim is the one you need,
and 'float array to mem'

all success

martinvicanek wrote:Why don't you use stream? The CPU hit is not that bad.

Nice approch! The problem is that I would to "show" the shape how it will be, than "play" it with a progressive bar.
Mem type is "dynamic", so I think I couldn't show what the signal will be and the draw a progressive line on it.

Or is there a way? Such as this:

http://www.fastswf.com/CumhxmY

P.s. how do you generate that "consecutive" random array? I see no heavy jump between points...

Dammit, Tronic beat me on that one!

Nowhk wrote:P.s. how do you generate that "consecutive" random array? I see no heavy jump between points...

Oh, I chose some random partial amplitudes and iFFTed them, so the result is smooth and periodic. However, if the period is long enough (>10s) then the ear won't recognize the repeating pattern.