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

Re: [Sc-devel] adding UGens / classes

What does BufGrain give you that TGrains doesn't?
if you have to ask this then you prolly have to really use them to
tell. Pretty much like asking why would you need *yet* another lpf
when we have one - why a moog yada yada.
sorry totally off line scott.


On Nov 27, 2007 7:01 AM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> On 26 Nov 2007, at 23:15, Josh Parmenter wrote:
> > By the way... if we did add in the granular ugens, I think a subset
> > of them would be good. Probably just the Sin, FM and Buffer ones,
> > with just the 'standard' grain and user supplied grain (this would
> > be six ugens). I also think it would be good to add a number of
> > channels and pan arg to them similar to PanAZ (allowing mono output
> > or grain by grain intensity panning).
> >
> > I don't think it makes sense to add in the more complicated
> > enveloping ugens, or the ambisonic versions. These are specialty
> > items, and wouldn't make sense in the standard dist...
> >
> I agree that a subset seems appropriate, as granulation can be very
> idiosyncratic and vary quite a lot in small ways between
> implementations, so very basic tools are probably what we want.
> Just to play devil's advocate:
> What does BufGrain give you that TGrains doesn't?
> Is MonoGrain different from InGrain in any way other than an
> alternate interface?
> Do SinGrain and FMGrain give you any real advantages over just doing
> it with a few UGens? (i.e. besides convenience; only a couple of
> lines of code after all)
> Not really opposed in principle, but thought it was worth asking. I
> haven't used these extensively, as I have my own (quite
> idiosyncratic) implementations of granular stuff.
> Flexible envelopes is the thing I miss most from TGrains, and one of
> the reasons I do have my own granular stuff. (It after all can make a
> rather large difference in the result.) So that would be something
> that I'd like to see in the distro. Personally I think I'd prefer
> being able to pass Envs as args rather than the buffer approach
> though. I assume it's done that way for efficiency, but in most cases
> IME (I'm often producing reasonably large numbers of simultaneous
> grains) I don't think the overall load is that significant. That
> might be an argument to go for the convenience, and leave it to a
> custom solution or Quark for those who really need to squeeze out
> every drop of CPU.
> S.
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel