As for using a buffer filled with a sin wave, that seems to be adding a complication that users don't have to deal with for other oscils, It isn't a requirement for SinOsc, and I think that is good. And yes, FM would be much more complicated. Of course, if the modulator is 0, you would just get a Sin tone, so maybe all that really need to be done is the building of an FM granulator, and the user can pass in 0 for the modfreq and index? Not obvious though, but if there are reasons to limit the number of additions, this could be one way to do it.
As for the Envs, I'll look into that some more. Shouldn't be hard. But I think having the option for the built in Hanning window is also a good idea. There are some efficiencies there, and it works quickly.
So, to sum up - possibly make TGrains able to output mono. possibly make TGrainsEnv make at least TFMGrain (and TFMGrainEnv) (also mono to ???) if wanted, same for Sins.Then I will leave my grain ugens in my library. I think the above would be good for the distro, giving users some good tools for granulation right away. As for phase, my UGens all start at 0. However, that seems like a more advanced parameter to have. Perhaps I will add that to my UGens, and users can download those if they want that parameter.
Josh Josh On Nov 27, 2007, at 7:09 AM, Scott Wilson wrote:
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. _______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel
****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/