Anyone know of a free sequential N->1 switch (or addressable) that has de-click functionality (or option) for switching audio signals?
The only one I am aware of is the VCV 4->1. But I am looking for at least 8 channels.
If the de-click option is an adjustable crossfade, then even better.
You might be able to use this, although it’s not a switch, its more like 8 VCAs with lag generators on the CV? The normalled connections let it do a little more than you might expect.
Perfect! I paired it with the ML Modules 1->8 sequential switch with10V input. The channel outputs select the correct input channel on SLADE.
Nice crossfade capabilities. But I was looking for clocked increment/decrement selection.
Just for fun and in case someone is looking for a “VCV-native” version, here’s a 16-step sequential switch based on VCV1-4.
It’s a two-tier approach, in which signal flow to four switches is controlled by a higher-level switch.
My PolySplice module can do up to 16->1 switching, sequential or other methods, has a slew that could “de-click” the inputs, and I’ve used it for audio without issues, does this cover what you need?
Well both Slade and Nu-Poly Splice worked perfectly once I combined them with some additional modules.
This functionality is part of an emulator patch with a Patch Master UI. I need the number of switch channels to be under user control.
For me the Slade was more straight forward in my use case.
I had to think a bit more to get the Nu-Poly Splice to work. But once done, it worked beautifully. The step direction is controlled via radio buttons, so I needed an extra MIX 4 to provide the needed CV.
Is it just the goal of this specific patch that caused this extra work, or is there an improvement I could make to the module that would make it more usable?
I don’t quite understand what you are trying to achieve, in the PolySplice version you are only using 3 channels?
I always have 8 channels patched in, but the number actually used at any given time is variable.
I have a PatchMaster knob controlling the ML Poly Splitter Channels knob. But in a general sense it should allow CV control as well.
For my use case it would be great if PolySplice had a Channels knob to control how many channels are used for switching, with the rest being ignored. I think it should have CV input as well.
I didn’t need it in this case, but it would also be cool if there was a Start knob and CV input to control where to start the switching sequence. So if Channels is set to 3, and Start is 5, then switching would occur between channels 5, 6, 7. The sequence can wrap, so if Start was 15, then channels 15, 16, 1 would be used.
I found the Mode knob difficult to use, I guess because you have to turn so much to get to the next mode. I’m not sure what could be done about that.
The faceplate displays the selected mode, but the knob hover menu should also display the selected mode name. I naturally look at the menu rather than the faceplate when I “twist” a knob. Also, Patch Master could then display the mode name as well. If labeled properly, I probably would have controlled the mode with a Patch Master knob instead of radio buttons.
Thank you, excellent feedback, I will have a think about these points and see what I can work into the module.
I can do something about this, when I built the module I wanted to experiment with this UI control, because the default knob controls don’t suit mode selection well, but until now I have had no user feedback on if what I changed is better or not.
modeKnob->setAngle(0.5f);
modeKnob->snap = true;
modeKnob->horizontal = true;
modeKnob->forceLinear = true;
modeKnob->speed = 2.0f;
Would you say its the horizontal change (you move the mouse left to right to change the knob, instead of up and down) that is difficult, or the speed, or the linear movement?
Eureeka! I never realized your knob was non-standard, and you must drag horizontally to move instead of vertically, so of course I struggled.
Now that I understand how it works, it works perfectly fine. When I first started with VCV, I struggled with all knobs because I was dragging the knob in a circular pattern. I eventually learned to just drag up and down.
If you used a horizontal slider instead of a knob, then I think using horizontal motion makes sense. But I don’t think it is a good idea to make your knob behave differently then the standard.
Unexplained UI, it is a common issue and even if I had documented it, I expect most users don’t read the manual.
Obviously I designed the module for myself, so I like the way the knobs works, but I can see how it being different to 99% of the other knobs in Rack would be non-optimal.
I think I’ll add a right-click menu option for standard/mode-selection knob behaviour…
By the way, in case you were not aware, when you hover over a knob you can simply use the scroll wheel (if your mouse has one) to easily move the knob, I find this quite a pleasing way to interact…
Cool! But, you do need to enable this in the Rack View menu.
Ahh - I wondered why it wasn’t working for me.
I tried it out, and wasn’t sure if I liked it or not. Then I noticed that the history was not reliable when I moved the knob with the wheel. Sometimes Ctrl-Z would restore the previous setting, and sometimes it would restore an earlier unrelated action. So I don’t think I will use the feature.
I never noticed the View->Knob mode menu option before with three knob modes. Make sure you honor the selected global option if you implement your right-click menu option.
Make normal mode be the default seems like a good idea.
I need 8->1, not 1->8, but that is not particularly important. Yes your 1->16 patch can work fine if you always want to switch between all 16 channels. But if you want all 16 channels patched, but allow the user (or CV) to dynamically specify how many channels to use, then the patch must become way more complicated.
Before I had the sense to ask if there was an 8->1 switch with de-click available, I actually implemented 8->1 using multiple VCV 4->1 switches. I didn’t worry about making it pure VCV, and it was still pretty damn complicated. Besides working out the overall logic, I also had technical issues like converting the incoming trigger into a 1 sample trigger, and inserting the correct number of sample delays for certain paths. Had I learned of the much simpler solutions before, I never would have taken the time to do this. It was kind of a fun challenge though.
Below is a video of my solution. The entire top row (except the recorder) is functioning as my 8->1 switch. The ADDR-SEQ Select control marked by a dark blue square is controlled by the Patch Master Grains control (which I am controlling manually throughout the video). In turn the ADDR-SEQ drives the TRANSIT module, which controls the 5 controls marked by a lighter blue square to the right. The FADE modules are working as instantaneous switches.
I color coded the cables to make it easier to trace the logic of the patch. The pink cables are the incoming trigger that gets converted to a 1 sample trigger, represented by the purple cables. The rest is fairly straight forward.
EDIT: I just realized I don’t need TRANSIT to control the two 4->1 switch sequence lengths since each switch is already being reset at the appropriate time to cycle back to step 1. I can simply leave those two switches at length 4.
I think it would be fair to say that any module that acts like a switch should have an optional de-click built it. IMAO.
I originally did this for the harmonic level CV inputs in Chebyshev. It is fun and easy to run various things into those, but of course it can click. so I put in the lag generator.
Then I thought it (the lag generator) was so cool (and low CPU) that I made Slade - maybe it was even in the same release.
Later that same lag generator was a key part in the limiter in F2, which I immediately put aside to make Comp with… the same lag generator.
Anyway, even though I have a (well earned) reputation as “the alias police” what I really, really hate is hearing an otherwise good sounding synth path that is popping away like crazy. It’s almost like a constant 1/8 note metronome with a random volume continues all the time. I really don’t like that!
Not the same issue, but similar is modules with DC on the outputs. I even wrote about that years ago: https://github.com/squinkylabs/Demo/blob/main/docs/dc.md