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?
2 Likes
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.
3 Likes
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.
1 Like
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…
1 Like
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.
1 Like
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
1 Like
I released version 2 of my Klavis Grainity emulation that uses the Nu-PolySplice solution. It works just as well with the Slade solution, except I like how the De-click control with the Nu-PolySplice method is able to display the crossfade time in milliseconds.
2 Likes
For 16->1 instead of 1->16, the path just needs to be set up backwards, but I agree that the VCV-only approach still does not provide what you were looking for. As you say, it gets quite complex if length selection is to be included. Your granular filter emulation is intriguing.
I’ve added your suggestions to PolySplice for the February beta
It was way harder than it should have been due to how I had previously coded it, but not complaining, it was fun and I am pretty happy with the result, thank you very much for the suggestions
1 Like
Fantastic!
I am a little unclear about the knob mode. Are you offering a choice between vertical and horizontal?
Or are you defaulting to VCV default behavior, with an option for your custom horizontal mode? VCV out of the box offers vertical, absolute rotary, and relative rotary.
I think the latter option would be much better.
The mode knob is now the same as other knobs by default (vertical), the right-click menu has an option to switch the knob back to how it originally worked (horizontal).
The absolute and relative rotary should be unaffected.
Edit: sorry thats not that clear either…
In Rack, by default, all three options of Linear, Absolute rotary, and Relative rotary, act in a vertical fashion.
My context menu option just flips the modeKnob->horizontal boolean, which takes effect for all three knob types.
Hope that clears things up