DSP Robotics Support

.

Moderator Note: Apologies if I've confused anyone by splitting this discussion off into a new thread to keep the original thread on topic for its OP.

MichaelBenjamin wrote:is FS a good way to learn ruby, trog?
it seems like it has some synthmaker specifics built in.

Tricky question - I'd already learned Ruby beforehand, so I didn't do it that way, and just had to adapt to the specifics.

Learning the language itself within FS might be a bit awkward, as there aren't any native tutorials, and ones that you find on-line often won't drop in, because they assume that Ruby is running in a console - you won't see their outputs, because there isn't a console to send them to in FS. Tutorials about methods and classes might be a bit weird too, because you use RubyEdits a bit like they're little stand-alone classes (i.e. you give them methods), but they're not really classes at all. I always did think that the way the manual just presents the custom method calls and then expects you to just go and learn Ruby for yourself was a bit of a cop-out, to be honest - it's really not clear about what differences you might have to watch out for.

My hunch is that learning Ruby the "traditional" way, as I did, and then adapt the learning to FS is probably the easier way really - you can get your head around the concepts of the language without having to keep modifying every example to fit the FS way of working. Once you know the language, doing that bit is quite easy - if you do it the other way around, you're trying to adapt code to FS using concepts that you haven't even learned yet.

Hmm. I'll sleep on that one a bit - and I'd be interested to hear what tulamide thinks; there aren't many other regulars here who do a lot of "big" Ruby code.

trogluddite wrote:Learning the language itself within FS might be a bit awkward, as there aren't any native tutorials, and ones that you find on-line often won't drop in, because they assume that Ruby is running in a console - you won't see their outputs, because there isn't a console to send them to in FS.

Not to mention that the "FS Ruby" is several versions (generations?) behind the current state of the art.

MichaelBenjamin wrote:is FS a good way to learn ruby, trog?
it seems like it has some synthmaker specifics built in.

About 2 years ago, and with a lot of help and encouragement from tulamide, I got into the basics of Ruby.

But my approach was needs-based, in that I only wanted to see what I could make it do in FlowStone, rather than learning all of its remarkable capabilities for other tasks. In fact when I looked at online tutorials I did find it tricky to relate to the FlowStone environment, and much of what was available didn’t seem relevant to my needs, such as just using it when green would be too cumbersome and not easily reconfigured and, of course, MIDI processing.
I guess that using Ruby for FS is like using Photoshop just to crop pictures. But it’s what I needed.

I’ve forgotten most of it now, due to lack of practice, but I made plenty notes for when I do need it.

So, for me at least, I found that learning some Ruby in FS worked quite well.

Cheers

Spogg

trogluddite wrote:My hunch is that learning Ruby the "traditional" way, as I did, and then adapt the learning to FS is probably the easier way really - you can get your head around the concepts of the language without having to keep modifying every example to fit the FS way of working. Once you know the language, doing that bit is quite easy - if you do it the other way around, you're trying to adapt code to FS using concepts that you haven't even learned yet.

Hmm. I'll sleep on that one a bit - and I'd be interested to hear what tulamide thinks; there aren't many other regulars here who do a lot of "big" Ruby code.

The problem with answering the question is that we both have a rather long history of programming. I started with BASIC on a Commodore PET 2001 in the 80s, and I guess you can also point to something similar. That makes it difficult to decide wether someone with no programming background can adapt to it just as quick.

What I can say is that I learned (and still am learning, for example the whole regex and pack/unpack topic is my weak spot) Ruby through Flowstone. I had no prior Ruby knowledge, but started with the few (extremely bad as I now know) existing code examples, by analysing them through Ruby-Doc, the only source I ever needed, besides The Ruby Style Guide.

But if you don't know about the OOP concepts and start programming for the first time, it can be tough. I would think, that a well-known surrounding gives you more comfort and trust, compared to literally nothing but a text editor and a console output. I count that as a plus for Flowstone. But the general concept are surely easier to comprehend, when following a tutorial whose results match the ones you have. But then again, instead of puts, you can just use the info pane or the watch method.

Yes, it's difficult to decide.

p.s. In the very early 90s I stumbled upon some strange script language in my preferred newsgroup. It was called Python v0.9.(something), and it had an interesting concept, but was tedious and complex to learn (no documentation). Much later I jumped on the Python train again, because many of my preferred tools used Python for scripting, but I never had the same easy learning progress as I had with Ruby - so that might also count for the Flowstone/Ruby combo.
Ruby's big plus regarding learning is its strictness - there are no exceptions from the rule (contrary to C/C++). Everything is an object, even numbers or operators. What you once learn in a particular application, stays true for everything else as well. That has a certain beauty. I think, for me it clicked, when I understood that "1 + 2" in Ruby is actually "1.+(2)" This "class-dot-method-parentheses-argument" structure (to put is in simple words) is the core of Ruby and together with code blocks makes it so extremely versatile.

Spogg wrote:I guess that using Ruby for FS is like using Photoshop just to crop pictures. But it’s what I needed.

Hey,
same here… And I thought it's what it would have been when Ruby was announced to be added to the old SM.
Sure, it pushes a way further the FS capabilities, but , IMO it drifted from it's original essence… A graphic programming software.
Since you guys are in the ruby game, sure I saw many good uses of Ruby, especially what comes to parsing and strings manipulations, but it's getting more and more complicated, and less and less… graphical…
Many times I opened an example schematic posted on the forum by one of the Ruby guru around here, looked at it, and said to myself, humm, cool looks Handy…, ha too bad, it's only code… Even more, now, that I have to wear glasses!
I already felt the same way at the end of the SM days… many new comers had some good coding and DSP bases and started to post stuffs only in ASM… Hummm… Trog…… No offense there!
It's just that I came to SM because it was a graphical programming software… and with the years, I feel like I'm the ultimate one using the String array get at Prim….

