hi,
I know there's probably already a bunch of these out there,
but here's my take on grains...
I'm seeding the randoms by sampling the adc~, so the dsp should be on before you load the patch. There must be better ways to seed randoms. Any suggestions ?
gr,
Tim

http://www.pdpatchrepo.info/hurleur/grains.zip

a new contribution from Tim Vets. And a great one at that!

I particularly admire the effects that playing with grain_pitch_spread has (when everything else is set to reproduce the input as accurately as possible), but that's very likely because I love effects that still retain the original character. of the input.

So I found a couple of bugs (and didn't work on them since it's 3am here!)

Returning grain_pitch_spread to it's original setting (far left) doesn't make return the sound to its original sound. Pitch is correct, but there's some kind of new phasing/comb filtering.

on load, scatter's slider looks to be on the far left, although audio is still scattered.

various other tiddly bits.

The delay is wicked!!

Keeping the sound reminiscent of the original is the key here!

Here's the outcome of playing a sample of a slow melody + chords on the guitar through your grains synth:

sorry, here's the file...

okay, it's not uploading!

you tried to attach an mp3 file to a post? in that case you'll have to load the mp3 somwhere else and just attach the link here.

i did some minor mods on the gui to make it easier to see, and changed some of the sliders to 'jump on click'.

it's a beautiful sounding patch. really captures the graincloud effect so well. thanks for sharing!

http://www.pdpatchrepo.info/hurleur/GRAINS-guitweaks.pd

>>There must be better ways to seed randoms. Any suggestions ?<<

yes. every version of an abstraction will get a unique value which can be called by $0

so, instead of

[random 127]
|
[/ 127]

just do:

[random $0]
|
[/ $0]

i can finally tell you that because i found the subpatch containing the audio code. it was fairly well hidden. i reckon it's a good idea to leave that subpatch exposed so anyone can play with your code... unless of course you don't want them to,

hello,
thanks all for your replies and tweaks !
hardoff, I wonder if that can work. I tried it, but changing [/ 127] to [/ $0] will also affect what comes in from the sliders obviously...
maybe it can be solved by setting the slider to 0-1 range and adding

• right before it goes into the random object...something like that?
  also, doesn't $0 always start to count from the same value when pd is loaded ?
  i tested this with [loadbang] -- [f $0] -- [print] and i always get 1002 when loading that right after opening pd..

>>maybe it can be solved by setting the slider to 0-1 range and adding

• right before it goes into the random object...something like that?<<

yeah, sorry, i realized that after i posted. should have written another comment here, but i had made so many posts i was starting to feel shy. you are spot on. change the slider range to 0->1 and then multiply by $0. perfect.

>>also, doesn't $0 always start to count from the same value when pd is loaded ?

if you put your [loadbang] -- [f $0] -- [print] construction inside an abstraction, and then load several versions of that abstraction in a patch, the value will indeed be different for each version of the abstraction. $0 is unique for each PATCH opened, and in this case, abstractions are treated as seperate patches in their own right. it's perfectly fine for seeding random numbers.

new version with some more modifications:
-random seeding with $0, as suggested by hardoff
-'grab' and 'autograb' for live input grabbing
also, the graingen subpatch is now less well hidden

gr
Tim

http://www.pdpatchrepo.info/hurleur/GRAINS2.zip

it's not clear where grab takes it's input from? I always have my mic set up in [adc~ 6].

This is a great piece of work nonetheless. Thank you Tim

That delay is astounding

hi arif,
thanks
the input sits inside the 'loader' subpatch, by default it takes inputs 1 and 2
(its just [adc~] without any arguments)