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

Re: [Sc-devel] adding UGens / classes




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.