tektoog wrote:Hummm… Trog…… No offense there!

None taken! In fact I agree with you more than you might think. For example, I never understood why all of the GUI controls were converted to Ruby ones for FS. They're not good Ruby tutorial examples, add no features that we didn't have before, are hard to adapt for non-Rubyists, and SM users had long ago made some much improved versions of the stock controls that would have been much nicer to have as standard toolbox parts.

I've always seen SM/FS as having two "levels". The most important one, even for me still, is the graphical programming level. DSP/ASM/Ruby, I look on as the second level - as primarily a way for advanced users to make new "primitives" for the toolbox. I always try to make those kind of modules so that they can be used as "black boxes" - useful to "graphical" users whether or not they understand how the insides work, just as we have no way to know how the insides of the stock primitives work.

This is a big advantage of SM/FS, IMHO. Compare it to SynthEdit, for example, where making new components can only be done by conventional C++ coding using all of the complex external tools that are needed for that. You can't make the slightest change to a SynthEdit "primitive" unless the C++ code is open source and you also have, and know how to use, all of those tools. And using a compiled coding language in that way is a lot more laborious than being able to do it all within your main target application (anyone who has tried using the DLL primitive will know exactly what I mean!)

There are a couple of caveats, though. If you want low CPU loads, DSP, and even more so ASM, can be much more efficient than networks of primitives - and there are things that they can do that you simply can't do at all using primitives. And to some extent that's also true of Ruby - for complex String manipulation, or when you need data structures more complex than simple arrays, for example. It's maybe arguable that there should have been far more attention paid to adding new primitives to the toolbox over the years, to make these kinds of things possible without written coding - but if you close your eyes to what's inside any module, they amount to much the same thing.

However, I am also lazy sometimes! There are just some things that I can build 100 times faster with a few lines of Ruby than anyone ever could by creating a huge "spaghetti" graphical module - and it's easy in the spur of the moment to forget that not everyone has years of hiding in their bedroom learning the skills to be able to do that!

@tulamide
I had suspected that you'd probably agree with me in broad strokes - you're quite right, I think, it's that "conceptual leap" into OOP that's the big stumbling block, maybe even more so than for the coding style of DSP/ASM. Even with my years of previous coding experience, I found OOP quite a difficult jump to make from the imperative languages that I first learned (e.g. BASIC, C, Pascal).

I agree with your comments about Ruby, too. Given that you want to add a scripting language, I do think it's a very good choice - as you say, Ruby is a very consistent language with few rule exceptions, and unlike many, the "core" language is very capable without needing external libraries for common tasks (e.g. having Hashes, complex numbers, regular expression, etc. as standard classes).

tektoog wrote:It's just that I came to SM because it was a graphical programming software… and with the years, I feel like I'm the ultimate one using the String array get at Prim….

I agree with Trog. For me the main aspect is the graphical programming. Yes, I can save me some time or make modules that would be much more difficult to realize without Ruby, but then again, I have the opportunity to use modules and prims on the DSP/ASM side, which I would never be able to adapt to. It just never clicked in regards to how do I program for a single sample to achieve a certain dynamic over all samples? And so I benefit from the graphical programming base of FS.

And there is nothing against using what FS provides! It's just that those prims, a bit like Trog said, don't cover every aspect nowadays. And I feel comfortable enough to fill the holes using Ruby. So, don't see the code in the RubyEdit and feel diaheartened. Just see the whole module it's placed in and accept it as a user made prim for your toolbox

trogluddite wrote: For example, I never understood why all of the GUI controls were converted to Ruby ones for FS

Yes, it was one of the first thing that turned me off and made me feel it started to "get over my head"

trogluddite wrote:It's maybe arguable that there should have been far more attention paid to adding new primitives to the toolbox over the years, to make these kinds of things possible without written coding

Well, that's the way I feel Like for instance, to get basic on/off switches or selectors that don't send unnecessary triggers, a universal MidiLearn PRIM etc... at least the basics to built a synth, and not that one has to build everything himself,from scratch… I posted an example of a bit of a schematic that took me ages to get to function the way I wanted to…

http://www.dsprobotics.com/support/view ... =3&t=38467

It took me nearly a decade to get used to the SM trigger behavior and caprices… Then I wanted to move on to FS, and then… Nothing works the way it should… thousands of unwanted triggers, string prim that doesn't read the float decimals… I had to rewrite basically all my modules… What is it going to be to migrate to FS4?
That's where I think the Devs should be focusing a little bit more... consistency first,and then a few new useful modules, retreived for the user forum and turned into prims like they did with the array queue at the time… plus the 64bit version, VST3...etc...

tulamide wrote:And there is nothing against using what FS provides!

hehehe, I certainly hope so… I often start a project in VB and then say to myself… it would be much more easier and faster in FS… which I end up with…

tulamide wrote:Just see the whole module it's placed in and accept it as a user made prim for your toolbox

Thanks to you all, who provide all these useful modules and examples which make every visit on this forum an exciting moment

I agree , I cannot program , which is what drew me into FS.
I would definitely say that more prims are needed , incredible green spaghetti sometimes to get things done.