My pleasure! 
@unlessgames This is very smart - thank you for the module. Yes, this is just a work around to allow us to move forward with this issue. Iâll add immediately this afternoon maybe if I can get time after work 
and let you know if the 5 sec max is not enough . . . I guess that depends on how long that delay continues lol
since our last discussion, I have indeed identified the culprit to one of my patches I have been using as examples. I figured it out simply by listening to that burst (its the first example) and identified the sound-source, then followed the logic of what was shoving a per-mature gate its way. I deactivated that module, saved, loaded - and . . . . . silence. It was creepy. 
Activated, repeated and there it was again - clearly its the only module, in this patch that is causing it. The other patch (delay in spectra pic) I have been using as examples has more of the same developers modules. I have more than four uses of them, various ways in this patch.
That said gentleman, @unlessgames @marc_boule, what is the best approach: post on Rackâs github page reporting this problem then link back here for support, or mention the modules here, or just contact the dev directly.
Iâm afraid itâs more desperate than smart
If you can indentify one specific module being the culprit, you should notify the dev in some way, some of us are here, almost all can be found through their contact/source link in the library or inside Rack itself by right-clicking the module -> Plugin
But are you sure it is one module? Can you not create a patch that starts with the noise burst, but doesnât contain said devâs modules?
What do you mean by premature gate? In theory, a gate sent âtoo earlyâ should only cause a sequence being out of step at worst, isnât it? Or you mean it is similar to what was found in the mixer? A gate like signal sent in place where audio is expected?
For me, all sorts of modules that load audio samples seems to contribute to the intensity of the noise, but if I build a big enough patch the noise burst can be present without those as well.
Since the potential issue is with a specific developperâs modules, Rackâs github page is not appropriate IMO, and if the dev has a github page, an issue there would be best I think. Contacting them in the forum is ok also I think, but github should be ideal.
Cheers!
@marc_boule thank you for the advice.
@unlessgames it is more like a desperate measure - I agree!
Yes I can create a simple patch without said devâs module and it does not have the burst noise at load time. Also, I am sure its this particular module in this patch from my testing. To be clear, I narrowed it down in, this particular patch. In my mind, I was sure it was just one set of modules from a dev but now I am not so sure anymore. In another example patch, I cannot pin it on one single culprit - freaking odd. I disabled a few, AND, one that was clearly okay (i had thought) in above patch, and the noise burst was gone. I saved after deactivating - loaded and there was no noise burst during load!! Is it you (I) can have only â10â modules but boy if you have â11â watch out when loading??? Is this the secret-sauce?? I will say also, the above module I am sure about in first patch is not being used in this 2nd example patch - so a whole other set of modules and problems emerge. TBH I had screen shots, examples etc to share but I hesitate now to share - so I will not. It is starting to get under my skin actually . . .
I am seriously thinking its just flat out a systemic issue - as you are basically alluding too. I think it is a number of things contributing to itâŠso I am going to implement pre-muter into the patches and just go from there. These two patches (and others of mine) can run for hours, to nausea without an audio stutter, or an overrun audio buffer⊠just run run run. No issues.
Iâll give it a few days and maybe do further testing
1 Like
Sir, I thank you. I implemented pre-muter and it rocks. Actually, it does the complete opposite - it harness the power of VCV and tells it to wait a flipping moment please. 
It addresses the unwanted bursts. Since it is clear that rack is moving forward with the vst plug-in version for DAWs and v2 - I believe thatâs what I read but may be mistaken, no more work will be going into this v1.1.6 - it is what it is - so this does indeed rock.
⊠I would not be adverse seeing a range up to 10 seconds. Reason that it may take a moment to load and gives us bit of head-room beyond the current 5. It is a knob, easily to select, 0 - 5 (or 
10) so this is magnificent. Set it, and forget it . . . the sleekness, simple - bravoâŠand thank you again. ( Do you have a tip-jar location, please? ) IMO, those that do have this problem - would love this module!
My conclusion is that there is a lot of things contributing to this audio-noise loading of a patch. I also firmly believe it could be avoided globally - via system - but heyho. When I say a lot of things, I am referring to modules that are running during initialization during a load and sends a cv/bang/gate/pulse to a sound-source once its landed/loaded - which maybe it is reacting to the module its connected to as well, or it just inherently does it - at initial load. I have yet to try and load audio files into a module in a patch to process as you had mentioned you do, but so many things are at play here - so many things.
I honestly believe IF it is the systemâs hardware/os/video drivers/audio drivers, there would be other programs and other instances of use cases that this would already had become strongly apparent. If you use windows os for example, as I do, you would have already had your hands deep into regedit, would have already run the latency checks and software utilities (like latency monitor, dpclat) studied the data logs and made appropriate adjustments from what it disclosed.
moving on . .
I looked up wiqid email address and will be asking him to review this thread and hopefully we can get some positive feedback or direction
below is 1 example of a module that I have identified that has this behavior for me. I love these module(s) and wonât not use them - I obviously have them in several patches
in the pic you can see, there is nothing other than this module and ways to capture the event. Itâs the same drill, screenshot, pix of audio file, upon the initial load - it fires . . . on the scope, please focus to the far left. (scope2) I adjusted re-burst cv to show negative to differentiate - coming from trig and cv port.
âŠto be clear, this all happens upon the loading of the patch.
True, but afaik the audio rendering is being rebuilt more or less with v2, so it might solve this issue altogether! There will be no reason to stay with v1.1.6.
15 seconds max then 
Iâve updated the builds!
About the Burst module being the culprit: are you saying that if you donât use that module in a patch, you never have the noise burst either? Maybe it is module-related for you then! Letâs hope the dev responds (they werenât active on github for over a year).
I do have one now! You can find the link in my readme.
However, I feel the need to point out that when I said you should report the issue in exchange for pre-muter, I didnât mean to imply that you owe anything⊠you donât!
I appreciate it nevertheless! 
one knob to rule them all, lol exactly. Thank you for this . . . this is perfect.
This issue has been more like an onion - getting to the root of my original issue/problem. I am hopeful it has been helpful for others too. It had been masked by a few things as they have been identified. For example, the mindmeld mixer DC-block oops, that since has been addressed, which then cleared a path to discover other causes of the issue.
If I use Burst, I am guaranteed to have the noise audio-burst due to its behavior at load time. I am surprised I am the only one that has reached out about this issue. If the trigger/gate is connected to a sound-source or whatever - every time it will happen.
Also, recently, I have discovered this loading a patch when I use the gate on quantum module:
see scopes == this is a screenshot from loading this example patch. Second scope, see far left of scope (audio). Taking this simple example and expanding this idea, multiplying it across several sound-sources - dude, you can build a bit of a burst, at load time
My hypothesis: there are several modules that have this type of behavior. I am not a dev and I have no idea why this would be needed / required (noob here) behavior during the loading of a patch into memory to use. These modules load running and bang the gong. Perhaps I am misusing the gate on the quantizer. I donât believe I am. I know I can use the gate, in this example, from permutation - but thatâs not what i was after. To be clear, using the gate from permutation, I do not have the burst.
I have not heard anything from the dev and from what you mentioned I am doubtful I will.
so . . . this is where I am with it all
One knob to rule them all . . . this now is sorted - set, and forget it.
1 Like
You âshouldâ log bugs with all the modules that do this. It is a bug, it can easily be fixed.
I will be happy to log them to the appropriate developer and reference the discussion here - thanks @Squinky
1 Like