I’m fairly new to VCV and was looking for a nice way to create a One-Shot Sequence.
Been watching a video by @Omri_Cohen about the Muxlicer and thought that would fit nicely for what I wanted.
This is the video, the One-Shot part is at about 8:35 to 10 minutes (video should start there)
I recreated that little chain (with a different sound source), but it didn’t work as expected. Same thing when using Noise as a source.
So I downloaded Omri’s original patch (3 levels of sequencing with the Befaco Muxlicer | Patchstorage) to have a look what I might be doing wrong. But still the same issue…
The issue is that there’s a constant audio signal whenever the first slider of Muxlicer is turned up. Even if Muxlicer (or a clock) isn’t running
Short video here >> Gofile - Free file sharing and storage platform
This simply isn’t happening in Omri’s video, although the first slider of Muxlicer is all the way up. When I’m running his original patch in VCV there’s an everlasting signal on track 2 (NOIS) of the mixer.
So why on earth isn’t it the case in his video?? I know he’s a Guru and I’m only a newbie and all that, but this is really strange to me…
Only way to stop the signal is to turn the first slider of Muxlicer all the way down.
Besides things like muting, disconnecting cables or turning the Drive of Tangents down, stuff like that. But all of that is certainly interfering with the usecase.
I was hoping that changing the “All In Normalled Value” or the “Input/Output mode” in the right-click menu of Muxlicer could be the solution, but that’s not the case.
Since I’m more or less a beginner I’m admitting that I might just be misunderstanding or overlooking something very simple. But I have no idea what it could be.
So, could somebody please enlighten me?
Hidden cables, how we can understand your patch, man?
see an ophthalmologist. Those cables aren’t hidden.
play the video
download the patch and have a look yourself. By doing that you could even change the colors and the opacity of the cables to your likings.
It’s not my patch, it’s Omri’s patch. Pretty much the whole topic is about that.
On the screen capture, the cable are nearly invisible (for mine old eyes).
Yep of course, I understand it’s Ohmri patch.
Okay, I’ll download and try the patch ASAP.
Sorry, didn’t want to be rude or something.
Just thought I immediately ended up with a troll lol
It’s true that the cables aren’t very good to see. Didn’t think about that before.
Don’t worry, I have a sense of humour.
I wasn’t rude too (I hope), and I am not a troll.
I had the same issue. By setting the 1st slider on the Muxlicer to zero I could “solve” this issue (at least for me).
The video by Omri was made in Jan 22, the last update of Muxlicer was May 22. Maybe there were significant changes aftert the video was made. The changelog says “Chaining using reset now works correctly”.
I have the same issue, too. You’ve surely right about possible signifiant changes (since the video)!
Yes, setting the first slider to zero works for “killing” the audio signal.
But this turns the 8 step sequence into a 7 step sequence, and the timing of the first (audible) step isn’t correct anymore. Since it’s originally the second step.
Short video, just a variation of the chain, to make it more obvious (and with visible cables ) >> Gofile - Free file sharing and storage platform
Would that basically mean that Befaco updated something that worked to something that doesn’t work anymore (the One Shot mode of Muxlicer)?
Exactly, that’s why I said: I could “solve” this issue (at least for me).
Maybe ask Befaco about that.
Another “solution” using an additional VCA driven by the “all gates” output of Muxlicer:
Beat me to it! I was just in the process of posting the same.
Note that the Gate Mode must be set to 1/2 gate so that the sound plays throughout the entire step.
At the default 1 setting it only plays for 50% of the step.
I believe the issue is related to the Address knob. I’m not sure what the correct behavior is - the hardware manual is confusing as to how it is supposed to work while the Muxlicer is not running.
Ok thank you folks.
So the bottom line apparently is that Muxlicer today is working differently than it did at the time Omri made the video.
I ended up using a different filter than Tangents and am using the All Gates output of Muxlicer to open the filter. Changing the Gate Mode of Muxlicer is nice to alter the sequence from time to time.
Hi @deepspace thanks for your interest in Muxlicer. I’m the dev that’s been working on the Befaco plugins, I also have the hardware version. Befaco themselves aren’t responsible for the code beyond supporting me (e.g. sending hardware units). First thing to say is, at least for the hardware version, the sequential switch has to redirect one of the inputs to the outputs (same, e.g. for VCV 4->1 Sequential switch), that’s just how an analogue switch works AFAIK.
On the hardware, and seemingly the earlier version in VCV, the final step was chosen - I think the reason you don’t hear it in Omri’s video is just that the volume/slider of the final step is 0. There was a bugfix to allow chaining Muxlicers with one-shot, that may have caused this “regression”, I’ll take a look.
However to me, this fix is just a variation of the same issue - you now would just hear the final step indefinitely instead (unless zero vol). So maybe it’s possible to add a context menu function to mute outputs on stop. I need to be careful though, because Befaco don’t want people buying the module assuming a certain behaviour/feature and getting a different behaviour.
ps I like the VCA solution of @Ahornberg / @DaveVenom as this is probably what you’d do with the hardware
Might not have anything to do with it but make sure on the Impromptu Clocked module that you set set the following right click options. Clock kept high on stop uncheck, On start send reset pulse checked and on stop do internal reset checked.
I ran into this as well when trying to chain Muxlicer into a 16-step sequencer. It’s a very clever module, but has some quirks that make sense in hardware but create some difficulties using it in unusual ways in software. Still a great module though!
Looks like I might have to check my “ambient abandoned factory” patch and make sure that the Muxlicer is still working how it did when I built the patch. It would kinda suck if the behavior of the module changed and messed up how that sequence plays, as Muxlicer was the only sequencer I could find that worked for that particular piece of sound design.
[EDIT] sequencer still plays the one-shot fine, nothing stays high/on when the sequence ends. I am not using the individual gates though, I am using the “all gates” output and a pair of MEX expanders to send the gates where they need to be.
Thanks a lot for taking the time and explaining all that
After all it’s not that big of an issue. It was just confusing and odd to experience this different behavior when doing the exact same thing with the exact same modules like Mr. Omri Cohen did in the video. I had no explanation how that was possible, so I had to ask here.
Haven’t thought that it could’ve been caused by an update of the Module, until @Ahornberg mentioned it.
I agree this is likely the best solution. But to open a Filter with the All Gates output of Muxlicer worked well with the sounds I had and it fit the context of the patch quite good, so I did it this way.
I wouldn’t call it a “regression”, it’s just different than before. And if I understood you correctly it’s not even possible to avoid this behavior in general, because you said “… the sequential switch has to redirect one of the inputs to the outputs…”
(at least “not even possible” when replicating the hardware 1:1)
Rightfully so and I completely understand this. It’s very generous to offer those Modules for free anyway. And I also think it’s nice to have those Modules working the exact same way like the hardware.
Thanks for that - it makes perfect sense now, and greatly improves my understanding of how the module works. Even with that understanding, I don’t think I would have ever figured out why it used to work in the Omri video on my own.
I notice that your Gate Mode parameter mislabels two of the settings. Starting fully counterclockwise, your 2nd setting is labeled as 1/2 step, but it corresponds with the Gate = Step time on the hardware. Your 3rd setting is labeled as 1 gate(s), which is correct, but it corresponds to the hardware half step time.
The hardware labels make sense. The 1/2 step time is a “standard” step with 50% duty cycle.
Currently the info menu directs the user manual option to the Befaco Muxlicer module page, and then the user must find the link to the hardware manual in the resources. And once found, it can be confusing because many of the hardware options are moved to the VCV module context menu (I understand out of necessity).
On your github site you list most of the changes you made to the VCV module, though you neglected to mention the tap tempo feature.
I think it would be helpful if the user manual menu item directed to your github site where differences are noted and from there add a link directly to the Befaco Muxlicer manual (assuming Befaco is open to that change)
Thanks for the comments Dave. Good catch, I’ve fixed the labels (see here). I also like the suggestion about manuals - Muxlicer is complicated enough that I think it warrents its own page, which I’ve started here: Befaco/Muxlicer.md at v2-mtr · hemmer/Befaco · GitHub - this will be added to over time hopefully though.
I will eventually link the module manual link to this page, but not yet as the link will need to be from VCV/Befaco, not my fork.
Both hardware and software have tap tempo, just tap tempo is in the menu - I’ve made this clearer in the docs.
Finally this happens to be on a branch containing a new module so if you were to check out the nightly build with the fixed labels you would see it…