Hello
On Friday 24 July 2009 19:36:23 Gabriel M. Beddingfield wrote:
> Hi,
>
> Since I'll be away for a couple days, I'm gonna go ahead and reply to this
> one instead of waiting for Jakob to reply with, "What?? Are you crazy??"
>
> :-)
>
> On Fri, 24 Jul 2009, Gabriel M. Beddingfield wrote:
> >> Very good idea! Inputs hould have to use _either_ ticks or ms/frames,
> >> though,
> >
> > I was thinking ticks + ms for Inputs.
>
> Let me explain this one a little more, since I'm not dead set on ticks +
> ms... and I think I've changed my mind. Also, I need to hunt down the guy
> who did lead/lag and give him a hug or something. Lead/lag is the coolest
> thing in H2.[1]
>
> Currently, H2 sequences schedule things like lead/lag and "humanize" based
> on audio frames and ticks (I don't remember which does what). Further,
> the user edits lead/lag by setting it to "a little before" or "a lot
> behind." IIRC, the behavior of these things change when the sample rate
> or even the tick size changes.[2]
>
> However, when I'm editing a sequence, I want better control over these.
> On the whole, I think I would prefer if I was editing lead/lag in
> milliseconds OR ticks.
>
> Reason for milliseconds: If I have a sample of a snare drum 'ghost' or
> 'dittle' hit, want the hit to lead or lag the beat by a specific time. If
> the tempo changes... this type of thing won't scale with the tempo.
>
> Reason for ticks: If I'm doing a hard rock mash... I want the high-hat to
> lead the beat a little bit. I *think* I want it to scale with the tempo
> (but I'm not sure). In that case, I'd want the lead/lag to be edited in
> ticks.
>
> So... what I *really* want is for .h2song to store <leadlag
> units='ms'>65.3</leadlag> and/or <leadlag units='ticks'>2.1</leadlag>
> (user gets the option).
>
> Looking at SeqScript, when adding notes, SongSequencer can translate the
> millisecond lead/lags to the current tick size. If a tempo change happens
> after the note is scheduled... then they won't *quite* happen at the right
> time... but I think it will be close enough.[3]
>
> If we do ticks + ms... then we can keep it accurate even during a tempo
> change... but at the cost of more complexity.
>
> So, I'm now in favor of floating-point ticks... not ticks + ms.... but I'm
> still mulling it over. What are your thoughts?
I say use ticks (floating point). If you _really_ want to have the option of
selecting setting a 'lead' value in ms, the results ought to be correct -- but
I feel this is too complicated, both with respect to the UI (imagine having to
select 'ms lead' for some notes and 'tick lead' for others), and the
implementation (resorting the internal seqScript list).
But what about MIDI? If a MIDI input needs to schedule "x ms into the current
buffer cycle", and we then convert the ms to ticks (for sorting), and then to
frames (for the seqScript output)? It seems easier to convert from ms to frames
directly, because a change in tempo (seems) more likely than a change in
sample rate.
For now, we could allow both ticks and ms offsets, and then decide later what
happens if they're both present.
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
There's also a possible relationship between the song and the internal timer. I
foresee that in the future (in fact in wolke's branch the future happens
already :-) ) we'll have tempo change information in the Song, that the
internal timer will have to respond to as it goes.
All in all I think the Internal timer should always be there, allowing itself
to be remote controlled by external timers if necessary (Jack or MIDI timecode
or whatever comes along) - and ready to feed timing information to the
sequencer, and to other receptors (Jack or MIDI time code outputs)
Lastly.. what about renaming JackTransportMaster to JackTimer, and
SimpleTransportMaster to SimpleTimer (and eventually InternalTimer)... The
JackTransportMaster and JackTimeMaster names confuse me sooo.. (I've been using
the word 'timer', but there might be a better word)
I hope I'm making the least bit of sense here :-)
Regards
-- Jakob
------------------------------------------------------------------------------
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
Hydrogen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
