DSP Robotics Support

Forget the follower thing. It was just a fast mockup of a first idea. But it does nothing else than the DeZipper Nubeat mentioned. I totally forgot that the easiest solution is already in your toolbox
However i think i don't fully understand what you're trying to do so i can't give any serious advice here. Just keep in mind that switching any a stream with a selector causes audio glitches. No matter if the stream is muted or faded out pre or post the selector.

BTW: There are others here or the SM forum which do way cooler things than what i do.

Hi TrojakEW,

I started with the HARD switcher ... using the MULTIPLEX PRIM ... that worked BUT was not pleasant to hear in the real-world scenario.

Right now I'm trying to work a type of fade OUT and then fade IN during the switch over from stereo MAINs to Stereo AUX.

I have a basic concept wired up ... I've just now discovered that I need to be able to reverse the order. Hard to explain ... easy to hear when it's a problem. But basically trying a fade out [using SLIDE], with a delayed fade-IN [SLIDE].

Trouble I'm at, when it comes time to switch back, I need to change the order of the fade IN and OUTS.

Kinda tricky this one

stw wrote:Forget the follower thing. It was just a fast mockup of a first idea. But it does nothing else than the DeZipper Nubeat mentioned. I totally forgot that the easiest solution is already in your toolbox
However i think i don't fully understand what you're trying to do so i can't give any serious advice here. Just keep in mind that switching any a stream with a selector causes audio glitches. No matter if the stream is muted or faded out pre or post the selector.

BTW: There are others here or the SM forum which do way cooler things than what i do.

Hi stw ... ok ... but it DID work!

But I think you're getting the right sense of the problem ... I AM having to switch audio streams. The 'glitch' can be enough to hit the PEAK LED in the DAW.

It did seem to help using the FADE OUT and IN.

But your last sentence was like ........ a LAST SENTENCE


So I wonder ... if the switching is going to be audible ... well ... if I first fade OUT, Switch, then fade IN ... might this not soften the transition??

I was trying to do something similar before with multiplex and was able to do it with trigger delay, but this also cause lag to preset change. So I never get really "working" version. Only solution for me was asm multiplex.

so you dont really wish a slide or, it just would be to avoid glitches...

here i have 2 more solutions, one is just a simple if statement in code form, which shouldnt produce any glitches when switching

the second is like fade out before setting the channel to 'off' and fade in after setting the channel to 'on'
here are selectors in use to disconnect the channel completely which also results in recompiling the prject

Nubeat7 wrote:so you dont really wish a slide or, it just would be to avoid glitches...

here i have 2 more solutions, one is just a simple if statement in code form, which shouldnt produce any glitches when switching

the second is like fade out before setting the channel to 'off' and fade in after setting the channel to 'on'
here are selectors in use to disconnect the channel completely which also results in recompiling the prject

Absolutely AMAZING Mr NuBeat !

I just 'real-world' tested the 'second' design ... that being the fade out-off-fade in. I tested at the 1000ms setting first ... smooth

I then went back, cleaned up a small section of my code, and then knocked the transition time down to 250ms.
Everything transitioned wonderfully ... even doing a 'master bypass' that switches 8 samplers ... not even a HINT of a glitch or any time warp dance

This is fantastic !!

Of course, I went inside to take a look ... just a handful of PRIMS but, the logic AND the solution ... it works!!
I just learned a little something with the way you handled the selectors with yin/yang conditions. It's such a simple, elegant way of handling those dual conditions ... I just never thought to do it that way. [I won't tell ya how I've been doing them ... but I'll start setting the condition straight at the input].

Thank-you NuBeat ... this put a nice smile to whats been a rough time. Much appreciated.

I need to test the transition time to see how tight we can go with this. The 250 worked great ... but I have a feeling I can halve that [or less]. This is something that I need to add to another project ... glitch-LESS transition.
Even my monitors are happy about this !!!

you `re welcome Rj,
if the green triggerdelay isn`t precise enough at small times (20ms or so) you could use a ruby triggerdelay which should be more precise (this you also can do in samples)..