Basic questions about Ruby and Flowstone (need answers)

[guyman]

I'd like to start a discussion clarifying some basic things. If anyone would like to converse I'd appreciate it. Check any part with a quote if you care to.

Be warned some of this may read like declarations of the truth, but these are my assumptions based on my current understanding. There is some info here for the uninitiated, some good questions raised and asked, and some guesses that need corrected...

I am under the current assumption that :

-Ruby in Flowstone is processing any input data (frame,gui,midi,ANY GREEN) at the same speed (sample rate), as streams, in sync with streams. This has to do with the buffers running in the background (as recently described to me by tulamide)..

111.JPG (42.34 KiB) Viewed 8396 times

-Though it analyzes all inputs instantaneously, it takes time to generate midi events. That time has to fall under the length of one buffer, with the buffer length set by the soundcard/asio. So with an ample buffer length ruby can be treated as "real time" like a stream. I believe this is the same case with turning signals into ruby frames (that can come later)...
(personally my computer/soundcard is set to 3ms currently(I record), but I guess I'll have to extend that for some functions I may want in the future.)

111 2.JPG (26.81 KiB) Viewed 8396 times

-When turning streams into green with mono2float, or poly to float array, or graph prims... it is real time, BUT the float is generated by samples taken at an instant == tick (tick25,tick100,custom), thus is open to inaccurate timing, and missing signal parts... as stream is running at sample rate (it is basically assembly language in clothing), and tick is (insert cpu clock jargon???)...

-you can reliably run green into streams, and the stream will = green, but not vice verse, and anything in green tangles will be open to these timing/accuracy issues...

111 3.JPG (32.27 KiB) Viewed 8395 times

BUT is this the case with the ruby input/output? If ruby is processing at sample rate like a stream is, at the same level(buffer) as a stream, is the output to be trusted? Like if I process an INT array in ruby at sample rate, and output an INT... is that INT accurate, or is even that in/output hole subject to green inaccuracy? Can I run out of that ruby INT output directly into a stream?
(picture below)
If I do, is it at sample rate speed accuracy? essentially creating an uninterrupted stream from inside the ruby module processes, out of the INT out, directly into a STREAM in on a DSPCODE box, and out the other side? Is that whole chain sample accurate? or is that one step of green ruining it?

If it is unreliable,

-is that problem avoided by using a frame out?
-then frame > mono?
-is that sample accurate?
-is it instantaneous?
-it takes time (I think a buffer) to go from mono to frame (UNUSABLE AS IT SEND CPU INTO SATANIC FURY)..
-Does it take time for a frame to go mono??
-Does it take hella CPU?

what if I want to output an array? can an array go out in a frame? frame to poly? mem? huh?
(let's get out of the deep end)...


-Are my assumptions about ruby's internal processing and accuracy correct?
-Are the outputs to be treated with that same level of accuracy?
-Is a green input/output inaccurate at the point of ruby out, or upon connection to green mechanisms?
-If I send a midi event into Ruby, use ruby to dissect it into it's constituent parts, and output them as INT/string, are
-those INTs/strings as instantaneous as midi>voices>poly? is it faster? is it as accurate?
-Is midi > ruby >green out realtime/sample rate?

If you can't tell, I am trying to ditch green as much as possible. Ruby can do what green can, at sample rate/accuracy (I believe )... with significant CPU savings.. && stream is the only way to process realtime/living data as it is running at sample rate..

I'm trying to use the above questions/thoughts to clarify ruby's mechanisms, and understand the best ways to translate between streams/ruby/midi, the timing issue, and limitations...


~~~~

If only there was one fluid ether, layed out all flowstone point and clicky (for my liwwle brain) that could accomplish everything I could ever dream of, without considering buffers, with complete accuracy, at sample rate, in realtime, capable of processing streams, conditional and statements, expressions, midi, and guis.. and tuck me in at night, and give me hot cocoa when im cold and and and

[guyman]

EDIT: Adding pictures

ruby directly to stream>>

111 4.JPG (24.17 KiB) Viewed 8394 times

eee.JPG (15.09 KiB) Viewed 8392 times

[guyman]

All pictures above are generalizations, not specific examples.

[tulamide]

A lot of questions, but I can't answer them all.

First of all, to avoid misconceptions, there is a difference between "sync'd to sample rate" and "running at sample rate". Ruby is sync'd to sample rate, as soon as ASIO is present, or it is used as a plugin in a DAW. It is NOT running at sample rate. It keeps running at 100 Hz.

Since a buffer can be quite large, you can get Ruby to perform something while this buffer is treated by the DAW or Soundchip, but that needs time. I doubt you can do anything meaningful with Ruby, while running a 3ms buffer.

So, where does sync'd to sample rate make sense then. When it comes to preciseness. When it doesn't matter, if something is calculated through one or more buffers, but that an event happens exactly on time with a specific sample. Method scheduling and timed events are two examples. You could basically prepare a whole pattern of notes to be scheduled, when the user hits the "arp on" switch, for example.

Anything that leaves Ruby via an output type other than RubyValue or Frame, is subject to that type's timing. Green is event-driven, so basically it would react instantanously, but only, if it isn't busy with other things. Those other things are defined by their appearance in the schematic, the order of links, the placing of multiple links from one output to several inputs, etc.

Ruby reacts to input changes immediately. The maximum delay would theoretically be 9.x ms, but in practise this will rarely be the case. However, it is for a reason, that DSPR always said, that Ruby's internal clock is reliable down to 10 ms. If you go lower, it will of course be unreliable, it is running at 100 Hz.

CPU load is dependend on the processor used, so there is no definitive answer. It is a lot higher than DSP/ASM. I made an example schematic using frames to work on audio samples in Ruby, you can find it in the user examples section.

.

[guyman]

Thank you tulamide !

This actually answers most of my key questions, clarifies my misconceptions, and makes a lot of the other questions irrelevant !

I appreciate you.