Quick question here:
Have used Tidal with MIDI clock to synch hardware quite a lot in the past. Been developing some new ideas lately and finding that it's tricky to get seqP
to play nicely with sending a MIDI clock. I'm sending the clock with midicmd "midiClock*24"
, but that's resulting in the slaved devices interpreting '1' measure of seqP
as a beat rather than a bar (which is more what I'd have hoped to expect).
In the last track I produced, I got around this by making bindings for seqP
that simply multiply out the seqP
inputs by 4 (similar to bar i o p = (i*4, o*4, p)
). This worked but ran into other weirdnesses when extending MIDI patterns by more than one cycle (functions seem to break up the pattern into individual seqP
units and perform the function separately on each of them). Now that I'm moving onto the next project (and the deadline is far enough away), I'm trying to figure out a better way.
I don't have a perfect example at hand but here you can see a seqP
pattern that should cover 16 bars according to the syntax, being written into just 4 bars (one beat per bar) on a timeline:
https://www.youtube.com/watch?v=v7FE0F0h3Ds
This was actually taken from a bug report I submitted to the maker of the MIDI timeline, so it doesn't describe the issue here perfectly. I'm just posting this here so that if anyone has played with the same functionality then we can get a discussion going -- I have more experimentation to do tomorrow.
The 'simple solution' of dividing the MIDI clock by 4 isn't really practical because then all the clocks downstream from Tidal (multiple independent software and hardware modules) will be running at 0.25 speed (or the opposite if I thought that through in reverse).
Anyone run into this or have any ideas towards proposing a solution?).
I have a few ideas relating to adjusting the tempo interpretation of cps and MIDI clock output rate that I'll try tomorrow -- just occurred to me while typing this and I've powered down my rig now.