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.
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?"
> perhaps cosmetic, but it would be nice to be able to act as MIDI time slave
> and / or master at some point). Also, there are some state variables in
See above. Good suggestion. I've been thinking about doing this with
InConcert as well.
> 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.
> Pattern mode is a bit funny - it seems that tempo changes aren't handled as
> well there. When you press 'play' the pattern starts from beat 1, but if you
> press rewind and then play, it sounds like beat 1 is played twice !??!!
I thought I heard that in Song mode, too, recently. I was throwing a lot of
wacked out
tempo changes, though.
Peace,
Gabriel
-------------------------------------------------------------------------
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
