New to modular synthesis so sorry if this is an obvious question, have tried searching to no avail.
I have a simple patch set up with a clock (Impromptu’s Clocked) running into an XOR gate (Bogaudio Bool). The clock is sending 1x speed and /2 speed trigger pulses into the two inputs of the XOR gate, with the desired result being that the simultaneous pulses will cancel out, and I’ll be left with every second pulse (offbeats) of the 1x clock as an output of the xor. 1111+1010 = 0101 if that makes any sense?
Instead, the XOR gate seems to misfire semi randomly when receiving the simultaneous triggers from Clocked. I have tried wider pulse widths, sending the clock output to gate>trigger converters first, using a different logic gate, increasing audio buffer size, etc. Nothing seems to help, which leads me to think maybe I am misunderstanding something fundamental about how logic gates are used or how precisely I can expect them to operate? For what it’s worth I have also built the exact same test patch on MiRack for iPad and experienced the same problem, both with low CPU usage and no spikes.
I understand there are other ways to achieve this result, but from my limited, beginner perspective it seemed like XORing a clock against a division of the clock (in this case from the same module!) would be the simplest way of generating offbeats.
I think this is a subtlety of overlapping gates. The divided clock has a twice as long gate and the edge of it just overlaps the rising edge of the main clock 2nd beat. Clocked has gate length control, set the divided gate to 0.25 (the size of the original clock gate) or very close and it should give a proper “off- beat” clock effect.
I take it back, using a logic after 2 outputs of Clocked is puzzling, I did the same thru count modula’s Clock Divider and it works like it should with no adjustments at all, something is odd about the Clocked outputs into logic.
Indeed, the pulse width will have a great effect on the results. I tried it now with very short triggers, and it worked perfectly. I used the built in pw control on Clocked.
You mentioned that you tried it already, but maybe give it another try.
Thank you for that, sending the output of Clocked into Clock Divider first instead of using the inbuilt dividers on Clocked gives perfect outputs from the XOR.
Cheers for the suggestion, I did try playing with the pulse width from Clocked again as you suggested but couldn’t achieve proper triggering from the gate. Did you set the pulse width on Clocked as its minimum possible setting, or something else? Did you set the 1x and /2 clocks to different PW values to achieve perfect overlap? It seems strange that it works perfectly on your end. As mentioned above I did get proper triggering but only when running Clocked through a different divider module.
Thank you for uploading your patch. I had a look and it is indeed triggering properly, but only when Clocked is at 120bpm (or 60, or 240). It seems any bpm other than a multiple of 60 brings back the false triggers from the XOR. When using a separate clock divider, the triggers are perfect at any bpm. Very strange behaviour, it would be great to understand what’s going on here!
Oh, wow, this is indeed very weird… I tried it with the clock from Sickozell, and it works as expected, but with Clocked, it’s all over the place.
Maybe @marc_boule can help us with this?
Hi Omri and friends, I believe the problem comes from the fact that in Clocked, the pulse width is normally a percentage of the clock period (with a hard minimum enforced so that no pulse width can be less than 1ms). So this means that when both PWs are at 1 (minimum value), the pulses produced by two outputs with different divisions will often be of different durations, and thus xoring them will not produce the reliable pulses wanted in that patching scenario.
In regards to using external clock dividers, I didn’t try this, but there could be subtle differences that also happen to fix the issue, in the fact that using an external divider introduces more cable latency, whereas in CLOCKED, the clocks are calculated internally and are sample perfect, meaning that when a /2 clock output should rise at the same beat as a x1 clock output, they will rise on exactly the same sample.
I tried the patch with CLKD instead of CLOCKED, which has an option to produce triggers (since it has no PW control), and it does seem to work properly:
I will think about adding that option to CLOCKED, but in the mean time, for this specific case it might be best to use CLKD, and if a CLOCKED is also needed for some of its features, we can just chain a CLKD to run off of the CLOCKED. I think that in the original patch, it’s perhaps even an accident that it worked at all as intended!
Cheers, I appreciate the detailed response. I did initially consider the pulse width may be responsible but had ruled it out after sending the outputs to gate>trigger converters before the XOR but still experiencing the misfirings. I guess that might be introducing its own small timing discrepancies though?
Good to know I can just use CLKD for this. It was mainly worrying me because I am still wrapping my head around CVs and boolean logic and I thought I was misunderstanding something very basic about how they operate. The whole issue, especially learning about the inherent cable latency has made me think I should in general not rely too heavily on perfectly synchronous triggers (even though in this case they are possible) if there are other ways of achieving the same or similar results.
