Befaco Muxlicer

[etckla]

I am not using any special modes. And when it is syncing to a clock, then one click, clockwise, on the speed knob sends it into “digital crunch” where all 8 step leds are lit at once (but dim).

That sounds kind of familiar, in that I've been confounded by this kind of behaviour before. But can't really offer help other than suggesting reset (either power down or soft reset by replacing the cable into the clock in) and double checking you haven't accidentally entered what I believe is a buggy mode (on my module anyway)

[danishchairs]

I am not using any special modes. And when it is syncing to a clock, then one click, clockwise, on the speed knob sends it into “digital crunch” where all 8 step leds are lit at once (but dim).

Not sure if this will help, but check the position of the Gate Mode knob. For testing, adjust it so that the white dot is at about 11 o’clock. And don’t have anything going into its associated CV jack.

I can get some unusual signals from the All Gates output, depending on exactly where the Gate Mode knob is situated. Usually I get nice square-wave pulses, but sometimes the pulses are very narrow, like quick trigger pulses, instead of gates with a pulse width of 50%. If I adjust the Gate Mode knob just a little, the triggers turn back into gates.

Makes me wonder if the Gate Mode pot on my module needs to be cleaned. (Perhaps the Speed pot on your module needs to be cleaned?)

Also, what is the voltage range of the clock signal going into Clock In? (Unlikely that it will make any difference, but good to check everything you can before considering repair.)

[danishchairs]

What I've realised from reading the manual is that there are 2 "quadratic only" settings - one for the gate mode (turn on with switch held down) and one for clock (turn on with switch held up)

Contrary to my previous post, it is the latter (skip non quadratic values for clock) which seems to cause buggy behaviour when it is on (ie when non quadratic values are being skipped).

Leaving it in default mode seems fine (for now)

@danishchairs Does everything work as expected for you in that mode?

I had never tried those skip-non-quadratic modes before now. I just tried holding the play switch down while powering on the Muxlicer. I can’t tell if Clock Out is skipping steps as I adjust it, but I’m not sure how to test it.

However, the Clock Out did go to full multiply once while I was in that mode and changing the division of the Clock Out. I don’t know why it did it, so I haven’t been able to replicate it.

It makes me wonder if the pot or switch is electrically dirty and if cleaning it might help. Or maybe switch bounce is a problem.

[etckla]

What I've realised from reading the manual is that there are 2 "quadratic only" settings - one for the gate mode (turn on with switch held down) and one for clock (turn on with switch held up)

Contrary to my previous post, it is the latter (skip non quadratic values for clock) which seems to cause buggy behaviour when it is on (ie when non quadratic values are being skipped).

Leaving it in default mode seems fine (for now)

@danishchairs Does everything work as expected for you in that mode?

I had never tried those skip-non-quadratic modes before now. I just tried holding the play switch down while powering on the Muxlicer. I can’t tell if Clock Out is skipping steps as I adjust it, but I’m not sure how to test it.

However, the Clock Out did go to full multiply once while I was in that mode and changing the division of the Clock Out. I don’t know why it did it, so I haven’t been able to replicate it.

It makes me wonder if the pot or switch is electrically dirty and if cleaning it might help. Or maybe switch bounce is a problem.

I'm actually looking at the sequence advance behaviour, not the clock out. I think both are affected by this mode, but Im not sure if clock out is buggy too.

Im sending a pulse from a Doepfer clock divider so I'm just counting how many pulses it takes to advance the sequence.

It doesn't feel like hardware failure to me, as default mode seems to be working fine

[LDT]

I have never used any alternative modes, so just to be clear, please tell me: If I turn it off, then turn it on without holding any buttons, I will be in default mode, right?

UPDATE, PROBLEM SOLVED!

I just moved the gate knob from its normal position (one gate per clock) and back again. This reset the behaviour and now I can multiply the rate as expected.

[etckla]

I have never used any alternative modes, so just to be clear, please tell me: If I turn it off, then turn it on without holding any buttons, I will be in default mode, right?

No, you need to hold the switch down at power on to enter the alternative mode. Youll need to hold the switch down at power on again to go back to default.

[LDT]

I have never used any alternative modes, so just to be clear, please tell me: If I turn it off, then turn it on without holding any buttons, I will be in default mode, right?

No, you need to hold the switch down at power on to enter the alternative mode. Youll need to hold the switch down at power on again to go back to default.

Ah, thanks. Good to know.

[danishchairs]

UPDATE, PROBLEM SOLVED!

