[PD] triggering samphold~ to trigger phasor~

[derek holzer]

Hi Spencer,

DSP loops can be avoided by using send~/receive~ pairs. I posted a fix 
for this problem a while ago if you search the archives for "DSP loop". 
There you'll get the whole story.

I'm having a bit of a hard time figuring out what you want the [phasor~] 
to be doing in this case, but the way I've done this in the past is to 
use many [delread~] objects, each one representing a different "voice" 
in the granulator (a la MIDI polyphony). The I use a sort of "asynch 
filter" to let the output of these different [delread~] through, or 
[switch~] to turn each voice on or off (where each voice has a number, X 
is the number of voices and all voices with a number above X are 
switched off). The actual reading of the [delread~] isn't driven by 
[phasor~] at all, just by sending it numbers which represent the 
readpoint in the delay. Maybe it's hard to explain without sending along 
a patch... but the basic idea is the same as Particle Chamber, except 
that instead of reading from a table, you are reading from a delay line. 
(I know I keep promising to post it, and I think I have some time this 
upcoming week to clean it up for release... really!)

d.

Spencer Russell wrote:
> I'm working on a granulator using vd~, and I want 
> to have a randomization factor for the grain density.
> I'm using a scheduling phasor, and a samphold to
> control the delay time to avoid the doppler-type
> effect, so I'd like to do the same sort of thing for
> the frequency of the phasor, but when I run the output
> of the phasor to the samphold, and then run the output of the samphold back to the phasor(sampling noise), I get DSP loops and a segfault. Is there a better way to do this?


-- 
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 205:
"First work alone, then work in unusual pairs."