SWING: reset input causes timing glitch

[bram2000]

Heya, I'm trying to reset SWING in order to have odd lengthed patterns (e.g. 5 note swing pattern that syncs with a 5 note arp) but the reset seems to glitch the timing momentarily. Not sure if this is just the nature of the phase based clock but it would be awesome if the reset to first position could be done seamlessly.

Cheers!

[Stubs42]

Hi, Swing uses a phase running von - 10 to 10v. It starts one half phase before the timed step ending one half phase after the timed step. The early clock is produced at phase start. Thus allowing to time the timed clock earlier than then normal step timing. After a reset there is no way to send the early clock a half step early so the first early clock is sent on the first step and the timed clock about 40 samples later to give your patch time to process the early clock before the times clock arrives. This will result in a delayed early clock and a delayed time clock on the first step after reset. This is behavior by design and I don't see a way to avoid that. So do not reset swing while your patch is running. To sync swing with the patch timing the clk input is the better choice.

Hope this explains the time glitch after reset. If I misinterpreted your issue please let me know.

[bram2000]

Yes that makes sense, thanks for the detailed response.

My mind is trying to find a way to make this work... I'm wondering if we could just queue up the reset to apply on the next clock cycle (so complete whatever clock is happening right now, then move back to the first step without any interruptions to eClock). I'm not sure if this would work however. I find controlling reset behaviour quite complex (inconsistent) when using SWING so for now I've moved back to clocking DEJAVU directly from Clocked.

[Stubs42]

I've done a lot of patches clocking DEJAVU from SWINGs eClk and never had any timing issues. Maybe because I reset SWING only once when I start patch. I would be interested for what reason you reset swing while the patch is running. Maybe I can find a solution if I understand the problem.

[bram2000]

Say I have a sequencer that I want to clock from SWINGs tClock output; the question is where to take the reset signal from. The reset signal that comes from my master clock is a long way ahead of the first tClock tick. This seems to be a problem for some sequencers which expect reset to hit alongside the first clock tick.

I've actually found a solution which is to use something like the RCM Seq Adapter or Sync (smaller version). I feed this with the tClock from SWING and reset from my master clock. It detects when reset is hit with a stopped clock, and waits until the clock starts before firing the reset. So far this has worked well in all cases I've tried.

It would be lovely if this was built into SWING itself, so you could patch up both tClock and tReset into any external sequencers and they would receive reset and clock simultaneously as seems to be expected.

[bram2000]

I've not actually had much reason to use the eClock yet. I mostly end up patching tClock in DEJAVU directly, and using the polyphonic trigger outs to trigger random melodies from MOTHER (fed from the CV out).

I'm a bit confused because when using the eClock then all of the gates/triggers would be out of sync with the beat, I guess you shouldn't be using anything clocked to eClock as an audible trigger so assuming it's just to feed e.g. other random seed inputs.

[Stubs42]

Hi, I already realized that eClk of SWING isn't used by much people yet. I myself nearly never patch anything to the tClk of SWING. All sequencers I use (trowasoft voltseq/trigseq is my favourite) do not have a problem with the first clock coming after reset. Also OranceLine modules like SWING, MORPHEUS do not do step advance on the first clock after reset. Reset behaviour of a lot of sequencers is an all time problem in vcv/modular. There are many different solutions already discussed a lot. Maybe you should give the following setup a try (see pic). This setup has a lot of advantages. Use Reset from CLKD to reset and the eClk to clock the sequencers (no problem with first step with good sequencers). On advantage of this is that since eClk is early. At the time the timed trigger will be generated all needed values for gates, pitch, modulation are already ready and there is only little need for sample delays in rare cases. Without patching the TIME input of GATOR, it used PHS and CMP to detect when PHS is crossing CMP. If there is a gate at the GATE input it will create a timed Trigger matching the tClk of SWING (just one or two samples delay, which never caused any problem to me). You don't use a trigger sequencer but one that outputs gates (trigseq gate mode) for the GATE input of GATOR. Now you can use any eClk timed sequencer to provide different micro timing (TIME input), gate length and ratcheting. JTR allows to randomly modulate the timing to 'humanize' the timing of the gates GATOR generated. Nearly all of my patches are based on that concept. In a lot of patches I use two channels of trigseg to feed them into the HEAT offset and HEAT scale of DEJAVU, giving me one channel to controll the triggers i want to be always playing (HEAT offset) and the other channel to control the scale of the HEAT knob of DEJAVU to control randomly generated additional triggers. DEJAVU GATE output is set to continues gate (red ligtht) and connected to the GATE input of GATOR. This setup can then be easily extended to control timing by step, gate length, ... Since Voltseq can be used to produce gates (10V step values), I use it very often to have a single sequencer controlling gates and other modulation values like pitch, gate length, timing, filter cutoffs, ... (Random output of DEJAVU also good source for modulation).

[Stubs42]

There was a mistake in the previous screenshot. DEJAVU used the tCLK which was wrong. Instead it should use eCLK with a 2 sample delay to get the input from the sequencers running on eCLK. I edited my previous comment fixing that (exchange screen shot)