Flowstone Guru is here!

Flowstone Guru is here!


Flowstone Guru is here!

So this is my new Blog focusing on the Flowstone Graphical Programming Language, which I shall refer to simply as FS or Flowstone from here on in!

I will be adding modules as time goes on, some will be paid for but most will be free. I do plan to do free versions of the paid modules that cannot be used for commercial projects. Paid modules will of course be highly optimized in every respect, free ones are more for the FS community to learn from so will focus on readability first and foremost.


A bit about me and some thoughts on Flowstone……


I am a self proclaimed Flowstone Guru (hence the site), others may agree, you would have to ask them ;-)

I have been using Flowstone since it was called Synthmaker at version 1. I came across it just as it came out of beta. My main goals then were to learn synthesis techniques and I thought Synthmaker was great for that and it is. I have learnt stuff I would probably never have learnt without Flowstone,  I understand the voodoo that is digital filters pretty well (although don’t ask me to write one from scratch ;)  my maths isn’t that good!) . I understand lots of DSP concepts and can write lots of stuff from scratch like Oscillators, Waveshapers ,Multi stage envelopes, compressors ect , well you get the idea. All of this I learnt from experimenting in Flowstone, I don’t think I would have had the patience to learn it all any other way.

I have learnt a lot about programming too, although Flowstone is very visual it is really no different to programming in a text based language. The difference is semantics, the problems you solve are pretty much the same. Obviously an environment like Flowstone takes a lot of the ‘pain’ away especially when working at a higher level. But for a lot of things the visual approach is actually much harder than writing code.

Having to deal with things like link order to ensure things execute in the right order, then if you delete a link and  re-add it the link order can be messed up introducing bugs! To solve it you have to delete every link and then re-add them in the right order. The order is clear as day when writing code. This is why I am very happy about the addition of Ruby. Somethings are just so much easier in a text based language, such as when doing dynamic drawing inside a loop for example.

Saying that I have tried to do somethings in Ruby and decided that it is actually much quicker and easier to use the wires and primitives approach. I recently started work on an oscillator that has a graphic display of the waveform which can be dragged to change the start phase. I originally was going to do it in all in Ruby but it is a pain to have to route values out of Ruby to store in a preset Parameter primitive to route it back into an input. Ideally there would be a “Preset Parameter” Object in Ruby to use. I also just found it easier to grab a few primitives for the mouse handling in this case and then I just did the drawing in Ruby (Which for me is where it shines, but is currently to low level to be very productive) I feel in many ways Ruby just doesn’t gel properly with the rest of Flowstone.  Hopefully this ‘integration’ will be worked on and  the object oriented nature of Ruby will be easier to use.

Having used a couple of GUI frameworks in Java namely Swing and Codenameone, the Ruby Module could be so much better when it comes to GUI. Where is the Button class? or Label? why do we need a primitive to load a bitmap? these are basic things that you should be able to add into your Ruby code. If you want a Button you are forced to use a module and hence the wires and primitive approach. We are losing the best thing about Ruby, Object Orientation!

Of course we can create our own Button class and any other class we so desire but it will still not be as simple as other frameworks. Most GUI frameworks have a concept of a Form or View which we can easily add Components such as Buttons too with very little effort, it’s as easy as form.addComponent(button); the Layout of the Form handles the size and position of the Button (which of course can be set). Then to get the Button to do something we just add an ActionListener such as…

