Spogg is learning Ruby...

[Spogg]

Hi guys.

Over the past few weeks I’ve been spending a lot of my FlowStone time learning about Ruby. It’s been fascinating!

Once it started to somehow come together, I realised that what others have said is absolutely true. It’s an amazing and useful extension to FlowStone and I love it on so many levels now. Why didn’t I do this before? I guess fear generated by looking at code and feeling overwhelmed. But it was a good experience, and I must thank tulamide for his mini-tutorials and some personal help he gave me.

Of course it’s a never-ending expedition and I’m still in the baby-steps stage, but it’s been a fruitful journey so far.
For anyone curious about what Ruby can offer I would recommend having a go. Here is the collection of books and information I found and used:

https://www.dropbox.com/s/bd6b7g1494ihr ... y.zip?dl=0

If anyone can add to this collection, that would be great. There are many Ruby books and tutorials out there, so maybe I missed something good.

I’ve added my comments to the books’ file names, only for my own reference, but you’ll make your own judgements of course. What’s good is that all the books have their own individual approaches to the same information. I would say none are perfect, but reading the same stuff presented in different ways proved useful to me.

The first information I studied was the FS User Guide, chapter 8. It made little sense at first but gave me a feel for how FlowStone implements and integrates Ruby. Then, once I had a better understanding of Ruby, I went back to the User Guide and have found it invaluable for making stuff.

Speaking of making stuff, I exercised my developing skills by making a 16-step MIDI sequencer (attached) which contains several RubyEdit modules I made or modified. This seems to work ok and is a bit of fun to play with. For me it’s a mini-celebration of where I’ve got to so far but, if anyone feels like it, I would love to get some comments, criticism or suggestions as to how the code could be improved. For example, each step has its own method for output and I’m sure this isn’t ideal, even though it works ok.

Cheers

Spogg

[KG_is_back]

One recommendation I have is to clean the inputs and outputs. pack the inputs into arrays and enter those, instead of entering them individually. That way you can also merge the methods - instead of having methods midi0, midi1, midi2,... you can have just one method that takes index as an input (or read the @stepcnt variable for that).

Off course, that means you no longer know which input has changed from the input trigger alone. You will need indexer prim to output the index that last changed alongside with the array (it might be a good exercise to try to recreate it in ruby). In the main module ignore the trigger that updates the arrays and only do stuff once this index trigger arrives.
Try to do it yourself and then compare with the version I've attached.

You can do the same thing in reverse for the leds. Instead of having the midiN methods controlling individual output to coresponding LED, have them just output index of the LED and make the "splitter" as separate module. (note: not included in the version attached)

Code: Select all

#example of a "splitter" to light up leds
#all outputs are boleans and they are referenced by connector index (no names requred)
#thanks to that the module is expandable simply by adding outputs, with no modification to code required
#inputs are @gate and @led_index
def event(i,v,t)
if i=="led_index"
output @led_index, true, time
output @led_index, false, time + [@gate, 0.07].max

end
end
end


[Spogg]

Thank you so much KG!
I really appreciate you spending your time doing this for me.

I didn’t think of creating an array using “external” prims; I was focussed on doing it all in Ruby and that’s a good lesson for me. I did consider converting all those inputs into internal arrays in Ruby, but that seemed inelegant somehow.
My conclusion is that where timing and/or complexity and the amount of triggers aren’t critical, then it’s easier to use prims for the work.

The other very useful thing I learned was something I couldn’t figure out before. And that was how to reference an output (or input) using an index. You simply created a string with the index number appended, and job done. So easy, when you know how!

The sequencer code looks kinda “good” now, and its size seems to correlate well with the relatively simple function it provides.

Cheers

Spogg

[wlangfor@uoguelph.ca]

Of course it’s a never-ending expedition and I’m still in the baby-steps stage, but it’s been a fruitful journey so far.
For anyone curious about what Ruby can offer I would recommend having a go. Here is the collection of books and information I found and used:

https://www.dropbox.com/s/bd6b7g1494ihr ... y.zip?dl=0

If anyone can add to this collection, that would be great. There are many Ruby books and tutorials out there, so maybe I missed something good.

Thanks, I'll try and learn Ruby . I have to admit I do not think it always is a better substitute but there are instances where is far and beyond a better alternative.

[Spogg]

Looking at your programming experience I don’t think you’ll find it too tough. The big issue for me was the nature of object oriented programming, since I only had some prior experience of Basic and some old machine code.

Ruby, like any programming system or tool, is wonderful for some situations and less so for others.
I love that you can write fairly simple lines of code that could replace a whole page full of green prims. Then if you need to tweak the function afterwards it doesn’t involve dragging heaps of connections around and losing your way.
As an important side benefit you’re then much less likely to get a huge trigger avalanche that you might when using green prims.

We have Ruby experts here who always seem willing to help.

Good luck!

Spogg

[Ricciardo]

GoodJob Spogg, i never quite learned ruby, but as i know other languages its more or less easy to interprete the modules and change their settings... but i cant create stuff, only change..

Ruby its incredibly usefull, it allows you to make very complex stuff for a resonably low price (memory wise)...

per example i have optimized some old schematics i had from the old synthmaker, and ruby does the same thing using only 10/20% of the same amount of modules...

a good way to test this is, open your projects,and then in the file tab, check statistics...
you will notice that old projects will tend to use hundreeds of thousands of components, in ruby, you can drop that quantity significantly, making the plugin lighter to use, faster to load, even waste less cpu power.