DSP Robotics Support

Currently, a "Ruby bus" search on this forum, only returns 18 occurrences.

Page 143 of the Flowstone User Guide (version 3.0.2) there is a short example consisting on a RubyEdit module, generating a hash as "Value" considered as local bus, along with another RubyEdit module that's inputting such hash seen as "Value", such RubyEdit module getting able to read and exploit the new "Values".

Page 95 of the Flowstone User Guide (version 3.0.2), states that "Value" data type can refer to any Ruby object. Apparently, the "black Bus" data type, is an object that the "Value" data type can refer to.

What to do for allowing a vast amount of existing "Bus Extract" Flowstone components, to read such "Value" local bus?
What to do for allowing a RubyEdit module, to read a "black Bus" that's emanating from a "Bus Create" Flowstone component?

Any suggestion or example will be highly appreciated.

I think you misunderstood the whole thing.

- A RubyValue output or input can transfer each and every Ruby object.
- A black bus output or input can only operate with the bus prims.

They are not related to each other.

Well spotted. Thanks. I remain thus under the impression that one cannot convert a Flowstone bus (a black Bus), into a Ruby "value" (actually a hash) to be exploited by a RubyEdit module. And, I remain under the impression that one cannot convert a Ruby "value" (actually a hash), into a Flowstone bus (a black Bus). Am I right now?

steph_tsf wrote:Am I right now?

Yes; as tulamide says, they're two separate concepts - the User Guide example would be better described as passing a Ruby "container"; calling it a "bus" is a rather confusing metaphor, IMHO. Also note that passing Ruby objects through a "black" bus may not work (it fails in FS 3.0.6 at least). The 'Bus Create' and 'Bus Extract' primitives will allow connectors to be of Ruby Value type (V), but the Ruby objects do not get transmitted or received by the bus. I assume this is a bug rather than by design!

Thanks for the confirmation. As you may know, the time passing, one tends to have huge expectations, and one lazily assumes that everything is compatible with everything. It takes time for understanding the contours and the comfort zones of the various software development tools that Flowstone (seen as a whole) is relying on: graphically sketching a digital signal processing flow, creating a leading class GUI, adding extremely concise procedural code whenever required (Ruby), and adding powerful SSE pseudo-assembler DSP routines whenever required.