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:
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.