Make transport compatible with Jack

[theGreatWhiteShark]

Audio driver + version : Jack

---

Right now the transport implementation is incompatible with the one of the Jack server (in case Hydrogen is the timebase master and uses the tempo and measure provided by an external program). This results in a rather clumsy solution. With an option in the preferences the user can decided whether she wants to make all patterns having the same length as the corresponding bars in the master application (manually, tedious, and error prone) or whether she will only alter speed in the external application and not the measure (restrictive).

See #950

[trebmuh]

@theGreatWhiteShark I've been reading at this twice and I'm not sure what you're referring too. Can you please write a step-by-step scenario where I could see and understand the faultive behavior?

[theGreatWhiteShark]

Imagine you use Hydrogen and another application X (e.g. Ardour) and keep both in sync using Jack. But since your song is somewhat more evolved you have to work with different measures and speeds.

• In X bars 1-4 have measure 4/4 and speed 140bpm and bars 5-8 measure 3/4 with 70bpm
• You set X as Jack timebase master
• In Hydrogen you enable J.TRANS but not J.MASTER. It will now listen to the Jack server for both measure and speed information
• Unfortunately, in the classical, constrained scenario (option matching bars) relocation (usually) does not work within Hydrogen anymore when relocating passed the fourth bar

The reason is because measure information is in Hydrogen encoded in the pattern length and can not simply adopted from Jack (in my point of view. Maybe there is a use case for this.) Instead, only the speed is respected.

To make the relocation work again, there are two options:

1. You have to make sure yourself (manually) that all pattern lengths do match the corresponding measures in X (the patterns for bar 1-4 in Hydrogen have to be of PatternLength 8 and for bar 5-8 of 6).
2. You drop the use of different measure altogether and just use different speeds and can thus use arbitrary pattern lengths.

But in any case, Hydrogen has to know about your choice and this is currently done an option in the Preferences.

I hope this make things more clear. If not, maybe the original issue #922 is more enlighenting.

[trebmuh]

Clearer explanation, thank you very much.

[theGreatWhiteShark]

I just had some sync glitches today again when trying Qtractor in combination with Hydrogen. Instead of adding some glue and adhesive tape I think the only sustainable (and maintainable) solution is to make Hydrogen compatible with JACK. 😬

Since the AudioEngine is already split off, this seems like the right moment. I will encapsulate the transport position in a base class AudioEngine will be derived from and the current tick/frame/pattern can only be accessed via getter/setter functions. Inside this class transport will be based on frames instead of ticks (but because of the getters the remainder of Hydrogen won't be able to tell the difference). This means whenever relocating transport the inner part of the AudioEngine has to take all patterns up to the supplied frame into account in order to convert it into the corresponding tick. But even for songs with a large number of patterns this shouldn't be a costly thing to do and it only occurs seldomly.

[theGreatWhiteShark]

Implemented in #1435