Re: [Hydrogen-devel] transport design discussion / questions

[<jl...@im...>]

The debate goes on...

>
...
>> For now, we could allow both ticks and ms offsets, and then decide later
>> what happens if they're both present.
>
> I wonder if maybe a union (frames OR ticks OR ms OR ticks+ms) might be
> more appropriate.  Giving the inputs a choice of how it's scheduled.  I've
> omitted the idea up to now because it sounds complicated.

Yes it does, but if that's what we want in the API, let's do that. The
implementation can be optimized later if all goes well.. Personally I find
unions (as in C) a bit ugly, perhaps we do it with overloaded functions,
or just different function names? (ie. scheduleByTicks, scheduleByMs..)

...

>> Another thing to be considered is the status of the internal timer of
>> hydrogen. Your design is based on the sequencer always running as slave,
>> and the internal and external (e.g. Jack) timer being interchangeable. I
>> feel that the internal timer should have special status though -- one
>> good reason for this is that any other application, acting as jack time
>> master, might at any time give up that responsibility, and hydrogen
>> would receive jack__bbt_valid == false or what ever it's called -- and
>> the internal timer should be ready to take over. In that situation, the
>> jack transport (i.e. play, stop, rewind etc) would still be used, but
>> with our own timer
>
> This is *sort of* the idea.  Note that JackTransportMaster (JACK transport
> slave) is not complete... and that's why it doesn't handle the case where
> there is no B:b.t info.
>
> But, JackTransportMaster is *the* internal timer for Hydrogen.  There is
> no other.  If the jack server doesn't provide B:b.t (or provides _invalid_
> B:b.t), that class is responsible to provide a good fallback.

Yes, and that will be something like "OK, where were we... Let's keep
going from there, whith the present tempo, possibly taking info from the
song and the playback state (looping, pattern or song) of Hydrogen into
account". And that exact same thing happens whether we have
JackTransportMaster, XXTransportMaster, or InternalMaster (or whatever
it'll be called when there's no external sync source). So it wouldn't
really make sense to have that functionality in all the -Master classes?

I guess my suggestion here is to have that code in either Transport (what
is currently an abstract base class) or in H2Transport (which I think of
as some sort of proxy between the sequencer and the various transport
classes), if that makes any sense.

...

> How we implement this remains to be seen... but from what I recall, the
> calculations are simple enough that I think we can avoid a 3-way transport
> mediation.  :-)

Naah, come on, we should have three-way meditation, that would be dead
cool :-D

> [1] Actually, this makes it possible to be the JACK Transport Master...
>      but not be a JACK Transport Slave.  Not sure if anyone wanted
>      that...

We could be slave to MIDI timecode, and master to other JACK apps :-)

See you
 -- Jakob

Aah, one more thing, about note off messages... Currently in Hydrogen
(trunk that is), if there's no note off, a sample WILL play 'over its
tail' in the sense that two or more instances of the sample can be playing
simultaneously... You can hear this if you select eg. a long ride, fill
8th notes, and adjust the 'humanize time' button (it will create some sort
of random comb filter effect). Also, if you adjust the note lengths so
that the notes don't overlap, it will again sound differently.