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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
