DSP Robotics Support

No way dudes? Is it clear what I'm looking for? Maybe PPQ and manage index/array? (so sync with daw and not DSP code clock).

The green timing system is best effort only. Tick100 doesn't mean precisely 100 triggers per second, depending on the CPU load it may be much less than that. You can't sync green with stream.

Nowhk,

martinvicanek wrote:The green timing system is best effort only. Tick100 doesn't mean precisely 100 triggers per second, depending on the CPU load it may be much less than that. You can't sync green with stream.

This leads you back to my post (the 4th in this thread). If you want a bar to follow the current position, don't forget that each monitor basically outputs at 60 Hz (even if they say something like "400 Hz system"). That means 60 frames per second, or 60 images. So there's no need to and no use in trying to be any faster when displaying something.

martinvicanek wrote:The green timing system is best effort only. Tick100 doesn't mean precisely 100 triggers per second, depending on the CPU load it may be much less than that. You can't sync green with stream.

So I can't do this application? Can't output (in sync) those 1024 samples?
Or what do you mean with "the green timing"?

tulamide wrote:Nowhk,

martinvicanek wrote:The green timing system is best effort only. Tick100 doesn't mean precisely 100 triggers per second, depending on the CPU load it may be much less than that. You can't sync green with stream.

This leads you back to my post (the 4th in this thread). If you want a bar to follow the current position, don't forget that each monitor basically outputs at 60 Hz (even if they say something like "400 Hz system"). That means 60 frames per second, or 60 images. So there's no need to and no use in trying to be any faster when displaying something.

I don't mind so much for the progression bar and LFO Graph. This can be "unsync", is just for visualization.

What should be in sync are the 1024 samples that I'll send to the output to automate knobs/sliders in my DAW. Those must be strong sync!!!

This is the idea I have:
PPQ run at Tempo project (so I guess it is sync enough).

1024 is the max range, than I restart the index (I could set it dynamically if I need less/more samples).
"Playing" will start/reset the index of the array when the DAW start.

I could place a math function to slow down/up the speed of PPQ (so it is not sync with project, but I can choose different ranges) and than (at every OUTPUT INDEX) read the value from the array of samples I've build thanks to the OSC modules (even if I've not idea how to do this in this moment without ruby).

Can't work in this way? Will suffers asynch?

You cannot rely on green calculations for doing anything else than visualisation and slow user inputs. FS allows itself to block green processing whenever it needs a lot of the CPU (so eg. whenever audio chunks are processed). When the CPU is quite busy because of other programs/plugins and FS only has small time slots to do its audio processing, then green calculations can in the worst case get delayed for seconds.
That's like always, if your CPU is busy then the user interface graphics and user inputs get wonky Although this doesn't happen that often on modern processors...

MyCo wrote:You cannot rely on green calculations for doing anything else than visualisation and slow user inputs. FS allows itself to block green processing whenever it needs a lot of the CPU (so eg. whenever audio chunks are processed). When the CPU is quite busy because of other programs/plugins and FS only has small time slots to do its audio processing, then green calculations can in the worst case get delayed for seconds.
That's like always, if your CPU is busy then the user interface graphics and user inputs get wonky Although this doesn't happen that often on modern processors...

Oh... wow! Nice to know this! So the only way is deal with stream. But at this point seems I cannot output stream to FL Studio? i.e. my whole project will fail? Damn no... I hope to be wrong!

Using PPQ as reader clocker seems not so inaccurate anyway. Maybe it could works...

At which clock/speed a DSP code module process iterations? Its a fixed one or it depends due to the CPU I'm using?

That could be a problem if differs between machines... because can output values at different time.

You configure the sample rate for audio processing in the audio adapter settings. Common values are 44100 Hz, 48000 Hz, and multiples thereof. It is unrelated to the CPU speed.

martinvicanek wrote:You configure the sample rate for audio processing in the audio adapter settings. Common values are 44100 Hz, 48000 Hz, and multiples thereof. It is unrelated to the CPU speed.

So the DSP code works at that speed? Really? 44100 iteratition every sec?