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

Re: [sc-users] Coding vs patching: would you eat soup with a fork?

> (
> // harmonic swimming
> play({
> 	var f, p, z, offset;
> 	f = 50;		// fundamental frequency
> 	p = 20;		// number of partials per channel
> 	z = 0.0;		// start of oscil daisy chain
> 	offset = Line.kr(0, -0.02, 60); // causes sound to
> separate and fade
> 	p.do({ arg i; z = FSinOsc.ar(f * (i+1), 0, max(0,
> LFNoise1.kr(6 + [4.0.rand2, 4.0.rand2], 0.02, offset)),
> z)});
> 	z
> }))
> 
> and show them Sciss' max like representation:
> 
> 
> 
> 
> Then ask them to make p = 100 and imagine what the max
> patch would look like. That's when lights go on and
> people realise that the SC version is so elegant and
> expressive because of the abstraction. In essence it works
> so well because in SC you can tell the program to make you
> all these UGens, whereas in Max the visual metaphor requires
> you to 'make them' yourself.

Hi Scott,
     I'm a pd user who's learning sc at the moment, and I've been playing around with porting your example above to pd.  Though not as elegant/efficient as the sc code, none of the solutions I came up with requires the user/programmer to make all the relevant objects themselves.  A patch that works for p=20 works equally well for p=100, and is merely a matter of changing a creation argument to an abstraction (or the input to an inlet).  The "do" method is simulated by use of dynamic patching.
     I don't use Max but I would be very surprised if something similar can't be done.

Thanks,
Jonathan


      

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/