Timer Bug

[User]

The timer is not counting in milliseconds. It should count to 1000 in 1 second but it's not doing that. Any ideas ?

[Spogg]

We need to see the schematic please!

[User]

Here is the example file for FS306 but i think it's doing the same thing in all other versions. I will have to try it later. It takes 10 seconds or more to count to 1000 when in fact it should take only one second.

[Spogg]

This is down to something that catches people out when they start with FS! It happened to me.

The green system relies on Windows timers which are notoriously inaccurate. For example the Tick 100 prim outputs triggers at about 60Hz, not 100. Also when a schematic gets big, and there’s a lot of green triggering going on, the timing can be variable and thus unstable.
It’s also worth knowing that the green system seems to run faster in an exported VST than in the schematic editor. I think that’s down to the graphical overheads in the editor environment.

If you need super-accurate timing you can use DSP which is locked to sample rate.

Ruby can be accurate to 10mS intervals since its input/output timing is independent of Windows. The calculations "inside" a RubyEdit run much faster.

[User]

Thank you for your help. I guess I will have to try DSP. Is there a manual for DSP ? Or examples ? This page here is talking about some high precision timers but I guess FlowStone doesn't know about those.

https://docs.microsoft.com/en-us/window ... uqx2kb2c00

[Spogg]

The article looks interesting, thanks.
I'm not a code-head but it seems to be talking about measuring intervals accurately and time stamping events, and I’m not sure if or how that relates to the “Windows timers” that FS uses. My knowledge about green timing is very much second-hand from others here in the past, so I merely repeat it when it crops up. Maybe it could be done better, but we have what we have! Possibly someone else could add to the story…

The first step to DSP learning is to read the User Guide chapter 9 carefully. In my case I then looked at DSP code made by others and experimented until I got the result I wanted. Start simple and build experience. Others here may take a different view and approach so maybe they could help.

[tulamide]

Thank you for your help. I guess I will have to try DSP. Is there a manual for DSP ? Or examples ? This page here is talking about some high precision timers but I guess FlowStone doesn't know about those.

You're confusing terms here. The high resolution timestamps are not timers. They are a way of measuring computing time.
Flowstone implements them in the easiest way possible, with the prim Time. Whenever you trigger it, you get the current time (aka timestamp) precisely down to 1 ms.

-----------------------------------------------------

Also, you won't find a PC, that's able to trigger once per ms. That's why all developers use interpolation. They measure, how much time has passed since the last call and then interpolate from then to now. Flowstone's one sample point at a time approach also isn't running at 44100 Hz, but uses buffers behind the scene. So you're actually working on (for example) 1000 sample points, until they are computed, then the buffer is sent out. You just don't get to see it, thanks to clever programming of Flowstone.

In short, if you need to produce a value per ms, you have to come up with similar ideas.

[User]

Do we have any modules for that interpolation part ? Or how do we do the interpolation ? Let's say I want to cross-fade between some samples to create a synth similar to Korg Wavestate. Like... Cross-fading between samples to create wave sequences. Any ideas ? Or code examples ? Do I have to use Ruby ? Or DSP ? Or ASM ?

[Spogg]

For the actual cross-fading you’d need to use DSP because each sample point has to be evaluated.

When you write DSP code and click outside of the DSP editor box, the code is compiled into assembler before it’s run. The compiler is fast but, like any assembler, it doesn’t always make the optimum choices. The assembly code is available at the S output pin as text on the editor. People skilled in ASM can often take that code and optimise it to use less CPU, so it can run faster than the original DSP code (the calculations, not the sample rate). Then after optimisation the assembler text can be pasted into an ASM editor box.

Some are so skilled they can write directly in ASM language without going through the DSP step. So, stream-rate processing in FS is actually all happening in ASM, whether optimised or not.

Ruby is capable of processing audio using “Frames” but the CPU overhead is many times higher than DSP. What Ruby can do well is create green control signals however. But with the 10mS input/output update limitation it’s often better to use stream-based signals from LFOs and envelopes etc.

[User]

When you write DSP code and click outside of the DSP editor box, the code is compiled into assembler before it’s run. The compiler is fast but, like any assembler, it doesn’t always make the optimum choices. The assembly code is available at the S output pin as text on the editor.

That's very nice. I wish somebody would Include a more complete DSP and ASM manual. This is what it printed out from this DSP code.

streamin levelIn; <------ DSP code
streamin threshold;
streamout levelOut;
levelOut = 0 + (levelIn > threshold & 1);


streamin levelIn, threshold; <------ ASM converted
streamout levelOut;
float _F_1=1, _F_0=0;
movaps xmm0,levelIn;
cmpps xmm0,threshold,6;
andps xmm0,_F_1;
addps xmm0,_F_0;
movaps levelOut,xmm0;


I don't think this can be optimized more than what it is. Can it be optimized more than that ? Probably not.