yeah, i realize the limitations. i think i did try it with a slower phasor at first, but seemed to be getting compounded errors.
here's a revision that should keep going ok until you get float rounding errors. i remembered that [rpole~ 1] can be used as a sample-by-sample accumulator (thanks to maelstorm for the tip on that! really handy trick! see here: http://puredata.hurleur.com/sujet-6194-sample-played-automated-varying-speed-detect-completion ) the main dilemma here is that the patch runs at normal samplerate and bitrate. i think to get the sound close to the original code examples, you're going to have to somehow force the calculations all to be done with 8bit floats, rather than pd's internal 32 bit (or whatever) I still can't get my head around how to do that. On Tue, Oct 18, 2011 at 4:35 AM, martin brinkmann <m...@martin-brinkmann.de>wrote: > On 10/16/2011 02:31 PM, hardoff goes bananas wrote: > > further condensing of martin's patch: > > that is probably the most compact version (of course only if expr counts > as one object...) it sounds a little different from the message based > version though, but this is probably only a matter of tweaking the > "samplerate". and it repeats after 100(?) seconds, while the first > version should run for about a day. i have not tried to make the phasor > much slower yet. > > and my version sounds still different from the c/js version, though > quite similar. i think this might be caused by the type conversion > to char. > > bis denn! > martin > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
single_line_of_code_music-v.pd
Description: Binary data
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
