So you want help with your schematic, do you?

So you want help with your schematic, do you?


Hello everyone,

I’m Trog (even to my mum!) – and Exo has very kindly allowed me to join his little ‘editorial team’.  I’m also one of the ‘old guard’ from the SM days, and apparently, I’m also a ‘Guru’ (Exo says so, so there!).  As many of you probably know my awful taste in jokes and puns by now, I’ll cut to the chase – a subject dear to every guru’s heart…

As anyone who’s joined the SM or FS forums knows already, they are simply the best place to go when your new design gets a case of the ‘gremlins’ and you need help.  I know, because I was a ‘noob’ once too, and I never would have got my first VST up and running if it weren’t for the generosity and patience of the people there.  Now that I’ve earned my ‘guru’ badge, I always try and repay that by doing what I can to help out, and like most ‘old-hands’, I learned very quickly that some people make it very easy for you to help them, and sometimes – erm – it’s a little more “challenging”.  This often has more to do with how the problem is presented than it does with the nature of the problem itself –  so I thought I’d share a few tips on how best to go about asking for help, and possibly even avoid some of those bugs in the first place…

Keep it tidy! – One of FlowStone’s best features is the way that you can wrap any group of parts into a module.  Divide your design into logical blocks that each perform only a very simple function.  As you design each one, and before plugging it into the rest of your design, connect a few Floats, Integers etc. into the inputs and outputs, and make sure that it performs its little task as you expect.  If you can’t get it to do what you want, you now only have to post that little bit for folks to take a look at.  If you post a whole schematic, it can take an age to find the problem, because any errors in one little bit will spread everywhere else.  That makes de-bugging very hard work, especially for someone isn’t familiar with the schematic – and it will put people off from helping you!

Keep it tidy! – Oh, did I say that already?  Because I really mean it!  If you do need to post a larger chunk of a schematic  because that’s the only time the bug happens, make sure everything is as clear as possible for your potential helpers.  That means:..  No ‘spaghetti’ of links crossing over the top of modules all over the place – use the link nodes to tidy them up, and consider condensing sections of the schematic into logically named modules.  Give all of your inputs, outputs and modules meaningful names – we’re not psychic!  Doing this will also help you to understand your own design better, and you will be glad you did it if you have to return to an old design months later – you may even stumble across the bug while you’re tidying.

When does the problem happen? – “It doesn’t work” doesn’t help anybody to help you – we don’t have time to test every possible combination of control settings, and if you haven’t even described what the design is supposed to do, we wouldn’t even be able to tell if we fixed it or not!  So describe as accurately as you can – What is it supposed to do?  When is it supposed to do it?  When doesn’t it do that?  What does it do when it goes wrong?  Which modules do you suspect are faulty, and how do we find them?  What version of FlowStone, Windows or VST host did you test on?

Wireless links – use these as little as possible!  They can be very useful for getting “global preferences” around a schematic.  But when it comes to de-bugging, they make life difficult.  Even when using the ‘wireless finder’ features, they make it much harder to tell where signals are going.  They also have a very unpredictable link order that can sometimes lead to timing problems – don’t use them if the order that triggers get sent matters!

Be patient! – The right person to help you may be busy with a million other things.  Besides working on their own FS projects, it is not unheard of for forum members to have jobs, families, holidays, a bad case of the grumps, terrible hangovers…  And bear in mind, that if you ignore the advice here, and make de-bugging harder than it needs to be – you probably deserve to be kept waiting!

PM’s – don’t call us, we’ll call you! – Don’t use private messages to ask for help unless that user has already offered.  Firstly, while “oh, you’re such a cool Guru, I know you can fix it” is very flattering, other forum users are just regular folks like you – they’re not a full-time support service, and no-one on the forum except “admin” is an employee of DSPr.  Secondly, even the most knowledgable guru’s don’t know everything – we all have our own specialities and aren’t always the right person to ask (for example, I don’t build synths, so I’m hopeless for help with poly problems).  But, most importantly, you want as many people to see your problem as possible – you’re much more likely to get help, and get it faster, the bigger the “bug-hunting party” is!  You may say, “but I want to sell this plugin, so I need to keep it secret” – I have two answers to this.  1)  If you can’t fix it yourself, are you really ready to go “pro”?  2)  If it’s a commercial synth, anyone that helps you deserves a cut of your profits – at least make the offer, they might still help you for free anyway, but if you are running a “business”, you should consider helpers to be employees and not slaves!

FlowStone crashes! – crashes can very rarely be fixed by forum members – we may be able to find a work-around, and we’ll certainly help by checking your design on other operating systems and in other hosts so that DSPr get a more useful bug report.  But crashes should always be reported to DSP Robotics, as only they have “debug” versions of FS that can help nail the bad code, and the more reports they get, the easier it is to fix things.  The only exception to this is the Assembly module, where user’s code can indeed cause crashes that are nothing to do with FlowStone bugs – for these, just follow the same advice as any other schematic problem.

