Gate VST Out Of Sync Using Various Pattern Lengths

The sync to external VST effects seem to get out of sync when using varying lengths for patterns.
I have tested this with various VST trance gate and arpeggiator plugins, all with the same result.

To reproduce:

  • Create a new song, using 256 rows for the first pattern
  • Put some pad synth in the first pattern, and put a trance gate plugin for this track
  • Set the trance gate so that you will be able to hear the first bar differently than the other bars
  • Create a second pattern with a different size - lets say 64
  • Create a third pattern, which is the same as the first
  • Play the first and third patterns - you will notice they are different.

On my attempts, the VST effect (the trancegate) does not recognize the first bar correctly, and shifts the whole thing by one or two bars.

I also tried setting the second pattern to 256 and using the FB00 command to break where I wanted - the result is the same.

Can anyone else confirm that this is indeed a problem?

Would be great if you could assemble a small example song and attach it to this thread. This would make things easier / more clear for us.

But it requires an external VST… let me see if I can do a sample file with any of the free VST gates.


I have created a small ZIP file containing a sample XRNS and the mgTriggerGate.dll, in case you dont have it.
The mgTriggerGate may also be downloaded directly from their site.

Play the first pattern, then the third pattern to see that it is out of sync.
I know that this must be “by design”, since the sync is kept on the song level and not on the pattern level, but it presents a serious problem in cases when you want to introduce pauses or patterns with a different length.

If it is by design, then maybe there should be a command (effects column) to reset that sync?

Get the sample file here (it was too big to attach)

Thanks for the file. I see what you mean and understand what you would like to do, but this is something that happens in every host and has to be solved by the plugins, not the host / Renoise:
Hosts do not send out “sync bar/beat” commands, but simply tell the plugin which beat and sample position currently plays (beside the BPM and stuff). If we would now force every pattern to start at a fixed (not continues) bar/beat position, imagine what would happen if you sync for example energy XT to Renoise: You would get “holes” or “jumps” in the timeline which is for sure not what you want.

What you need is a command that resets the plugins sequencer, not in the hosts sequencer. Or simply use an VSTi instrument which resets its sequencer on every new note that gets triggered…

I was afraid thats gonna be the answer… :)
So this in effect limits the use of plugins that sync to the beat - gates, arpeggiators, step sequencers - all will work fine, until you break your pattern.

It seems like I am probably the only one who wishes it had a solution, but I was hoping there is a possible way to “fool” the external sync and shift it forward or backward.

This is indeed an unfortunate side-effect which can affect all tempo-synced plugins in all hosts. As taktik has already mentioned, the VST plugin itself simply has no concept of the pattern structure in the host, it only knows the current position in time, so the plugin developer has to provide some way to reset or adjust the timing, if it’s something the users require.

A simple workaround that I give to users of my Glitch plugin, which also suffers this same problem, is to make sure all your breaks and pauses in Renoise (or any other kind of non-standard pattern) are rounded off to the nearest full bar. In your example, if you make your pause last for 16 steps instead of 8, then the gate remains in sync quite happily on the next pattern. This may not fit the style of your song, however.

I have noticed that mgTriggerGate’s sync is a little bit “buggy” to begin with. Using your example song again… Even on the very first pattern, the gate behaviour is different at 80bpm vs 82bpm, or 120bpm vs 121bpm, etc. This gives me a clue that the plugin might be having some other minor problems in reading the correct position in time, or perhaps some rounding errors in a calculation somewhere.