On 27 Nov 2007, at 14:41, Josh Parmenter wrote:
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?BufGrain doesn't require output to be stereo or more, and BufGraiB give you the envelope on the grain by grain basis.
As I said I like the envelopes. But perhaps TGrains should be altered to allow for mono rather than add BufGrain if that's the only significant difference. (Unless that's technically awkward for some reason.) But the envelope thing would be really useful.
Perhaps having a name and/or interface similar to TGrains would be sensible and easy for users. TEnvGrain or TGrainEnv?
Is MonoGrain different from InGrain in any way other than an alternate interface?Yes... makes it work like the other grain ugens (trigger based). BufGrain, like the others, also all have a similar interface, making them a little more interchangeable.
I think the triggering idea is good. Consistency is nice, and supplying your own trigger makes the UGen very general in terms of grain scheduling.
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)Well... I'm not sure what you mean. How would you do the functionality of SinGrain or FMGrain in only a couple UGens?SynthDef(\fm_grain_test, {arg gate = 1, amp = 1; Out.ar(0, FMGrain.ar(Impulse.ar(100), LFNoise1.kr.range(0.1, 0.2), Line.kr(660, 220, 10), Line.kr(100, 200, 10), Line.kr(1, 10), EnvGen.kr( Env([0, 1, 0], [1, 1], \sin, 1), gate, levelScale: amp, doneAction: 2) ) * EnvGen.kr(Env([0, 1, 0], [1, 1], \sin, 1), doneAction: 2) ) }).load(s); s.sendMsg(\s_new, \fm_grain_test, a=s.nextNodeID, 0, 1, \amp, 0.2); s.sendMsg(\n_set, a, \gate, 0);I can't think of how else to do this without having the language create the grains. This gives you one synthdef, and a global env.
Well, I just imagined that with general purpose UGens that spawn grains from a buffer or an input source it should be possible. (i.e. BufGrain on a sine filled buffer.) I can see that with FM it is a little more complicated, as there are more parameters to take into account, and if you want grains to work on polled parameters that's harder to deal with in the FM case.
It's not clear from the help files however what's happening with phase in SinGrain or FMGrain (or in terms of time offset, etc. in InGrain), so perhaps that complicates matters?
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.Making versions that take Envs would be fine for me also. Like I said, I would also like to add a numChannels option that lets the user output the grains as mono, stereo, etc with grain by grain panning.
I think that's a really good idea. There's also a complication that can come up from granulating a stereo or multichannel source, which is that it's sometimes nice to have stereo or multichannel grains themselves. That's probably too complicated to deal with without turning these into FrankenUGens, however.
S.