[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.