Loading time tips

[Father]

I have some questions related to loading time.
in order to make the plugin load faster, using which one is better?
1. Sub modules or merged modules?
2. Wireless or wired connections?
3. Tickers, more or less?
4. Drawing or using bitmaps?
5. Embedding text or loading from file?

[tester]

1) I see no difference on apps. It's only a matter of order within your schematic.

However there are situations in which if there are too many visual or specific visual things within a module (within a visual workspace) - then navigating in that view may work slower on that particular view. Maybe it's a bug in FS.

2) No difference. They are wired or wireless only for you.

However it's good to remember, to set the connector type manually, because sometimes auto-refreshing does not works correctly (in cut/copy/paste operations).

3) This depends. In complex architecture, tickers may slow down the schematic/app behaviors. It's like with all triggers. So it's not a matter of tickers, but of clean spread of triggers across whole schematic and within specific sections within order.

4) A matter of taste. I prefer vectors. Smoothing on bitmaps may look not so good, but this depends on bitmaps and scalings. Also - bitmaps take place within the schematic (slower saving). Maybe there are bitmap vs vector specific issues, related to refreshing speeds for example.

5) If text is loaded on start, then it's within the app, thus - there is no difference. But if you load it from external file - you can edit it without interfering with app/schematic. The downside - your app must be provided with these text files if you use only external loads.

If external text is spread into multiple places in schematic - remember to reduce amount of triggers (with "changed" module for example).

[trogluddite]

Hi there,
Probably the most important thing to remember is that you very often have to make a trade between several different priorities...

- Speed of loading the plugin.
- Speed of changing presets (if you are using them)
- CPU load of the plugin.
- "Readability" - i.e. a schematic that is easier to bug-fix and add new features to.

To take the items that you listed...

1) Modules - will have only a tiny impact on loading times. Modules exist only to help us organise the schematic when we're editing it - they don't correspond to the 'sub-routines' or 'functions' that you would see in regular 'text' programming languages. However, when you combine several smaller modules into a bigger one, it is quite common that it reveals other 'optimisations' where a few primitives can be dropped because they are duplicated.
However, always consider the "readability" factor when doing this - is the tiny bit of time saved really worth it if the schematic becomes so "messy" that you cannot easily find any bugs that your customers report?

2) Connectors - again. very little difference. In terms of CPU load, there is no difference at all. For loading times, wireless might take a little longer (matching up the names) - but OTOH, by using wireless, you often end up with far fewer module input and output primitives. Wireless is also often a good way to share common data that might otherwise be duplicated.

3) Tickers - this depends on what tickers you are using. When you use the standard 'Tick25' and 'Tick100' primitives, there is only ever one instance of the ticker which all of the primitives call upon - like having a single ticker with lots of wireless links. So for those, add as many as you like - you'll save on links!
If you are using your own custom tickers, made from Ruby or Timers, then it would be better to share, because each new one you add is adding extra 'code' to the schematic.

4) Drawing or Bitmaps - this one is a big trade off. Drawing a bitmap to the screen is much faster than creating shapes and rendering text - so it will keep CPU load low. OTOH, bitmap data has to be stored within the schematic, so will increase loading times. But even then, if the bitmap is, say, your main panel background, and is replacing hundreds of primitives for drawing labels etc. it may still load faster because there is less code for FS to "build" at load time, less primitives to initialize, fewer green triggers etc.

5) Text - this depends a lot on how you use the text. If you need the text available at all times, store it in the schematic - adding another HDD 'find and load' isn't going to make things faster. However, if you just need certain text at certain times (e.g. customer clicks your "show help" button) then it may be better to use an external file.

Remember also that nearly all "green" primitives store their own "startup" data that also has to be loaded - for example any Array primitives that contain lots of data, or primitives containing samples and wave-tables. If you are going to be loading data "as required" from external files, you need to make sure that you clear data out of those primitives before exporting, otherwise you'll also be exporting all of this "embedded data" inside the export.
Ruby input and output connectors also store their values when you export (except for bitmaps) - so again, you may need to clear any large arrays before exporting.

Ruby can also be a bit of a problem for load times. Every RubyEdit primitive will have to have its code parsed at startup so that the methods they contain can be defined. It is not unusual to have essentially the same code parsed many times over (the RubyEdit primitives inside the toolbox labels and knobs for example).
This is something I've been talking to Malc about recently. By using custom Classes and Modules, it is possible to define common code once, and then re-use it wherever it is needed - but this is rather difficult to set up in FS at the moment, as we can't easily share and load code libraries. Where Ruby is used a lot in a schematic, being able to do this could potentially speed up load times significantly, so I'm really hoping that he can come up with something.

