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

["Dan Stowell" <danstowell@xxxxxxxxx>]

Well FWIW I don't agree with Ross, I think that keeping both for 3.2
and then dumping the old one for 3.3 would be standard deprecation
practice. But I'm not strongly motivated, happy to leave them named as
they are.

Dan


2008/1/12, Click Nilson <clicksonnil@xxxxxxxxx>:
> 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
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>


-- 
http://www.mcld.co.uk