I do have a really strange sync problem with Hermod and trigger riot,
I send the clock out from gate 8 of Hermod to clock in of trigger Riot, and from.Hermod 8 CV out ti reset in of trigger riot.
Case 1)When I compare the clock out from Hermod to one of the Output of trigger riot they are in sync
Case 2) when I compare Hermod clock out with Hermod gate out 1 they’re in sync
Case 3) when I compare Hermod gate out 1 with the clock out of trigger riot ( clocked from Hermod) they’re in sync
BUT
When I compare the Hermod out 1 with one of the Output of trigger riot they’re out of sync …
Using clock shifting 001 on trigger riot make them to sync but it’s per step and can’t be set previously
logically, Id say that one of these statments is false
however… it could be your equality check is imprecise - e.g. perhaps comparing rising edges vs falling edges, or its not 100% in sync, and then trigger riot is perhaps do something like quantisation, or perhaps there is something odd going on with reset.
one thing to check is reset, different modules treat reset different - some want it as a ‘run signal’ others as a reset, some on rising edge, some on falling.
(Ive seen this with Frap tools usta)
if you have some kind of oscilloscope (e.g. mordax data) then you could look at all the gates and reset and see whats going on.
sorry, I don’t have a trigger riot to check with (and im not that familar with it) ,
but for sure, i know it can be a bit fiddly getting (multiple) sequencers all in sync.
Actually was just cycle settings in trigger riot who wants a little time to go in sync for the pattern outputs, the statement are clear and they act like that there’s no logical fallacy check again i wrote Hermod gate out 1 ( channel 1 gate out)
Basically Hermod clock is bit wobbly at start ( checked on scope) and trigger riot start is a bit wobbly that’s all
if trigger riots is attempting to estimate the BPM , then the issue is probably related to the fact that Hermod does NOT send the clock whilst the transport is stopped.
this is an issue I have noticed with USTA,
(USTA cannot accurately estimate the BPM until its seen a few clock pulses, so intially it is out of step)
Ive previously sent a feature request to Squarp, to allow (an option) for the clock to always be sent regardless of transport state - this would resolve the issue.
(this feature is already present on the Pyramid)
if this would be useful to you, Id recommend also sending a feature request to Squarp via the contact form, so they know its useful to others as well