[Father]

Thanks for your replys. Very useful to have them in mind.

drawing a bitmap to the screen is much faster than creating shapes and rendering text - so it will keep CPU load low

I am drawing knobs with multiple shapes so this could be the reason for my specific schematic. i don't think i can fall back to bitmap, no control over shapes and colors. I guess i have to choose between beauty and function eventually!
Now that we are on the subject, does sharing bitmap, for example between similar knobs, make a difference or it is kind of automatic?

[Exo]

Threads can be very useful to decrease load times.

In my Synth on first load I create 4 large Wavetables that are 4096 samples and save these to the hard drive (Like the FS oscs do but with much bigger Wavetables, Flowstones are only 256).
Then the Synth loads from the hard drive every time removing the need to keep creating the Wavetables.

First load without Threads = 6.6 sec
Second load without threads = 3.8 sec

First load with Threads = 3.8 sec
Second load with Threads = 3.6 sec

So as you can see a big improvement for first load, after that not so much. But without my scheme to reduce load times every single time the plugin loaded it would be 6.6 seconds, now it will be 3.6 (except the first at 3.8) . That is a very nice 3 second reduction!

Sorry no example fsm to show but all I am doing is creating the Wavetables with an after load trigger then each Wavetable has a Thread primitive placed before it so it is created in it's own thread. Then I use a new thread also for the saving to the Harddrive.

So If you are using Wavetables especially large ones they will add considerably to load times, 3 seconds in my case.

Also I will point out that the wavetables are created from the top level of the schematic and sent down through wireless to all the Oscillators. This is important because it means they are created only once in the whole schematic.

In the past when I was less experienced with Wavetables I was creating the tables for each Osc separately (within the Osc) that Synth took about 15 -20 seconds to load and never got released

[Father]

Threads can be very useful to decrease load times.
In my Synth on first load I create 4 large Wavetables that are 4096 samples and save these to the hard drive (Like the FS oscs do but with much bigger Wavetables, Flowstones are only 256).
Then the Synth loads from the hard drive every time removing the need to keep creating the Wavetables.

Interesting, thanks for sharing. But in my case its an effect plugin so no wavetable is needed. I'll share the result when i get to the bottom of it, one way or another.
How about a loading screen or something like that, so the host doesn't freeze. has been done?

[Exo]

Threads can be very useful to decrease load times.
In my Synth on first load I create 4 large Wavetables that are 4096 samples and save these to the hard drive (Like the FS oscs do but with much bigger Wavetables, Flowstones are only 256).
Then the Synth loads from the hard drive every time removing the need to keep creating the Wavetables.

Interesting, thanks for sharing. But in my case its an effect plugin so no wavetable is needed. I'll share the result when i get to the bottom of it, one way or another.
How about a loading screen or something like that, so the host doesn't freeze. has been done?

A Load screen would have to be a feature added by DSPR, we cannot do anything until the plugin has loaded I'm afraid (via the after load primitive).

[tulamide]

I am drawing knobs with multiple shapes so this could be the reason for my specific schematic. i don't think i can fall back to bitmap, no control over shapes and colors. I guess i have to choose between beauty and function eventually!

Fear not!

I am currently working on two graphics modules that will enable you to use both, beauty and function, on the bitmap side. It also is lightweight compared to standard bitmap use. Stay tuned

[Exo]

Actually I just realized my Wavetables were being created twice on first load and only once on second load.

I made some changes and now ...

First load is 1.7 seconds
Second load is 1.4 seconds.

I have never had a Synth load so fast in FS!


Are you using any multi LFOs in your effect? These are based on wavetables so might be adding a bit to load time. There is an old schematic of mine over on SM Wiki which is called "non bandlimited LFO" (to lazy to post a link ) which doesn't use wavetables so will be faster loading and lower CPU.

[trogluddite]

does sharing bitmap, for example between similar knobs, make a difference or it is kind of automatic?

AFAIK, the same file should only load once, but I haven't seen this tested since long ago in SynthMaker.
Of course, there is another advantage to sharing - if you edit your bitmap, you can change all the knobs in one fell swoop instead of editing every single knob!

Threads can be very useful to decrease load times.

Very interesting
I've never dared to use them for routine schematics - only "emergency use" for the MIDI trigger bugs of long ago! now that I'm messing with concurrency in C++, I am a little less scared, so I might have to have a play with this.