Hi,
I’m developing mine modules covered by two plugins:
- free Ohmer.
- free/commercial OhmerPrems.
My development & tests platform is Windows 10. Also I can compile & test under Ubuntu 16.04 LTS Desktop.
Installed Studio Edition git.2efb7ff5 (but same issues concerning previous Rack 2 git builds, Win/Mac/Lin)
I’ve noticed they’re different Rack 2 behaviors - as soon as you load a patch in particular (or autoloaded Documents/Rack2/autosave/patch.json). - if AUDIO module have/had already defined an audio device or not (no matter selected audio driver, its sample rater/block size).
DSP routine (void process…) seems to have got erractic initialization after a patch is loaded (or during load).
As example, if already patched, my module must run a 2-sec self-test when both jacks are connected on the first time, not later (even if I disconnect, then reconnect any cable).
Case 1 - No audio device defined: on patch load (module’s jacks - 2 - already connected), module behavior is as expected.
Case 2 - Audio device is defined in AUDIO module (no matter the AUDIO module, its sample rate setting and block size setting), the “already patched” module does an unwanted self-test. It assumes the module isn’t patched, but patched few instants later.
I’m suspicious about APP->engine->getSampleRate() returned value while patch is loading (or just loaded). I can’t find a way to instruct my code the Rack’s DSP is really ready/stable/reliable.
Is existing - in Rack 2 API - a “kind of flag” (or variable) who is acting as “go signal”, indicating the DSP (void process) can be used on every sample? or a way to defer its execution (depite flag, sample rate checked if > 0)?
I don’t understand, I’m totally lost. 
Perhaps I miss something (it’s possible).