DSP Robotics Support

I've just dropped in anything in the tool box that looked interesting and useful. Feel free to add some Ruby stuff of your own. We can create a kinda nice mini Ruby data base here

Cheers!

Fantastic, thanks

Awesome ! I would love to add to the collection but I am working on the Alpha version.

This is a great idea!

When I was learning a bit about Ruby I set myself little exercises to make some basic functional modules. So I’ve attached these as my rather sad and weak contribution.

The quality of the coding and the style varies considerably as I made progress.

It might be useful to get comments about how stuff could be done better, or issues that I didn’t spot at the time.

Cheers

Spogg

Great idea! I'll certainly have a rummage to see what generic Ruby modules I've got knocking around.

A couple of general comments...

- I think we need to be careful to distinguish between practical "drop-in" modules and code examples. For example, a Ruby 'sample and hold' will generally be far less efficient than a 'green' one. So, I wouldn't encourage people to use it as a "drop-in" toolbox module, but at the same time, it is a good example of how to handle triggers in Ruby.

- I noticed that the 'Windows Bell Sound' in Spogg's schematic uses the Win32API module. Unfortunately this doesn't work any more in plugin exports unless the customer also installs the correct Ruby library file in the right location. It's easy to get caught out by this as, when testing plugins on our own PC, our FS installation already includes the necessary file.

Nice one, spogg thanks!

Trog, waiting to see what you are hiding there

By the way, can all that Ruby stuff get merged into one FS system file? If it does, maybe we can create one collection file that can be updated from time to time.

trogluddite wrote:G- I noticed that the 'Windows Bell Sound' in Spogg's schematic uses the Win32API module. Unfortunately this doesn't work any more in plugin exports unless the customer also installs the correct Ruby library file in the right location. It's easy to get caught out by this as, when testing plugins on our own PC, our FS installation already includes the necessary file.

Are you sure?
From the manual I get two informations:
"Currently VST plugins generated by FlowStone cannot make use of Ruby extensions or Gems."
"However, if you create an exported exe that uses the extension and want to pass this to someone else then either they will need to have FlowStone installed on their system or you will have to distribute the \ruby\libraries\win32 folder (including the ruby and libraries parent folders). The ruby parent folder should then be inside the same folder and at the same level as your exported exe as shown in the picture below" [with no picture following ]

For me this means no VST at all, even with a proper folders installation. And exe works fine if provided with the folders.

trogluddite wrote:- I think we need to be careful to distinguish between practical "drop-in" modules and code examples. For example, a Ruby 'sample and hold' will generally be far less efficient than a 'green' one. So, I wouldn't encourage people to use it as a "drop-in" toolbox module, but at the same time, it is a good example of how to handle triggers in Ruby.

This is presumably because the Ruby sample & hold is interpreted whereas the green prim is hard coded in something fast…?

My understanding is that Ruby excels at doing stuff better than green where there would be a lot of complexity and triggers generated. One example is the array uniq and sort module. Try doing that with green prims!
What’s not so easy for me to determine is the break-point at which a RubyEdit will perform better than its green counterpart. If you take my monostable as an example, this kind of thing can be done in green with a counter and greater-than prims etc. But is the Ruby version guaranteed to be “better”? My view (which is fully open to being corrected) is that the Ruby one will be more accurately timed and less likely to be thrown off the scent by other simultaneous green activity in the schematic.

BTW I’m glad you mentioned possible issues with the Windows bell sound module. I maybe shouldn’t have included that one but it was just there as one of my little exercises.

Cheers

Spogg

@tulamide
Yes, you're right; my bad!
I was forgetting about the change to the Ruby interpreter linking for plugins, which does indeed disable the ability to use C++ Ruby extensions in plugins (though plain Ruby code will still "require" OK.)

Spogg wrote:This is presumably because the Ruby sample & hold is interpreted whereas the green prim is hard coded in something fast…?

In part, yes; though the Ruby interpreter does translate the code text into "byte-codes" so that the code doesn't need to be parsed every time it's used. Ruby also deals only with "objects", which is a very different way to store values than green uses. For example, a green float is just a 32/64-bit region of memory, which can simply be overwritten when a value changes. OTOH, in Ruby, a new Float object has to be created for each new value, and whenever Ruby starts to run out of space for new objects, the garbage collector has to scan the objects to see which ones can be thrown away to make space. So there can be quite a bit of overhead for all of this copying/converting between green values and Ruby objects, especially for "containers" such as long Strings or Arrays. Green and Ruby also run in different threads AFAIK, so there's likely some overhead for synchronising the threads, too.

Ruby "Value" links can help to some extent - they pass just a reference to an existing object rather than creating a copy. However, this has to be used with care, as any change to the object will be visible everywhere else that it's used, even in places "earlier" in the chain of links.

OTOH, the many, many built-in methods which Ruby objects have are all coded in C++ behind the scenes. So complex operations on "containers" of data can be very efficient if you can use the built-in methods to do what you need. And, of course, Ruby has all sorts of goodies that would be extremely difficult to emulate in green!

Hello all and thank you for providing these modules, kortezzz.
May I ask the question, whether anybody would know whether it is possible to program a ruby module that gets triggered by some input (poly for example) and the adds a probabilistic value from a normal distribution to it.
Why do I ask?
a) I wouldn't know how to do it myself. b) it would be really useful in combination with a sequencer to produce alternating sequences.

I wish you all a good week-end, thanks again, kortezzz
Best Regards

Phil