wave file to frame (RUBY)

[Tronic]

Be careful because the ruby thread are not executed if at least one RubyEdit is not re-triggered continuously.
For example, in your schematic it works because you have a Mono-Readout doing this,
otherwise it will freeze and is never executed until arriving at any RubyEdit certain triggers.

[KG_is_back]

Confirmed... making the "progress" readout trigger faster makes the loading faster... How to make it run continuously?

[Tronic]

How to make it run continuously?

you can't, but i use this

Code: Select all

def event i,v,t
   if (i==0)
      @thread= Thread.new do         
         # do some process
         @thread.exit
      end               
   end
   # here retrig until the thread finish
   input 100, nil,t+0.001 if @thread.alive?
end

and sincerely this is an odd function of how the ruby is implemented in FlowStone

[KG_is_back]

I've found out, that putting the main thread to "sleep" boosts the loading speed significantly. It seems that during the sleep, the ruby interpreter stays active and has free time to process secondary threads, like the loading one.

[tulamide]

and sincerely this is an odd function of how the ruby is implemented in FlowStone

Indeed! It renders the purpose of multiple threads almost useless.

I've found out, that putting the main thread to "sleep" boosts the loading speed significantly. It seems that during the sleep, the ruby interpreter stays active and has free time to process secondary threads, like the loading one.

That's what I said in a prior post. It is slow, because it is a sub-thread. While it is certainly interesting to see, that you can boost it by setting the main thread to sleep, the question is what will be the advantage? Pretty much nothing. One could as well call a method in the main thread with a time delay. That would also give processor time for graphic updates, etc., while loading is fast.
It disappoints me that multi-threading can't be used effectively.

[Tronic]

After several tests with the class thread,
the thread actually runs in the background, but to have a return feedback from it,
of course we must now retigger the RubyEdit module,
but I believe we can transfer the return via a send function or some sort of callback to caller thread,
we investigate this.

[Tronic]

hehe, I have to contradict yet, it only works if retriggered, otherwise it stays still,
sorry I missed a readout active.
here I stop I'm tired.

[KG_is_back]

I've written an E-mail to the DSPR support. Perhaps they can give us some insight on why this is happening and possibly even solve the problem.