On Tuesday 26 August 2008 19:42:47 Gabriel M. Beddingfield wrote:
> Jakob Lund wrote:
> > The transport code we have now is really confusing and hard to understand
> > - I still think we have to reinvent it somewhat in order to get it
> > working.
>
> Agreed. However, we may want to try and put a half-way decent band-aid on
> it and release 0.9.4 before restructuring it.
>
> > In my opinion the transport code should be moved into the sequencer (the
> > Hydrogen instance), instead of being processed in the audio driver (this
> > is
>
> Actually... that's where the code already is, isn't it? And that's kind of
> the problem. When H2 is the master, the JACK Transport is just copying that
> code (which seems to work OK). When H2 is the slave, the JACK Transport
> code is trying to cleverly update that info. It looks like the sequencer
> was designed as a standalone sequencer (master), and later it was
> retrofitted with a slave option. So what we have is that even when
> Hydrogen is a transport slave, it *thinks* it's the master (in
> hydrogen.cpp).
>
> How about this: Create a transport interface that the H2Core::Hydrogen is
> *always* the slave to. One that is focused on mapping ticks to samples in
> the current buffer. Then, create different Transport implementations
> depending on the situations.
Yes, that's it: Transport in one place, supplying the sequencer with sufficient
info to deal with ticks and notes. Right now transport is partly in
hydrogen.cpp, partly in jack_output, and even in sampler.cpp, ticks and
tickSize are used.
>
> SEQUENCER ABSTRACT INTERFACE IMPLEMENTATIONS BACKEND
> INTERFACES ========= ================== ===============
> ====================
>
> Hydrogen <--TransportInterface <--+-- MasterTransport -->
> JackTransportAdapter
>
> | +-- SlaveJackTransport <-- jackd <-+
>
> V |
> AudioOutput +-- SlaveMTCTransport <-- MidiDriver
>
> +-- SlaveOtherTransport
>
> +--
> MasterTrickedOutExperimentalTransport
>
>
> class TransportInterface
> {
> public:
> virtual ~TransportInterface() {}
>
> uint32_t getBufferOffsetFrameForTick(uint32_t tick) = 0;
> // ... other methods ...
> };
>
> Then, H2Core::Hydrogen doesn't care about sample rates, frames-per-tick,
> samples-per-beat, tempo, or anything. We just go through the Note queue
> and say, "What sample to I use for tick 575?"
Also important, imo, is that the sequencer fix a starting frame to every note
before passing it to the sampler (or even picking the sample from the note and
passing that); the sampler shouldn't have to know about ticks or tempo at all.
> > Tempo changes from Ardour (which is about the only app that I know is
> > being a `good master`, in your terms) are working OK in Song mode; as
> > long as you make sure that 1 bar == 1 pattern on the song timeline
> > (especially important if the meter changes as well -- i.e. in non - 4/4
> > time).
>
> Maybe I'm misunderstanding what you're saying... but isn't that sort of a
> given when using the transport? ...that your time signatures need to line
> up? Gracefully handling a mismatch would be good -- but I think is sort of
> "undefined" by its very nature.
Rightly so, but the first part is less obvious. Using Hydrogen alone, it's
possible to have patterns with two or four bars in them, alternating with
patterns of 1 bar length; but not when syncing with Ardour, currently.
The information of time signature, bar length or whatever, has to be stored
somewhere as well, perhaps inside the Transport object you proposed, as a
linked list of time signatures and tempos, much like the 'timebases' you were
mentioning wrt. InConcert earlier :-) .
If the length of a bar was known at any position, new patterns could be
allowed to begin, while long patterns that hadn't yet finished could keep going
- that'd be way cool (e.g. to have some groove in a 4-bar pattern, and being
able to layer shorter patterns on top).
- Jakob.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
