Re: TempoClock:setMeterAtBeat

Hello James

On 20 Apr 2008, at 23:25, James Harkins wrote:

Agreed, its mainly used by beatsPerBar_

> I'm tempted to ask if this might be changed to prSetMeterAtBeat and  
> then replace setMeterAtBeat with something that will handle the  
> scheduling for you, e.g.
>
> setMeterAtBeat { arg newBeatsPerBar;
> this.schedAbs(this.nextTimeOnGrid(beatsPerBar, 0), {
> this.prSetMeterAtBeat(newBeatsPerBar, this.beats);
> })
> }

Wanting something like this is understandable, I've used something  
similar in the past.
Instead of
t.schedAbs(t.nextBar, {t.beatsPerBar_(3)});
you want to be able to do
t.setMeterAtBeat(3);

But see comments below.

> But if that carries too much risk of breaking code, I'd be content  
> to call the new method something like setMeterNextBar and leave  
> setMeterAtBeat as is.

I think setMeterNextBar is a much clearer name.
The point about setMeterAtBeat is that the beats is an argument.
Without that, the name doesn't make much sense?

What about something like setMeterAtBar(barNum, beatsPerBar) ?
then setMeterNextBar could be

setMeterNextBar{| beatsPerBar | this.setMeterAtBar(t.beats2bars
(t.nextBar), beatsPerBar)}

Though a warning would be needed in the help file about not changing  
meter before another already scheduled _later_ change.

> Any objections?

As above. While I agree the change may not break code, it could be  
argued that setMeterAtBeat isn't a great name for what you propose,  
as your new name suggestion setMeterNextBar already implies. Having  
something like setMeterAtBar would also provide more flexibility IMHO.

Perhaps another issue around bars/beats is that the its a little  
confusing that nextBar returns beats and bar returns a bar, but  
changing that would break code for sure.

2c

Tom


_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel