Can you code your own algorithms in Flowstone or you have to use ready-made blocks that come with it? I don't know anything about Flowstone really. Not to take anything away from the efforts that went into making this synth, I am sure it is a monumental task to build synth emulation in Flowstone, maybe even so if you're limited only to ready-made "blocks" that come with it.

 

Coding Your Own Algorithms

• Yes, full customization is supported. Flowstone combines graphical wiring with text-based programming for extending or replacing blocks:
  • Scripting: Use Ruby (built-in scripting language) to write custom logic inside components. For instance, you could script a unique delay algorithm with variable buffering or modulated sampling rates, as mentioned in developer discussions.
  • DSP Code: Write your own signal processing routines in C++ or even assembly (ASM) for low-level optimization. This lets you implement bespoke algorithms, like advanced physical modeling (e.g., simulating organ pipes or string resonances) or hyper-efficient multi-channel audio processing using SSE instructions.
  • User-Defined Components: Once coded, you can package your custom scripts or modules as reusable blocks in the library, wiring them into larger schematics just like stock ones.
• This hybrid setup means you're not "limited only to ready-made blocks." It's powerful for synth emulation—users have built FM synths with user-wired algorithms (e.g., stacking operators like in a DX7), additive synths with per-partial panning, or even full virtual instruments that export as VST plugins.

 

Flowstone/Ruby, C++, BrainFuck... if the tool gets you there then it was the 'right' tool for that person. Airwave isn't a 1:1, Unison demonstrates the sonic falloff and problems most apparently I think. But, TUS aside as that's a whole different animal, this is still the closest approximation that's been released when factoring the total palette. Arturia just rebadged their white label assembly line. That Reaktor one is.. there's just no point in comparison. His at least matches the writing on the tin, even if it is a little dented.

 

A ROM can run perfectly and it’s still not the entire enchilada. Take a Kontakt library as an example. A developer painstakingly samples some synth with great converters and all that. The library loads into Kontakt, and from that point on it’s just a wrapper around Kontakt’s engine. Does that mean I can go into Kontakt, swap its filters or modulation blocks, and it will still remain a 1:1 copy of the original synth? Obviously not.

Loading a binary ROM isn’t some magic shortcut to authenticity. There’s a lot more to a perfect emulation than that. Without proper measurements of the hardware itself, all you’ve got is the usual “trust me bro, it sounds the same” coming from people who don’t even have the real device sitting in front of them.

Running the ROM doesn’t magically make the synth identical; it only guarantees the control flow is authentic. The sound still depends entirely on the accuracy of the DSP model underneath, and that’s where most emulators fall down. The ROM can issue the same oscillator and filter instructions it did in 1995, but if the host-side math, timing, interpolation, coefficient quantization, accumulator width, saturation behavior, and internal overshoot aren’t modeled to the original chip’s quirks, the output won’t match.

Saying it’s “just interpretation for another processor” is underselling it; the original chips often had undocumented hardware behavior that simply can’t be guessed. Workarounds don’t solve that — measurements do. And very few people actually measure the real unit’s output at the algorithm level.

So yeah, ROM-running emulation can functionally work, but it’s nowhere near proof of sonic accuracy.

 

You are maybe thinking about this more in the terms of Synthedit. Have you ever used Maya? An individual component carries its own code inside the object. For Flowstone, the blocks contain code written in Ruby. People forget that Maya is not only a 3D program used by graphic designers; the dependency graph is basically a programmable environment. If you know how to abuse it, you can prototype almost anything: control systems, UI logic, mechanical linkages, even synth routing.

each object carries its own internal logic. Flowstone is more that direction than SynthEdit was or is. But the important part is within your question. Flowstone’s “code inside the object” is Ruby, and Ruby in Flowstone is not running in the audio thread. It’s not DSP code. It’s GUI, logic, parameter handling, event stuff. Anything time-critical in the signal path still has to be built from the pre-made DSP primitives Flowstone provides.

Blocks contain Ruby, but the Ruby isn’t how you write an oscillator core, or filters, or nonlinear stages. It’s not replacing C++ DSP. It’s not giving you low-level control of coefficients or oversampling or accumulator width. It’s just metadata and control behaviors attached to the object.

Maya nodes are internal logic that actually executes the thing.
Flowstone blocks means Ruby logic that manages the thing, while the DSP itself is still prefab. The audio engine underneath is still whatever Flowstone ships with. It is not what you might call traditional OOP (object oriented programming). It is a RAD environment.

I'm not sure why people are so obsessive over emulation comparisons to begin with. It sounds good and you like the workflow or you do not. For the hardware users amongst us do know that you cannot stick a computer file on Reverb.com and get $1000 for it like you can a real Roland JP-8080.

 

Sounds great. I want that. I don't care what it is made of. For all I care it can be written in hieroglyphs. I use REAPER, and REAPER eats them all. )

 

That’s all true there are much more subtleties, of course. Just simplified for clarity a ROM appearing to run doesn’t guarantee 100% authenticity in the end result. As I said, it all depends on the developer actually understanding the quirks and measurements, which can take years like it does for Plogue when they emulate much simpler chips

Workarounds are often necessary sometimes to give the emulator more capabilities than the original chip, some emulators even cheat to get the result They can be the only practical way to get results close to the the original measurements

 

Last edited: Nov 21, 2025 at 8:12 PM

Ootb blocks/environment can't, but you can reference your own compiled dlls. Though I don't know the full scope of integration beyond you can add your own c++ to at least some degree.

Last point is the most salient, I think. There is a lot of good software. There is some excellent unique software. There are not a lot of good (accurate)..erm.. 'tributes.' In a just and righteous world marketing firms would be put to the torch. But alas, we do not live in that paradise. So forever on goes the chase and forever goes the meticulous hand crafted accuracy of being meticulated by the meticulation of just how gosh darn meticuli all these devs are.

 

Airwave Synthesizer by Adam Szabo (No Talking)

Adam Szabo Airwave | Demo Test | Super Saw Trance Lead Hard Dance

Adam Szabo Airwave | Demo Test | Super Saw Trance Lead

 

Sounds a little different and better...

Roland JP8000/8080 Emulator (The Usual Suspects)
https://audiosex.pro/threads/roland-jp8000-8080-emulator-the-usual-suspects.82027/

Coming soon...