I just moved the gate knob from its normal position (one gate per clock) and back again. This reset the behaviour and now I can multiply the rate as expected.

Excellent. Glad to hear it.

It’s likely that the Gate Mode pot needs some cleaning, but now we know how to correct the issue, at least temporarily, should it happen again. Just wiggle the knob a little.

[etckla]

UPDATE, PROBLEM SOLVED!

I just moved the gate knob from its normal position (one gate per clock) and back again. This reset the behaviour and now I can multiply the rate as expected.

Excellent. Glad to hear it.

It’s likely that the Gate Mode pot needs some cleaning, but now we know how to correct the issue, at least temporarily, should it happen again. Just wiggle the knob a little.

Certainly good news but Im not sure that the "dirty pot" explanation works for me anyway as the behaviour I'm seeing seems dependent on mode.

Maybe it's not got a lot of visibility because the mode itself is a bit hidden and not obvious to access

[LDT]

UPDATE, PROBLEM SOLVED!

I just moved the gate knob from its normal position (one gate per clock) and back again. This reset the behaviour and now I can multiply the rate as expected.

Excellent. Glad to hear it.

It’s likely that the Gate Mode pot needs some cleaning, but now we know how to correct the issue, at least temporarily, should it happen again. Just wiggle the knob a little.

Certainly good news but Im not sure that the "dirty pot" explanation works for me anyway as the behaviour I'm seeing seems dependent on mode.

Maybe it's not got a lot of visibility because the mode itself is a bit hidden and not obvious to access

Well, my issue was not because of the hidden mode. More likely for me, I think it was because I have not moved the gate knob in ages. It seemed to just need a little excercising.

[mandlia]

Thanks again for your feedback. I appreciate it!

… snip …

I think the cv range circuity is definitely the place to check first… right?

I agree. The first thing to look for is a cold solder joint. If you find one, it will be easy to fix.

I’m attaching an image of part of the schematic. I’ve circled the components close to the analog portion of the cv range range circuit. Look there first. If you find a cold solder joint, reheat it till it looks / tests good.

There are a few other joints / components near the ones I’ve circled. Check them if all the circled ones look / test good.

I was reading through this thread looking for clues to explain the drift/glitches I have when using my freshly built Muxlicer kit with a quantizer. I have exactly the same problem as johannes described, even though I didn't understand it was due to a high-freq. interference until now. So this is really helpful. @johannes were you able to solve your issue?

[Devilwidget]

Can anyone comment on how useful an addition the MEX is? It seems relatively functional, but perhaps a little too simple given there is already all those gate outputs...

[LDT]

Can anyone comment on how useful an addition the MEX is? It seems relatively functional, but perhaps a little too simple given there is already all those gate outputs...

At first I thought it was just a per step on/of gate switch and was not interested. But the cool thing is that the switches have three positions where the third position gives you the clock output with whatever division that is doing. So it definitely gives you something you did not have immidiate access to before.

[johannes]

Thanks again for your feedback. I appreciate it!

… snip …

I think the cv range circuity is definitely the place to check first… right?

I agree. The first thing to look for is a cold solder joint. If you find one, it will be easy to fix.

I’m attaching an image of part of the schematic. I’ve circled the components close to the analog portion of the cv range range circuit. Look there first. If you find a cold solder joint, reheat it till it looks / tests good.

There are a few other joints / components near the ones I’ve circled. Check them if all the circled ones look / test good.

I was reading through this thread looking for clues to explain the drift/glitches I have when using my freshly built Muxlicer kit with a quantizer. I have exactly the same problem as johannes described, even though I didn't understand it was due to a high-freq. interference until now. So this is really helpful. @johannes were you able to solve your issue?

Sorry for my late reply. No, i was not able to solve the issue yet. In my case the com io outputs a higher freq tone along the cv wich messes up the quantization. A workaround - but not a real solution - is to set the cv range on the muxlicer to max but than the cv needs to be rescaled by another module.
Others here have mentioned that this might be caused by a cold solder joint at the cv range circuit. I also contacted befaco - hope they are cool with sharing their feedback here:

„Sounds like the multiplexing is leaked to the path. Is this noise present on all the I/O jacks, or only on the Common I/O. If this is a DIY module you should contact to the builder, but you can check the solder points and if there are some shorts on the circuit.“

„ If the noise is affected by the range selection, the problem should be on this point:

CB4F2527-1ABE-4C9F-A977-5E4AA5893A64.png (7.39 KiB) Viewed 1491 times

When You connect some signal or a dummy cable to the common I/O you disconnect this block so if the noise disappear when you connect something gives us a clue.“

