TempoClock:setMeterAtBeat

[James Harkins-2]

I'm working on a piece that will use frequent meter changes (first time in supercollider for me), so I'm looking carefully at TempoClock's setMeterAtBeat method and it seems unnecessarily complex to use.

// meter should only be changed in the TempoClock's thread.

// bar must be integer valued when meter changes or confusion results later.

That's a lot of opportunities to make mistakes in your code.

I don't know to what extent people depend on this method, but this seems to fit the profile of a private method to me (since very specific conditions have to be met before it can be called). 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);

})

}

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.

Any objections?

hjh

: 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

[Tom Hall]

Hello James

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

> I'm working on a piece that will use frequent meter changes (first  
> time in supercollider for me), so I'm looking carefully at  
> TempoClock's setMeterAtBeat method and it seems unnecessarily  
> complex to use.
>
> // meter should only be changed in the TempoClock's thread.
> // bar must be integer valued when meter changes or confusion  
> results later.
>
> That's a lot of opportunities to make mistakes in your code.
>
> I don't know to what extent people depend on this method, but this  
> seems to fit the profile of a private method to me (since very  
> specific conditions have to be met before it can be called).

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

> hjh
>
>
>
> : 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

[James Harkins-2]

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.

hjh

On Apr 21, 2008, at 5:16 AM, Tom Hall wrote:

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.

: 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

[James Harkins-2]

Just occurred to me, setMeterNextBar could be simpler:

setMeterNextBar { arg beatsPerBar;

this.setMeterAtBeat(beatsPerBar, this.nextBar);

}

Any objections to committing this?

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.

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.

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

[Tom Hall]

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