« Return to Thread: TempoClock:setMeterAtBeat
Re: TempoClock:setMeterAtBeat
by Tom Hall
::
Rate this Message:
Hello James
On 27 Apr 2008, at 22:25, James Harkins wrote:
> Just occurred to me, setMeterNextBar could be simpler:
>
> setMeterNextBar { arg beatsPerBar;
> this.setMeterAtBeat(beatsPerBar, this.nextBar);
> }
>
> Any objections to committing this?
I think this method name implies that you can call setMeterNextBar
(newMetre) where beatsInBar has any value, but this fails, as you
point out below.
> We might also want to think about modifying beatsPerBar_ to do the
> same thing -- that is, use this.nextBar instead of this.beats, with
> the rationale that (as noted in a comment to the set meter and beat
> method) confusion can result if you change the meter at a beat
> number other than a bar line. Currently the most intuitive way to
> change beatsPerBar does nothing to prevent that kind of confusion,
> and since that could be risky, maybe it would be a good idea to
> change the default behavior to avoid the potential point of failure.
I understand the confusion issue, however your suggestion would break
the following, which should be legal?
t.schedAbs(t.nextBar + t.beatsPerBar, {t.beatsPerBar_(3)});
As per my last post, changing the beatsPerBar should be able to be
done in advance of the next immediate bar IMHO, as is currently
possible at least with the code snipped above, and is the rationale
for the suggestion of setMeterAtBar, which could then be called by
setMeterNextBar. If this were the case, one could still cause
mischief by setting the meter for a distant bar, then setting again
for a closer one, e.g. setMeterAtBar(50, 4), followed by setMeterAtBar
(45, 3). Some bookkeeping is always needed for these kind of changes,
though whether it should be user responsibility or in the methods is
the moot point.
> Or this...
>
> setMeterNextBar { arg beatsPerBar;
> if(this.beats <= (this.nextBar - beatsPerBar)) {
> this.schedAbs(this.nextBar, { this.setMeterAtBeat(beatsPerBar,
> this.nextBar) });
> } {
> this.setMeterAtBeat(beatsPerBar, this.nextBar);
> }
> }
>
> ... where the scheduling covers the case of reducing the bar
> length. That is, if the current beats per bar is 4 and you do
> setMeterNextBar(2) on the clock's beat 1, without the scheduling
> thatClock.play(something, -1) would be expected to schedule at the
> next bar line (before) but it would actually schedule at beat 2.
> Delaying the actual meter change in that case would eliminate the
> ambiguity.
I haven't had time to test out the above, but how about this simpler
possibility (untested)?
setMeterNextBar { arg beatsPerBar;
this.schedAbs(this.nextBar, {this.beatsPerBar_(beatsPerBar)});
}
Regards
Tom
>
> hjh
>
>
> On Apr 23, 2008, at 8:19 AM, James Harkins wrote:
>
>> Thanks, Tom, for the comments.
>>
>> I may actually have to put this on the back burner, since I
>> realized for my current needs, I'll likely have to change the
>> meter variable in advance of the real bar line (so that other
>> processes that evaluate later can use the information).
>>
>> I agree that setMeterAtBeat should be left alone and any new
>> convenience method should have a different name.
>
>
> : H. James Harkins
> : jamshark70@...
> : http://www.dewdrop-world.net
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal." -- Whitman
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
On 27 Apr 2008, at 22:25, James Harkins wrote:
> Just occurred to me, setMeterNextBar could be simpler:
>
> setMeterNextBar { arg beatsPerBar;
> this.setMeterAtBeat(beatsPerBar, this.nextBar);
> }
>
> Any objections to committing this?
I think this method name implies that you can call setMeterNextBar
(newMetre) where beatsInBar has any value, but this fails, as you
point out below.
> We might also want to think about modifying beatsPerBar_ to do the
> same thing -- that is, use this.nextBar instead of this.beats, with
> the rationale that (as noted in a comment to the set meter and beat
> method) confusion can result if you change the meter at a beat
> number other than a bar line. Currently the most intuitive way to
> change beatsPerBar does nothing to prevent that kind of confusion,
> and since that could be risky, maybe it would be a good idea to
> change the default behavior to avoid the potential point of failure.
I understand the confusion issue, however your suggestion would break
the following, which should be legal?
t.schedAbs(t.nextBar + t.beatsPerBar, {t.beatsPerBar_(3)});
As per my last post, changing the beatsPerBar should be able to be
done in advance of the next immediate bar IMHO, as is currently
possible at least with the code snipped above, and is the rationale
for the suggestion of setMeterAtBar, which could then be called by
setMeterNextBar. If this were the case, one could still cause
mischief by setting the meter for a distant bar, then setting again
for a closer one, e.g. setMeterAtBar(50, 4), followed by setMeterAtBar
(45, 3). Some bookkeeping is always needed for these kind of changes,
though whether it should be user responsibility or in the methods is
the moot point.
> Or this...
>
> setMeterNextBar { arg beatsPerBar;
> if(this.beats <= (this.nextBar - beatsPerBar)) {
> this.schedAbs(this.nextBar, { this.setMeterAtBeat(beatsPerBar,
> this.nextBar) });
> } {
> this.setMeterAtBeat(beatsPerBar, this.nextBar);
> }
> }
>
> ... where the scheduling covers the case of reducing the bar
> length. That is, if the current beats per bar is 4 and you do
> setMeterNextBar(2) on the clock's beat 1, without the scheduling
> thatClock.play(something, -1) would be expected to schedule at the
> next bar line (before) but it would actually schedule at beat 2.
> Delaying the actual meter change in that case would eliminate the
> ambiguity.
I haven't had time to test out the above, but how about this simpler
possibility (untested)?
setMeterNextBar { arg beatsPerBar;
this.schedAbs(this.nextBar, {this.beatsPerBar_(beatsPerBar)});
}
Regards
Tom
>
> hjh
>
>
> On Apr 23, 2008, at 8:19 AM, James Harkins wrote:
>
>> Thanks, Tom, for the comments.
>>
>> I may actually have to put this on the back burner, since I
>> realized for my current needs, I'll likely have to change the
>> meter variable in advance of the real bar line (so that other
>> processes that evaluate later can use the information).
>>
>> I agree that setMeterAtBeat should be left alone and any new
>> convenience method should have a different name.
>
>
> : H. James Harkins
> : jamshark70@...
> : http://www.dewdrop-world.net
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal." -- Whitman
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
« Return to Thread: TempoClock:setMeterAtBeat
| Free Forum Powered by Nabble | Forum Help |