Did we fix it? – If you do get a fix for the problem, either from the forum, from DSPr, or because you just worked it out yourself, please let everyone know.  This saves people from wasting time on further de-bugging, and it let’s other members who might have the same problem get to the answer.

DON’T SHOUT! – Your bug will not get fixed quicker if you pester – and ALL CAPS just makes it look like you are not worth helping because you’re too dumb to even work out how the caps-lock key works!  It also makes my head hurt when I had too many beers the night before!

Do you want help fixing that, or do you just want someone to build it for you? – That’s not, as it might seem, a rhetorical question.  Some forum members are happy to build modules for others – they just enjoy the challenge sometimes – so be honest if this is what you are asking for., it’s not a mortal sin!  Otherwise, don’t be surprised if you get a longer answer to your question than you expected, and sometimes one that may be hard to understand.  It is very difficult sometimes to know how experienced other forum members are – they may have programmed in other languages, or have amazing DSP maths knowledge, or be completely new to the whole thing – so it’s tough to know how to pitch the answers sometimes.  Most helpers will try to help you understand why you got a bug, so that you learn how to avoid the problem next time.  If their answer flies over your head, don’t be afraid to ask a few questions – we all did it, and the FS forums are not the kind of place where new guys are bullied or looked down on.  OTOH, if an answer seems patronising, don’t be offended – other people besides you may be reading the post when they run into the same problem – it’s nothing personal, just trying to engage a wider audience.

OK, lecture over! – when I read those last couple back, I heard them in my mother’s voice!

Hopefully coming along soon, I’ll have some shiny new toys that I’ve been working on ready to show you all – and I’m slowly working through my old SymthMaker tutorials and Toolkits to give them a FlowStone make-over.

Happy FlowStoning,


1 1 0 0 0

About the author:

Trog's been a SynthMaker and FlowStoner since the early versions of SynthMaker, and is a FlowStone forum moderator. His speciality is VST effects that morph his six-string bass sounds so that he doesn't have to learn to play keyboard properly! When not doing that, he can often be spotted up to his knees in soggy moorland, on the quest for the ultimate pint of Yorkshire real ale!



  1. Exo
    Exo  - August 8, 2014 - 10:09 am

    Thanks for that Trog great first post.
    Regarding wireless links I agree they should be used as little as possible and only where it makes sense and there is a real benefit. Saying that I think I may use them to much sometimes I don’t like having wires looping back into an input so will some times use them for that case, it’s ‘cleaner’ but actually harder to read. Wireless link also make modules less reusable because they have a dependence on certain links so you cannot just copy a module and paste it into another schematic without taking a lot the wireless dependences which is a pain. I try and keep each module as contained as possible (check the Dev toolkit) and then any wireless links can connect to these via the inputs on the module. Leaving main functionally of the module very reusable.

  2. Exo
    Exo  - August 8, 2014 - 10:46 am

    Your point about naming all your inputs is spot on this is so important! Some people don’t always seem to bother but I obsessively name everyone even when it is not really necessary. It’s all about readability creating readable clear code is the best defence against bugs and when bugs do creep in the code can be easily understood and fixed. I don’t always create ‘good’ readable code first time (well never actually) but that doesn’t matter as long as you clean up and name things as you go, don’t skip this because it saves time in the long run! Once you have got it working the job is not finished until you have cleaned up!

    • trogluddite
      trogluddite  - August 8, 2014 - 12:42 pm

      Too true – in the heat of the moment, it’s so easy to punch the air, “Eureka”, when you got something fixed, and then retire to bed because you’ve got to get up for work in two hours! I make a point now to begin every session with a ‘tidy up’ of the previous session’s work – before I even think about adding anything new.
      Some others that I always forget…
      – Primitives have labels too! – just because WHAT they do may be very simple, it doesn’t always follow that WHY you used one right there is obvious.
      – The ‘Tooltip Help’ primitive is not just to help toolbox searches – it can really speed up debugging when you can just hover over a module and see a description.
      – The ‘Comment’ module – really handy for putting in “developer notes” to remind yourself that something needs looking at.
      – Long connector names – On module boxes, you normally want fairly short names, to keep the module nice and compact. But connectors can also have long names that only appear when you have the module selected. This is a big help if a particular connector only works with certain values. To do this, edit the connector name as normal – put the ‘short name’ first, then ‘\n’, then the ‘long name’. For example…
      “Freq\nFrequency in Hz, range 20Hz to 20kHz”
      “Mode\nSample mode: 0=Off, 1=Play, 2=Record, 3=Error”
      (NB – the 1st example – Mixing Hz and 0-1 frequencies is a very common source of bugs, try to always make clear which one your module expects!)

      • Exo
        Exo  - August 8, 2014 - 1:00 pm

        Some good tips there Trog. I wasn’t aware of the \n in the long connector name tip! I usually add long descriptors like in the cases you describe but never knew that adding \n split them out between name and description like that, much cleaner. I usually end up with a long name that is trialling off with … so thanks for that one :)

Add Comment Register

Leave a comment

You must be logged in to post a comment.

Back to Top