[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] server naming conventions cleanup?

Changing this seems like it would impact on a lot of plugins; would seem too much to force everyone to recompile everything to be compatible with 3.2. Can we please keep the old names even if they're not the most elegant? (though actually, we might live perfectly well with calc_BufRate, as Ross also notes, and this is the only controversial one). Or at least allow both to persist; unlike Ross, I don't recommend a harsh name swap at this notice. 

just my opinion,
N

On 10 Jan 2008, at 14:56, ronald kuivila wrote:


Hi guys,

This may be gelding the lily, but...
How about calc_SampleBlockRate and, for consistency,  calc_SampleRate?


RJK

On Jan 10, 2008, at 6:38 AM, Ross Bencina wrote:


Hi Dan

Thanks for the feedback... re the rates stuff:


I'd also like to mention one which came up re my chapter. In the
plugin API the constants for the different rates are calc_ScalarRate
(scalar-rate), calc_BufRate (control-rate), calc_FullRate
(audio-rate), calc_DemandRate (demand-rate). "calc_BufRate" to me
is a
bit opaque/confusing and it would perhaps be more helpful to change
over to "calc_ControlRate"? (Both constants would be preserved for a
while, with calc_BufRate being deprecated, since it's in the API.)
Grateful for thoughts on that.


Seems like ControlRate would make more sense for people who are in
the know,
but "BufRate" is actually more accurate to the semantics of the
operation
imho..

I don't like the idea of keeping both.. I say break plugins and
change the
name. If it has the same value it will only break things on
recompile and
developers will soon sort that out.

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



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