@morpheu5 you could reduce the amount of oversampling, is there a reason for oversampling by a factor of 16? And you can [X] - switch~ off grains that are not playing..

@morpheu5 @whale-av is right, you need to get the grainSpeed into the clone as a modifier of the output of [vline~]. My comments from yesterday were not well thought out.
Spoiler: one way to do it grain.pd

@morpheu5 ...you could also use a counter instead of [next(, then retrigger the previous grain when you press a key. maybe that's the best option. sorry for the confusion, it's late over here

@morpheu5 i almost forgot [this( message to clone! check the helpfile, [this( + pitch should do the trick

@morpheu5 ...of cause, this would not stop the last grain playing at the wrong pitch. So you need to stop them all, then send the pitch value and retrigger metro....

edit: hope that's not too confusing

@morpheu5 i guess you get the wrong pitch because the grain is already playing when you press your key (i haven't tried the patch). You can send a trigger + pitch value to [clone] when you press the key with [next(. Right now you are sending the trigger to all grains simultaneously.

@morpheu5 you should send your grain pitch value as a second element in a list,
like [next $1 $2(

new version up! (v 0.4)

two new objects:

pp.parameq~ - a parametric equalizer.
fancy! I guess I pushed pd-UI design to the limits with this one:

pp.butterkreuz3~ - a 3 band crossover filter with a relatively flat magnitude response. Allows you to create multiband (well, 3 band) effects.

...many fixes, changes, additions... (sorry, I'm too lazy to keep track)

@hansr recording with writef~ is pretty safe actually. It runs in a subthread. It will not stop recording even if you stop dsp (it'll just pick up recording when you turn dsp on again) I just made a test on linux, turning dsp on and off, stopping the jack server and switching to ALSA and back to jack..., nothing could stop writesf~ from doing what it's supposed to do...
You can send a [print( message to writesf~ if you want to see what's going on.

One potential issue is documented in the help file; writesf~ needs some time between "stop" and "start" to flush the output to disk. What also happened to me sometimes is that I accidentally overwrote the file I just recorded. I take care of this with a patch that gives individual names to every next recording automatically.

@hansr why do you think this is necessary?
I record a lot with writesf~ and it never failed me. If it fails (for some reason other then exceeding memory) you should report this as a bug to the mailing list.