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

Re: [Sc-devel] what needs to be done before 3.2?

Nick has already started indicating the rates in his new helpfiles -
see BeatTrack or KeyTrack or MFCC for example. Not sure if he's using
the same scheme as you're intending.

Personally I'm dubious. I find those little rate keywords baffling,
even as an experienced user, and I'd much prefer the rates to be
expressed in a way that a beginner could understand, because otherwise
they become intimidating jargon that makes helpfiles less friendly.

I can't think of a systematic yet understandable way to do this, so
I'm left with the fallback of explaining it in plain english (e.g.
"must be audio-rate" or "may be scalar or control-rate"). This might
be a minority opinion though.


2007/12/20, Scott Wilson <i@xxxxxxxxxxxxxx>:
> On 20 Dec 2007, at 21:33, Josh Parmenter wrote:
> > On Dec 20, 2007, at 1:01 PM, Scott Wilson wrote:
> >>>
> >>
> >> Hmm. I think there was a notion of expressing only the fastest
> >> possible rate. Is there a reason why that wouldn't work?
> >
> > Well... BufRd for instance needs a-rate for phase, but can't use k-
> > rate. This is the exception rather then the rule though, so perhaps
> > this is fine, with special note where needed.
> I'm fine with that. Any objections?
> Do we want the rates as you've done them, or in the descriptions?
> >>
> >>
> >> I'd trod carefully with this. It might be best to make a careful
> >> decision and go through the rather tedious and large job of doing
> >> this for all the files rather than risk having this patchily and
> >> inconsistently added to some files. I don't imagine you're
> >> planning to do all of them? ;-)
> >
> > UGen.subclasses.size
> > 279
> >
> > yes... daunting! But how can the general user know what kind of
> > input is allowable? Since 3.2 is supposed to be a reference for THE
> > reference, it seems like this should be included. If not now, when?
> Josh, that's the kind of bold argument I like to hear!
> >
> > I certainly can't do all of these, bit perhaps if a number of us
> > each took a UGen source file?
> >
> Okay, I'll certainly do one if we can get enough people to cover it all.
> While we're at it though, could we please, please, please correct all
> the files so that they more or less match the UGen template?
> S.
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel