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 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