Hope it helps. If you can fix it please share the solution here. Peace

[airfrankenstein]

Can anyone comment on how useful an addition the MEX is? It seems relatively functional, but perhaps a little too simple given there is already all those gate outputs...

Iv'e had one for a few weeks and see several uses :
it's easier to mute notes (by turning gates off) when using muxlicer as a sequencer
expand upon ryhthmic variations and make them more controllable on the fly
this gets even wilder if you have several mex's
skip or ratcheting effects by using ths switch in the left-hand position - in that position the mex is clocked by the clock out so if clock out is faster than temp you get ratcheting and if it's slower steps will occasionally skip i - i think that's it i haven't tried to do the latter but the ratcheting works very well.
buy a few diy for 60 euros - i think befaco does free EU shipping for 150 euro orders.

[mandlia]

Thanks again for your feedback. I appreciate it!

… snip …

I think the cv range circuity is definitely the place to check first… right?

I agree. The first thing to look for is a cold solder joint. If you find one, it will be easy to fix.

I’m attaching an image of part of the schematic. I’ve circled the components close to the analog portion of the cv range range circuit. Look there first. If you find a cold solder joint, reheat it till it looks / tests good.

There are a few other joints / components near the ones I’ve circled. Check them if all the circled ones look / test good.

I was reading through this thread looking for clues to explain the drift/glitches I have when using my freshly built Muxlicer kit with a quantizer. I have exactly the same problem as johannes described, even though I didn't understand it was due to a high-freq. interference until now. So this is really helpful. @johannes were you able to solve your issue?

Sorry for my late reply. No, i was not able to solve the issue yet. In my case the com io outputs a higher freq tone along the cv wich messes up the quantization. A workaround - but not a real solution - is to set the cv range on the muxlicer to max but than the cv needs to be rescaled by another module.
Others here have mentioned that this might be caused by a cold solder joint at the cv range circuit. I also contacted befaco - hope they are cool with sharing their feedback here:

„Sounds like the multiplexing is leaked to the path. Is this noise present on all the I/O jacks, or only on the Common I/O. If this is a DIY module you should contact to the builder, but you can check the solder points and if there are some shorts on the circuit.“

„ If the noise is affected by the range selection, the problem should be on this point:

CB4F2527-1ABE-4C9F-A977-5E4AA5893A64.png

When You connect some signal or a dummy cable to the common I/O you disconnect this block so if the noise disappear when you connect something gives us a clue.“

Hope it helps. If you can fix it please share the solution here. Peace

Thank you very much johannes for getting back regarding this issue. I contacted Befaco support and got some ideas, but ultimately, I decided to go with their help in the form of the "Happy Ending" service they provide. So hopefully, the module will be in perfect condition when I get it back. Will make sure to report on the(ir) solution here as well.

[johannes]

Yes please report their solution

[mandlia]

Yes please report their solution

So, I got the module back from Befaco. I also got a refund for the Happy Ending purchase, 'cause they didn't find anything wrong with my unit, they tested it and concluded it was in perfect condition.

I have tested the module again, and unquantised I cannot hear any instabilities when using the CV out for pitch. I am not able to register any instability in the output voltage using a multimeter. I'm still however having difficulties using it musically with a quantiser though. Perhaps you guys could help me confirm if what I experience is due to this particular sequencer, or something you have to live with?

My patch is this:

1. Made a simple sequence of two notes by passing the gate out on the second step to the reset input. The Com I/O of the Muxlicer is connected via a quantizer (the Kassutronics Quantizer, but I also tried Dual Quantizer on Ornament and Crime/Hemisphere with the same results) to the V/O input of the digital oscillator Plaits, whose output is patched to my output module for listening.
2. In unclocked/realtime mode of the quantizer, I am able to reproduce "glitchy" notes easily by moving the sliders. My interpretation of these glitchy or noisy notes are that they indicate unstable CV output from the unit, and if they are on the border to another note in the quantizer's current scale, the noise is really the quantizer working at its internal maximum resolution, with the target/selected note being changed very quickly -- thus the noisy result (like a very fast trill). The risk of getting stuck in such notes is of course depending on the current scale applied, and the relative size of the scale steps laid out on the sliders.
3. If I decide to clock the quantizer at the speed of the gate outputs, the same issue will be rendered differently, with no noisy hits this time (since the quantizer works at a much lower speed), but with the altering between the two adjacent notes happening occasionally as the sequence repeats.

