Which is better for realtime performance?

[tulamide]

Is eveything the same as within the 'interpreter', or is the export compiled into code ?

There's no compilation going on. The export is a minimal Flowstone runtime plus the schematic's code. So, you basically get what you see. If it's slow in edittime, it won't speed up in runtime.

[RJHollins]

Ah ...ok,

Thanks for the info tulamide.

[kortezzzz]

From what I've noticed, avoid green loops

KG, can you please show in a very simple schematic how it can be done? If we take a look at the stock multisample
module, we can see it's sample loading system is built around the green loop. Maybe it can be optimized then? (by the way, the stock multisample module really need a optimizing as it never optimized from the old days of synthmaker!
What the community needs, especially the amateurs, is an optimized stock multisamle alike module with good performance and less extra features that would be a good starting point for and expanding. Would someone meet that challenge please?)

Also avoid text prim connected to/inbetween array links.

The more connectors a prim has, the more likely it will be slower

Ok, now I really have to take another look at my older projects. Used to use this methods a lot. Any ideas how can we avoid of feeding the wavtable prim' with a bunch of wavetable text files and a huge selector?

[KG_is_back]

KG, can you please show in a very simple schematic how it can be done?

I'm having trouble creating a visible and still simple example. This schematic contains two modules that do exactly the same - fill an array with 10000 elements. each element is value of previous + 2 ^ its index. That is quite massive operation. the buttons in the schematic are modded to send out 10 triggers at the same time.

The green version takes about 8 seconds to finish on my machine and even causes the hour-watch cursor to show up and completely freezes flowstone while doing so.
The analyser version takes only about 5 seconds.

green VS analyser.fsm

(7.54 KiB) Downloaded 751 times

If we take a look at the stock multisample module, we can see it's sample loading system is built around the green loop. Maybe it can be optimized then?

Unfortunately not. The schematic still needs to fire triggers to load the samples and that seems to be the bottleneck. Rewriting the loop that fires the triggers to single ruby module may save a little time, but I doubt it will be a significant improvement.

Ok, now I really have to take another look at my older projects. Used to use this methods a lot. Any ideas how can we avoid of feeding the wavtable prim' with a bunch of wavetable text files and a huge selector?

You may replace the text wavetables with float array prims. However, in this case the problem is not that significant. In this situation you use text prim to actually store data that is not that significantly big and is requested only once in a while. I mainly meant situations where text prim is connected for example to a mono to float array prim that is triggered by a ticker. float array is converted to a text and displayed on screen several times a second for no apparent reason. The biggest no-no is to even use that text prim in between float array connectors. Array must be converted to text and then back for no reason, wasting CPU for conversion and also for displaying the text on screen.

[kortezzzz]

Thanks for the example KG.

The schematic still needs to fire triggers to load the samples and that seems to be the bottleneck

Seems like it has very long neck The performance are bad. Wish there would have been an additional multisamper , a prim' only, with the necaessary ins\out that works smoothly and fast as possible. What we have right now is actually not useable.

However, in this case the problem is not that significant. In this situation you use text prim to actually store data that is not that significantly big and is requested only once in a while

I see. So it's depends on the way you use it.

Thanks.

[MyCo]

Seems like it has very long neck The performance are bad. Wish there would have been an additional multisamper , a prim' only, with the necaessary ins\out that works smoothly and fast as possible. What we have right now is actually not useable.

Noticed that the wave load/save primitives use internally a very slow float <-> PCM conversion. And with slow I mean ridiculously slow. When you want to compare it, store a version of a wave in IEEE-Float format and then compare the load time of the Float version to the PCM version. On my tests the speed difference was about 20 times.

[kortezzzz]

store a version of a wave in IEEE-Float format and then compare the load time of the Float version to the PCM version

Sorry, what is IEEE-float format?

[tulamide]

store a version of a wave in IEEE-Float format and then compare the load time of the Float version to the PCM version

Sorry, what is IEEE-float format?

It was the short form of describing a float that follows an industry standard. The complete name is

IEEE Standard for Binary Floating-Point Arithmetic for microprocessor systems (IEEE 745-1985)

But you don't need to worry about it. If a sound tool offers writing wav in 32-bit float format, you're on the safe side (unless that tool is some crude 2-hours-backyard-project of a kid).

[CoreStylerz]

The schematic is wrapped "as is" into a VST plugin.
Flowstone exports as just wrapped schematics. What you do in ruby is interpreted with the interpreter, what you do in assembly is assembly, what you do in code is assembly. All other stuff are what they are.

The VST interface provide input and output to interface with the host.