Rack stutter audio-noise Loading a Patch

@marc_boule I spent about . . . wait, let me turn the room light back on and allow you to come out from the corner … :upside_down_face:

I tested about an hour loading random patches, first with just the ones with the scoop attached which showed much desired flat-lined. Then, against my better judgement, others with headphones on, and main levels up. . . happily, with no issues. With the Mute enabled, dc blocker I always turn on, hey - it did in fact mute! As far as I can tell, the mute and DC blocker is working!!

Awesome. @marc_boule thank you for addressing so quickly. Quick question though, why would DC blocker ever be an option? I cannot see this never not enabled - imho. I think it is defaulted to off too btw…I may be wrong.

From my testing, I say push this version out to one and all. This is terribly exciting. I, I am not kidding, the relief knowing that I don’t have to muck about with my mains level with every load… or if I forget I get a burst of audio-noise that scares the every living crap out of me . . . . yay! My Genelecs thank you @marc_boule

I am very curious though, is it “normal” standard behavior for during an initial load process crap blurts out?? Is there a plethora of reasons why this does happen? Load/system/weather?

I still like to find out why the impromtu clock starts/activates on load and sends a clk, when obviously it is not enabled. With this Bang, it initiates what every is connected - seems odd to me.

TBH, I wish, the audio globally, had an on/off option, the “run” engine is in a pause/off state. All modules / deactivated at load. Similarly the way MAXmsp sorts it out having to ‘start audio’ to get things moving. Having Rack at load ALL be inactive, until “rack-engine” becomes “turned on…” manually … just jabbering now

1 Like

Great news! Glad this was sorted out. I’m sorry it caused you so much lost time :frowning: and thank you so much for the detailed debugging :slight_smile:

For Clocked, if you turn off the option in the right click menu called “Outputs reset high when not running”, it should start up with a low clock signal, which may help for you case. There are many use cases and possible implementations for clocks, so this may seem weird, but in some cases it’s better like this. In any case, there are many options in Clocked’s menus, so it’s good to take a look in there if there’s a behavior you want changed.

For DC blocker, agreed that it could probably be on by default since it’s not a big thing to compute anyways.

Cheers and thanks again!

1 Like

you are very welcome @marc_boule I was happy to provide all the detailed debugging and testing efforts. The important thing here is we able to figured out the problem and you were able to address it!

Thank you too regarding the Clocked hint and explanation. I took last evening and started to review and study all the documentation you provide for the massive impromtu library - I have so much to learn but appreciate the challenge. I will make that adjustment you suggested that will help in this case and be mindful of it moving forward.

Cheers

@unlessgames I still am curious why this happens in the first place. Is it a systemic issue that can crop up time-to-time of Rack, is it my misuse of modules, my system performance . . . ? should I be just glad it now won’t be "“heard” and roll - with - it ? :slight_smile:

1 Like

@marc_boule almost forgot - could be no big deal but - your release preview build link text is v1.1.12, but the zip file is 1.1.11. old guys like me get confused fast seeing this . . . :wink:

Not sure what you mean. My assumptions about the source of the noise turned out to be false, it was a bug in MixMaster.

Are you saying the noise is still happening despite the fix?

That is intentional, so you don’t get the red update dot which would overwrite the temporary version you manually installed. But as soon as the 1.1.12 hits the library, it will update it automatically and you’ll be automatically back in sync with the library :slight_smile:

1 Like

@unlessgames sorry for the delay I actually had to work today and I wanted to squeeze in a test or two before I answered fully. The short of it, the answer is yes absolutely and also no, not quiet. It’s late for me and I need to gather my thoughts so not to speak out my arse. I’ll get back to this tomorrow morning. I felt I needed to at least clarify a little now, but tomorrow it will become clearer-we all freakin hope right? :slight_smile: cheers

No need to apologize for spending your time on other things! I don’t work here either.

Your answer kinda confused me tho, maybe because you answered both yes and no, or because you’ve used the phrase “not quiet” when talking about stuff related to something being audible or not :smiley:

I assume you still have some sort of noise burst on startup.

I also experience similar stuff sometimes, when loading up more complex patches that are supposed to be making “full sound” right from the start. I don’t know if this is something related to my setup, the modules I use, or is a general issue that most people just don’t care much about.

