[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] adding UGens / classes
What about this then?
TSinGrain.ar(numChannels, trigger, dur, freq, pan, env, mul, add);
TFMGrain.ar(numChannels, trigger, dur, carfreq, modfreq, index, pan,
env, mul, add);
// For TBufGrain, pos is where to start the grain at... not middle
position
TBufGrain.ar(numChannels, trigger, dur, bufnum, rate, pos, interp,
pan, env, mul, add);
TInGrain.ar(numChannels, trigger, dur, in, pan, env, mul, add);
building the delay into TInGrain could be messy (it would add
maxDelay, delay, interp parameters) but it could be done. Adding these
and leaving TGrains as it is I think is also cleaner, breaking NO code.
Leaving the leading T off of the UGen names is also fine by me, but if
that is done, I would like to propose:
GrainSin
GrainFM
GrainBuf
GrainIn
to avoid the conflicts in my lib.
comments?
Josh
On Nov 27, 2007, at 10:07 AM, Scott Wilson wrote:
On 27 Nov 2007, at 16:14, Josh Parmenter wrote:
I'll look more at TGrains to see if output can be mono easily
(ignoring pan in those cases)... then will look to see what would
need to be done to pass in a user envelope (and if all the above
can be done without breaking user code). If it can, I'll make
versions that fill the grain with sin or FM (thereby adding two
UGens)....
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.
OK. I think it's probably reasonable to include them both.
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.
I think they should all have a similar interface, so all should be
potentially multichannel in output.
I'd also love to have some form of InGrain, with Env possibilities
and a delay/offset control, but perhaps that could just be done with
TGrains and RecordBuf so it's not necessary.
Actually... one other thing that BufGrain does different the
TGrains is the startpos. TGrains shoots for the playback point to
be at the middle of the grain, where BufGrain gives playback points
to at the beginning of the grain. I do like the later better... to
get TGrains to playback at the beginning of a sound buffer, you
would have to:
dur = 0.1;
rate = 2;
centerpos = dur * 0.5 * rate; // !!!
TGrains.ar(2, trig, bufnum, rate, centerpos)
With BufGrain, you just say 0
I actual prefer to specify grain start as well, but it does seem
like a fairly minor variant. I suppose TGrains could be changed,
although I have a feeling that this came up in discussion before and
people were against it.
Maybe it could be implemented as a cmd? That wouldn't break anything.
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
*/