button.addActionListener(new ActionListener()


//Button Pressed do Something!!


Currently to get something this simple in Flowstone would be a lot of work and quite awkward anyway. Each Ruby component relies on built in methods such as “draw” and “event” ect. So if we did create a class Button this button would have to have a draw method and event method ect. and when we wanted to draw the button we would have to call it’s draw method within the Ruby draw method and to pass events we would have to call it’s event method in the Ruby event method. This would get long winded and messy and a far cry from a clean form.addComponent(button).

We could of course create our own Form class, I was thinking to create a Form object within a Ruby Component  which handles everything such as layout and passing events to the correct components within the Form ect. The Form could then be output to another Ruby component. This component could then just work directly on the form and bypass the need for the built in methods such as draw.

It would just then simply be a case of setting the Layout for the Form and adding your Button via form.addComponent(button) .

You wouldn’t need to worry about events or drawing just place the Button on the Form and let the Form take care of everything. You can then focus on what you want the Button to do!


I will wrap this up for now, but I think the main points from this Blog post are….

1. I am a Flowstone bad arse, been doing this since before you could walk kid.

2. Flowstone is great for learning about synthesis and DSP.

3. Ruby in Flowstone could be so much better!

4. I miss Java





0 0 0 0 0

About the author:

I am the founder of Flowstone Guru. I have been using Flowstone since the early days when it was Synthmaker, talking 7-8 years now! I have created lots of things in Flowstone and have a wealth of experience with the software, some of my work you will find on this site in the Downloads section. I'm passionate about programming (Flowstone, Java ,C++,Ruby) there is nothing I like to do more. I just love a challenge and enjoy pushing myself and the tools I use to there limits!



  1. kortezzzz  - July 30, 2014 - 4:53 am


    Good luck with blog. Nice to have an “address” which you may go to and find some cool articles and PRO modules. Wish it to become to a kind of “modules drugstore”, but first things first. As I understand, FS is soon going to expand it’s abilities with some new great features, and gonna be interesting to visit your blog abidingly. Moreover, I’m very surprised you mentioned JAVA at the end of the post… something we have to know? ;-)

    The best.

    • Exo
      Exo  - July 30, 2014 - 10:01 am

      Hey, yes hopefully will have a nice selection of modules on here. I have a lot of stuff hanging around on my Hard drive need to clean some of it up first though.

      No secret about Java, I just miss certain aspects of it and obviously cannot use it it Flowstone.

  2. Rene Chlada  - July 30, 2014 - 7:05 am


    first of all, thanks for putting up this blog, great to have some audio dsp focused source for FS.

    in some points you are talking out of my soul, specially the ruby stuff, i’m dreaming a long time about to have some gui classes for buttons, knobs and so on it would be enough to have them very basic to derive from and build your own more specialized ones,

    also the ruby editors would be so much better if they would have at least line numbering :)

    hope to see much interesting themes and modules here after i’m on FS/SM just for around 3 years there are still lots of things to learn and its great to have a first days Guru to learn from

    keep up good work

    Nubeat 7

    • Exo
      Exo  - July 30, 2014 - 10:07 am

      Thanks, line numbering would be a good idea, I will pester Malc about that and a few other things once he has got this release out of the way.

  3. trogluddite
    trogluddite  - July 31, 2014 - 9:18 pm

    Hi Exo,

    Agree totally about Ruby – the more I get to know the language, the more I realise how badly the FS implementation misses the mark.
    Been making suggestions to the dev’s about at least being able to embed our own Classes and Modules somehow, so let’s see. At the moment, I’ve been keeping mine all to myself, simply because I don’t want the headache of folks running into problems with the RubyEdit parsing order and connector Marshalling.

    Classes are the key to making Ruby EASY – and in so many ways, that’s what FlowStone is all about. The single most powerful method in Ruby is “require”, yet we don’t even have a standard user directory to require from – and it would break anyway as soon as a VST is exported.

    And I can’t help but mention the “examples” in the User Guides. Getting novices into a new language by ignoring every single recognised good practice is NOT the way to do it. Sure, we don’t want petty bickering over how much to indent etc. – but the majority of Rubyists put parentheses around their method arguments for a REASON – because you end up with nonsense as soon as you start chaining method calls, or nesting calls within the list of arguments. Repeatedly creating new drawing objects in the ‘draw’ methods – eh? – keeps the Garbage Collector in a job, I suppose!
    They’re the kind of bad habits that will really come around and bite people once they’ve picked up the basics and start venturing into the unknown – and make learning from 3rd party examples way harder because the code looks so different.

    Likewise about the lack of de-bugging tools. Of course, that’s something that SM/FS has always lacked, so I think we’ve kind dropped ourselves in it there by not making enough noise about it in the past. A ‘pause triggers’ button would make a nice break-point substitute, and a floating window to see the values at selected links or Ruby lines would make the job so much easier!

    Anyhow, enough whining. This blog is a great idea – somewhere to let off steam about our favourite little DSP platform (yeah, I love it really), and a repository for some of the best module collections (just like the official forums always needed!). I’ll gladly share some modules and tutorials here, if you’re looking for content – who knows, maybe even a Ruby Class or two if/when there’s an easy way to use them!


    • Exo
      Exo  - July 31, 2014 - 10:18 pm

      Thanks Trog, would appreciate the help with tutorials and content :) .
      I think this blog could be something great for the community and sorely needed I think! Still getting to grips with WordPress but was thinking about expanding into a proper module marketplace(free and paid), with some form of quality controls ect.

      But anyway yes I am disappointed with Ruby really to be honest, I was looking forwards to learning it but I haven’t really got into it as much as I would like. My first ideas where to do ALL my UI and events ect in one Ruby component, and just split functionality out into classes that can be defined in other unconnected Ruby components. This isn’t for ‘macho’ reasons it just makes sense to me to do it like that, if I am writing Ruby code I just want to write Ruby code! I don’t want to have to keep leaving it and going into the green world, which we have to do constantly anyway if we want a bitmap or save a value in a preset. It just makes things a pain.

      And yes the examples are bad, my first steps in Ruby was based on the examples. I knew that certain things where inefficient but just went with it while learning, optimizing can come later. But like you say to complete newbies they are picking up bad habits, and they might not even realize it.
      I understand the need to keep examples simple but best practices should be adhered to!
      Have you seen the example in the manual for generating a sine wave in Ruby? A new array is allocated for every buffer! And I’m not sure how Ruby works exactly with creating arrays, but the array is created with an undetermined size I’m guessing they have a default minimum? but anyway seems in that example the array will be constantly resized thrashing the GC even more!

  4. trogluddite
    trogluddite  - August 1, 2014 - 11:54 am

    Well, ‘macho’ reasons or not – going into and out of Ruby is not really a good idea, anyway. The Ruby and ‘green’ event systems are completely unsynchronised and on different threads – so you lose timing accuracy and add a whole load of extra CPU overheads that way.
    Always send data ‘Ruby to Ruby’ using the Ruby Value connectors if you can!

    I realise that when learning, short code is helpful, as it helps to ‘encapsulate’ the concepts – but when I see folks joining loads of Ruby “one-liners” with green links, it makes me cringe a bit. As I’ve said to Malc, this kind of thing is unfairly giving Ruby a bad name – quite a few folks seem convinced already that it isn’t worth bothering with because it’s “inefficient and inaccurate”.

    It’s also a hassle for code maintenance – if you decide to change how your controls work, but can’t synchronise modules for whatever reason, you’ve got to copy and paste a whole bunch of code. In contrast, I have a little system running where I define Modules for the shared methods, and just “extend” whichever RubyEdits need it.
    As Module definitions are totally mutable, and I prefer to edit in Notepad++, I even made a little module that ‘auto-updates’ the code when I switch back to FS. No copy and paste required until export time!

    That’s been my big Ruby project for a while now – a suite of ‘IDE’ type tools for code management and de-bugging. Sadly, there’s no way to temporarily suspend execution, but I have variable dumps and line-by-line code tracing just about working – once I get my inter-process DLLs finished, that should be possible for exported VSTs running in a host, too.
    That may well be my first “paid for” module collection, once I’m happy that its optimised and stable – I’ve been working on 6 months or more already!

    P.S) Ruby Array default size is zero! I got some seriously good performance improvements when I switched to a fixed-size circular buffer rather than pushing/popping in some message queue code I was writing. Heap allocation is a serious performance killer!

    • Exo
      Exo  - August 1, 2014 - 3:39 pm

      Look forward to see your work with Ruby. I think you should charge for some of your work, it’s not really about the money it’s just fair, there are plenty of people making commercial products that have always had everything for free.
      You are definitely the Ruby guru, I am always learning little things from your posts over on the forum. I appreciate the time you take to explain things as there are a lot of pitfalls when working in Ruby. I need to knuckle down and get over my annoyances with it. Think I will make a start on a proper UI library and see how it goes…..

      • trogluddite
        trogluddite  - August 2, 2014 - 12:11 am

        Thanks, you’re most welcome – it’s only fair that I repay the patience of you and the other gurus who taught me my DSP chops back when I was a SynthMaker noob!
        It’s what made my mind up between SM and SynthEdit. Just think, if you hadn’t been there to help me back then, you might not have had to put up with years of my terrible jokes on the forum!

        • Exo
          Exo  - August 2, 2014 - 9:26 am

          Ha ha I like terrible jokes :)
          But yes the community was a big pull factor for me too. I loved how helpful some guys where and I to wanted to give something back too. I think it has a knock on effect people that have been helped what to help others where they can too! Creates a strong community.

Add Comment Register

Leave a comment

You must be logged in to post a comment.

Back to Top