Reflecting on your first post, this behaviour might be a crucial difference between Rack and other music software. Most other software is not trying to make sound automatically as soon as possible (while still loading up graphics etc.), usually they have a master play or something that you have to toggle to start hearing things. Rack has engine off, or you can mute your mixer or whatever every time you quit a patch, but I don’t like this solution, when I want to quit a program, I want to do it asap.

Maybe the protection of speakers and sanity might be a good justification to put that “space bar toggles everything” feature into Rack that I’ve seen many people ask for…

Or have a work around module made specifically for this, that is basically a mute that waits a bit before enabling sound… this feels wrong too :slight_smile:

But I’m rushing ahead here, maybe it has to do with something else…

Your answer kinda confused me tho, maybe because you answered both yes and no, or because you’ve used the phrase “not quiet” when talking about stuff related to something being audible or not

…arrrrrg true, that is confusing and the wrong spelling - I was tired and banging the answer out on my phone which is never a grand idea. Isn’t it amazing how one letter out of place changes its entire meaning. :roll_eyes: sorry yes meant to say [not quite] / not yet

Your assumption is correct I still have a noise burst on startup - granted it is a lot more “pleasant.” This is still at the root of it, which ultimately revealed mindmeld’s DC-block issue that since had been corrected. Ty @marc_boule!!! It’s like, I thought, I had one problem somewhere, but it turned out there are multiple things going on here.

You are absolutely right, regarding your comments reflecting on my first post. That is at the crux of it isn’t it? I am with you, if I wish to quit (aha, I spelled it correctly too) a program I want to quit it and not need to do things manually for next time start up - there needs better safe-guards overall imo.

I don’t believe that you are rushing ahead, from my analysis and testing yesterday, it is disclosing another issue. In my case, in laymen’s terms, one thing is banging another thing once, thus causing audio burst for no good known reason. It’s the “premature downbeat” of the patch

I would need to deactivate, assuming it really does this to the module, each module that I might suspect initiates a LoadBang (sorry maxmsp term) at load which initiates the sound source module to produce a sound. Further what is nuts, imho, it’s just one pulse/gate/cv amount …a module, on load - pulses a cv value out.

I’m digging the idea of a special module to just stop this on load until all is loaded including video graphics, or the “press space bar I’m all loaded let’s get started” action! I totally agree…I vote yes!

…so this is what I meant above by saying, so I should then expect it’s just what vcv rack does.

Using the previous really cool let’s pre-record at load module simplicitier - I received these results. It’s screenshots of the audio burst. The 2nd one, has the sound source going thru a delay … as it shows … nuts!

Fun fact: I loaded/unloaded this 10 times and got the exact same results for both patches. Obviously mindmeld mains-out were not muted. ( heyho - when muted, the result is as expected - mutes…yayyy :slight_smile: )

…as you can see, it’s a much more pleasant but extremely bad for the heart if not expecting at loud levels - pro tip: I always expect it now

lol, love the delay approach, you could even make music from this :smiley:

I was rushing ahead because this might not be something that everyone experiences, it could still be an issue stemming from audio/video drivers, general audio setup etc.

Until (if ever) this problem is solved properly, I’ve made a module that mutes the signals on launch for x seconds then applies a one second fade-in to avoid popping as well, so you only need to put it between the Audio-8 and your mixer, no other action is needed.

Keep in mind that this is nothing more than a work-around. In exchange for it, you could make an issue on Rack’s github page reporting this problem! :wink: If you do so, link it here so I and others can stand behind it.

For now, you can find the module inside my dev-builds (it is called pre-muter). Tell me if the 5 seconds max is not enough…

1 Like

in case someone installed my dev-build before I’ve made this comment, I’ve changed the versioning from now on to use the technique explained by Marc

thanks @marc_boule!

2 Likes

My pleasure! :wink:

@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 :slight_smile: 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. :smile: 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 :wink:

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. :grinning: 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 :crossed_fingers: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!

:man_shrugging:

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 :stuck_out_tongue: 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! :slight_smile:

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. :slight_smile:

1 Like

You “should” log bugs with all the modules that do this. It is a bug, it can easily be fixed.