Utilize pure CPU- not eat DSP power-- Ruby thought

[nix]

Alright,
so Ruby is about 1000hz max tick speed.
We have here a 1000hz audio stream,
that does not touch the DSP power of the ASIO driver, soundcard and main CPU combined-
it is completely main CPU.
What if we could get 44100 hz out of Ruby?
This would bypass Audio DSP caps within hosts.
I may try some quick ticker tests.
As it stands- it's very nice.
My MIDI sequencer uses no DSP

[Tronic]

Please can explain more, your test?
44100hz from ruby?

[nix]

I have only tested the examples generally available,
sorry to get your hopes up and the occlusion.

So currently I only have 1000hz,
like everyone else.
Just wondering if there is any way to ramp this up 40x faster.
If so we could utilize all the processing power of a modern computer.

Will test soon, and see if I can eke out a little more speed.
1000hz is very low-fi, but it would work,
maybe I can post an audio example of what we have atm.

The devs are thinking about audio surely, they have given us frames.

With mentioning the seq, it's just nice that it uses no DSP,
it is only running note on/off, much slower than samplerate.

[chackl]

Remember:

For exporting subs and other non realtime things it is a must to hold on the samplerate otherwise there will be quick timing issues when exporting
So just think about you export a track and your midi is just calculated 3-4 times during the export - do you make songs that may be complete with 3-4 midi changes?

But you could put up de input time to get down the rate of ruby.

Regards

[chackl]

Next:

The ruby therad and DSP thread are 2 different thinks - well they are bound together with timing but they are different

Just do not know if you have noticed that if you calculate something in green AND in Ruby my old dualcore get up to 75% in taskmanager - so on thread is able to use an extra core like i tested here.

If you convert DSP to ruby - Flowstone creates a Bridge between those therads with the mono to frame (ruby) and Frame to mono - This is timed and triggered and hase also a little latency (lateny until the other tread replies)

Those are just my thought - the problem ist, that it is not documentated how flowstone is solving this in Background - those are only my test results

Next - CPU is CPU
if you clock DSP to 44100 or any other part - the CPU-usage is the SAME - you only get a lot timing issues if you split to different threads (And ruby is Thread-prepared there are dokus around the internet)

Please correct me if i'm wrong

Regards