Do you think this is related to the high-pitch bleed in the CV out, similar to what johannes has described? I pointed Befaco support to this thread, but they did not comment on it. Not really sure what to try next, or if I'm just being too picky about this. I'm still learning, after all.

[johannes]

Iam curious about feedback from other muxlicer Users as well.

From what you describe here i think that my unit behaves just like that.

Btw Have you tried to set the cv range to the max setting? On my unit this makes the bleed go away, wich solves the quantization problem. With the downside that the cv output range is 0-10 v wich is huge and needs to be rescaled before the quantizer.

[danishchairs]

So, I got the module back from Befaco. I also got a refund for the Happy Ending purchase, 'cause they didn't find anything wrong with my unit, they tested it and concluded it was in perfect condition.

I have tested the module again, and unquantised I cannot hear any instabilities when using the CV out for pitch. I am not able to register any instability in the output voltage using a multimeter.

Glad to hear it. This is good news.

...

1. ...
2. In unclocked/realtime mode of the quantizer, I am able to reproduce "glitchy" notes easily by moving the sliders. My interpretation of these glitchy or noisy notes are that they indicate unstable CV output from the unit, and if they are on the border to another note in the quantizer's current scale, the noise is really the quantizer working at its internal maximum resolution, with the target/selected note being changed very quickly -- thus the noisy result (like a very fast trill). The risk of getting stuck in such notes is of course depending on the current scale applied, and the relative size of the scale steps laid out on the sliders.

I think you're exactly right. (I can get that same behavior using my modules.) It probably has nothing in particular to do with the Muxlicer. You can probably get the same behavior by running a fast-enough LFO into your quantizer.

1. ...
2. ...
3. If I decide to clock the quantizer at the speed of the gate outputs, the same issue will be rendered differently, with no noisy hits this time (since the quantizer works at a much lower speed), but with the altering between the two adjacent notes happening occasionally as the sequence repeats.

I'm not sure I understand this last situation. One guess is that there could be a timing issue. Perhaps the Muxlicer's gates are not happening at the exact right time for your quantizer? (You could try slightly delaying the timing of the gates with a gate delay, envelope generator or slew limiter.)

[mandlia]

Btw Have you tried to set the cv range to the max setting? On my unit this makes the bleed go away, wich solves the quantization problem. With the downside that the cv output range is 0-10 v wich is huge and needs to be rescaled before the quantizer.

Yes, thanks, your suggested workaround makes the Muxlicer considerably less prone to produce noise on "in-between notes". I have also earlier confirmed that the high-pitch tone goes away at higher range settings, exactly the way you describe. If you make an effort, I can still hit noisy notes, but it is very difficult to do so and therefore not a problem musically.

I think we can conclude that the noise in the CV out of the Muxlicer is what is causing this trouble. I guess you already did conclude that, so chiming in.

The workaround is working but cumbersome, so I would rather have a unit without this issue ...

[mandlia]

1. ...
2. ...
3. If I decide to clock the quantizer at the speed of the gate outputs, the same issue will be rendered differently, with no noisy hits this time (since the quantizer works at a much lower speed), but with the altering between the two adjacent notes happening occasionally as the sequence repeats.

I'm not sure I understand this last situation. One guess is that there could be a timing issue. Perhaps the Muxlicer's gates are not happening at the exact right time for your quantizer? (You could try slightly delaying the timing of the gates with a gate delay, envelope generator or slew limiter.)

Thanks for helping out to clarify danishchairs, really appreciate it. I tried delaying the gate signal before the quantizer, but did not succeed. I think this is due to the CV signal being noisy for the duration of the step, which seems logical given the situation. I guess delaying the gate that makes the quantizer fire could produce another pattern of note selection, but it will not reduce the instability that makes the same slider position on the Muxlicer – if being set on the border between two notes in the current scale – trigger different notes as it repeats.

[johannes]

Yes, i would also like to have a solution for that problem. But iam not sure if this a is problem that
other diy or prebuild unit users experience as well.

I will ask the guys from exploding shed and report back later…

[Befacosynth]

Hey everyone! This issue regarding unstabilities between notes has been brought to our attention and we are working on it!
If any of you have a ICSP programmer can try this code to check if it helps!

https://github.com/Befaco/muxlicer/tree ... Has_ripple

[mandlia]

Hey everyone! This issue regarding unstabilities between notes has been brought to our attention and we are working on it!
If any of you have a ICSP programmer can try this code to check if it helps!

https://github.com/Befaco/muxlicer/tree ... Has_ripple

Wow, really! I don't have an ICSP programmer but this makes me more inclined to get one. Never thought it was software, I'm very eager to test.