The DLL Component – Getting Started, part 3: The Flowstone Schematic
In this part you will learn about the DLL component in Flowstone with some basic examples.
Here is a schematic that demonstrates all the functions from part 2 in action DLLExamplesV1.fsm . Inside you will find some comments that explain somethings that may be unclear.
I think examples speak larger volumes than words so I have restrained from doing a step by step guide to setting things up because the DLL component is pretty self explanatory, the examples are also simple enough to understand. Instead I will offer a few hints and best practices when working with this component.
Creating and labelling inputs
We create inputs by click and dragging the little rectangle with 6 dots down until we have enough inputs set. Each input will take the type of the input before it. Right click an input to change it’s type.
Naming inputs is slightly more awkward. Click on the DLL component to highlight it. The inputs names and short description will show for each input. Now you have to click one of them as though you was going to edit it and then you can press TAB to tab down to the inputs you just created and then name each one. You can do a short name (which shows on the front of the component) and a longer description which shows when highlighted. Do this by adding a \n (newline) , for example (without quotes) “Gain\n Apply gain to the input signal. Range 1 -4 ” .
The DLL component needs to be triggered via one of the “exec” inputs before it can do anything. There is two, one for “Green” events and one for Ruby events. Both can be used at the same time. It is important to know that these inputs are processed in different threads(processes) so triggering the Ruby input will not send triggers through green outputs (but values are updated) and vice a versa.
In the over drive example in the schematic you can see the Ruby exec input being triggered by the output of a mono to frame, this gets triggered in perfect sync with the audio stream.
Top level DLL locator
In the example schematic there is a top level module used to locate your dll and send it’s file location to all other DLL components. This is a best practice I recommend to follow.It also includes a button for resetting and unloading, this is essential if you have many components using the same DLL. Whilst debugging and making improvements to the DLL it is likely that you will have Flowstone open to test any changes straight away; the DLL will not build unless it has been unloaded from Flowstone first. With the top level reset button you can unload from all DLL components at once and then complete your build. The DLL will reload automatically when triggering “exec”.
Avoid embedding until necessary
The DLL component comes with a boolean input to embed the DLL into the component. My advice is to not manually embed until you absolutely need too. For instance when sharing a schematic or exporting to VST or EXE. In the case of exporting we can choose the option to embed any DLLs in the final product, so there is no need to do this during development. If you are sharing a schematic but don’t want share the actual DLL then embed the DLL just before sharing. In the example schematic there is a button to embed the DLL. It is handy to have a “embed” button in one place so you can embed all DLLs at once before saving and sharing the schematic.
It may be desirable to not embed the DLL in some cases, for instance you may want to update the DLL separately from your application or you may want to share the same DLL among instances of your app, saving memory usage. If neither of the scenarios applies to you then do your end users a favour and embed the DLL.
Create the DLL first then the schematic
To some people it may seem to make more sense to create the schematic first and set the DLL component up with the inputs you think you will need. I did this at first but found it was always better to create the DLL first without even opening Flowstone. The reason being that algorithms and design can change, you may think you will need this or that input/output but until you actually write the algorithm you cannot be 100 percent sure. It is better to finish the function first so you know exactly what inputs you need from Flowstone. Otherwise you may find yourself going backwards and forwards adding or removing inputs you thought you need but actually don’t. But I digress this is only really a problem if you are expecting lots of inputs, very simple stuff would be OK doing the schematic first.
That is it for now!
Hopefully this brief series has help you to get started with creating and using your own DLLs with Flowstone. Studying the code examples as well as the schematic should teach you all the basics you need to know about working with this component.