From: James Harkins ()
Date: May 17, 2008
Subject:
Re: *explain* nextTimeOnGrid
On May 17, 2008, at 2:48 PM, James Harkins wrote:
> All I want in the piece I'm working on now is to have something
> start on the next whole beat plus 1.
> Currently (and inexplicably) that isn't possible with the Quant /
> nextTimeOnGrid framework.
Since that e-mail was a bit testy, in the middle of a programming
session that wasn't going as well as I would've liked, maybe it makes
sense to explain the context.
The obvious answer to my question is, "Why don't you just add one to
whatever you get back from nextTimeOnGrid?" That isn't an option
here. It's a through composed piece where the computer will have to
keep in sync with the score. Also, for rehearsals the code has to
support starting at predefined places in the middle. So I'm working
out a multilayered architecture with chucklib processes at the
bottom, wrapped in timeline iterators, of which several comprise
sections (play can start at the beginning of any section at any
time), and the top level is an array of sections that play through in
sequence.
Because I need to control the order in which scheduled processes
execute (for instance, a "conductor track" controlling meter changes
etc. must run ahead of all other processes), it isn't as
straightforward as simply scheduling processes for "now" relative to
the iterator or section triggering them. The processes have to be
scheduled for some time in the future, from which a small amount is
subtracted for processes that have to run earlier. That's the +1.
With so many objects involved, the only way to keep everything clear
is for them to manage their own timing, and they do this by asking a
timing object what time they should start running. That timing object
uses nextTimeOnGrid, but in the case of quant = 1, phase = 1,
nextTimeOnGrid returns incorrect results and the whole system goes
out of whack.
It's certainly something I can solve without making any changes to
the main library -- just use a different timing object that handles
phase the way I think it should be handled -- but I still have the
question about why it is the way it is currently. It doesn't make any
sense to me, and I see no harm in changing nextTimeOnGrid to this:
nextTimeOnGrid { arg quant = 1, phase = 0;
var offset;
if (quant < 0) { quant = beatsPerBar * quant.neg };
^roundUp(this.beats - baseBarBeat, quant) + baseBarBeat + phase;
}
If standard usage is to have 0