@nicnut said:

@ddw_music
In the else library or Automatism theres some really good ones, but I haven't found any in Vanilla.

I wish I had found ELSE early on -- if I had, I might have gotten a much better impression. (It even has a copy of my favorite SC resonator, Ringz.ar <--> [resonant~].)

For fun, here's a 1-minute clip from my last show, a duo techno improvisation with my friend Neil on Digitakt (all drums are his) and myself live-coding SC (with the help of a custom dialect for patterns). I'm especially happy with the granular piano washes (the source notes come from VSTPlugin, which you also have in Pd as vstplugin~; granular processing + delays + reverb are all SC). 23-0324-hoodoo-jam-shorter-clip.mp3

@60hz

Don't forget to try https://ceammc.github.io/pd-help/,

Oh, I see, a complete alternate distribution. I had gotten discouraged when I tried to add the CEAMMC externals and found that (at that time) they didn't release them for Linux... but the alternate Pd does have a Linux version.

However, I guess I would have to build it myself, because I've adjusted some things so that the UI drives me slightly less batty. In particular, I loathe the way that dragging an object to reposition it enters edit mode -- but MSP feels that it's more important to be able to duplicate-move-type. Fine, whatever, he's wrong about that(+) but at least when I build from source I can fix it so that it works properly.

(+) Should be a user preference, but it isn't... if that weird UI decision is going to be imposed on everyone by force, then I reserve the right to be grumpy about it.

Anyway, the issue is not entirely about feature availability. It's also about workflow.

hjh

@KMETE I throw this at you until something better is posted....... Microsound-granular.pd .... which will happen.
The "smooth" anti-click part would be better done with a Hann window than the "duck" that is implemented and I am sure it can be improved/simplified.
It should be easy to understand and tailor to your requirements.
If you actually want granular synthesis there are good links here..... http://gerard.paresys.free.fr/Theme/Theme5.html
David.

@raynovich said:

And yeah, I kind of want to know more how it works. . .

Hm, well, let me propose an analogy. Analog synthesis is fairly standard: bandlimited waveforms, there are x number of ways to generate those, y number of filter implementations etc. But many of the oscillators and filters in, say, VCV Rack have a distinctive sound, because of the specific analog-emulation techniques and nonlinearities used per module. You can understand analog synthesis but that isn't enough to emulate a specific Rack module in Pd.

Re: Shuffling, I finally found this one sentence description: "Shuffling takes random sample fragments of variable dimensions from the last three seconds of the incoming sound and modulates its playback density and pitch" -- that's a granular delay.

A granular delay is fairly straightforward to implement in Pd: [delwrite~] is the grain source. Each grain is generated from [delread4~] where you can randomly choose the delay time, or sweep the delay time linearly to change the pitch. That will take care of "random sample fragments," "last three seconds," and "modulates... pitch" (you modulates playback density by controlling the rate at which grains are produced vs the duration of each grain -- normally I set an overlap parameter and grains-per-second, so that grain dur = overlap / grain_freq).

"... of variable dimensions" doesn't provide any useful technical detail.

But what isn't covered in the overview description of a granular delay is the precise connection between the Shuffling plug-in parameters and the audio processing. Since GRM Tools are closed-source, you would have to get hold of the plug-in and do a lot of tests (but if you have the plug-in, then just [vstplugin~] and done), or guess and you would end up with an effect that's somewhat like Shuffling, but maybe not exactly what the composer specified.

I'll send a grain-delay template a bit later, hang on.

hjh

Here's a fairly standard granular patch system made in "vanilla" Pd. Enjoy!
https://github.com/yannseznec/ys.granular

and here's a video tutorial that explains the patch:

@granular deken can be searched.

Edit: just remembered that searching for objects got added too deken in pd itself, just menu over to Help->Find Externals and type in the name of the object you are looking for and it will return a list of libraries which contain an object with that name for you to easily install.

@granular Try this vanilla replacement....... delta.zip
The external was, and probably still is in the maxlib library.
David.

I've been building some simple things and learning my way around PD vanilla. All in all it's a very nice system especially for free.

One thing that isn't working is creating windows for granular and FFT processing. I follow the exact patching from the tutorials that are included in the documentation. These things usually rely on "loadbang" for writing a single cycle of cosine to a table, buffer, etc. When I set this up I always still have to have to draw the table by hand. The filtering that I'm doing is working just fine, but I'm curious what I'm doing wrong. I've added a manual "bang" to write the table, calculate the size, etc, as well, but no luck. Usually I end up with nothing in the table.

I've had the same issue with granular synthesis. Even if I use a cos~ table that's offset and driven by a phasor~ I get clicks out the wahoo. This has happened even when just opening full patches that were made by the guy who wrote the software.

Anyhow. I'm finding workarounds for everything anyway, so hopefully things won't stay weird. It just seems like my system is acting screwy. I'm happy to try anything at this point as I'm looking forward to setting up my spare rPi as a standalone host for pd. Right now I'm just diddling around on my old 3930k windows 7 system so I don't get too carried away when I start trying to move things over to the Pi.

Thanks for any help,

JJ

@raynovich Loading a file into soundfiler takes time and so the table cannot be read correctly until it is written.
I don't really know what "granular" means for everyone, but made this Microsound-granular.pd a while ago, and it might help.
The file size stays the same and speed can be varied by a message to [phasor~] before [tabread4~].
It loads just one audio file and the arrays remain "whole"...... it is just the playback head that is moved and there is no "-resize" once it is loaded.
The playback head is moved all the time by a [metro] but before the move the sound is "ducked" by a message to [vline~] and then brought back up just after the move of the playback head to avoid clicks.

If you have lots of separate tracks loading with [soundfiler] you could join them together in one long track and access them by playback positions within the long track.
You will still have your problem though if you load a new audio file into the arrays and I don't know any way around that..... except that you could crossfade between old and new arrays once the new one has loaded..
David.

@Cmaj7 Maybe you should zip up your whole patch (without sound files) and upload it to this thread.
I think you have a problem we will not find without the whole picture.
But try this patch first....... Microsound-granular.pd ..... as it is also reading from arrays (onscreen) and softening crossovers with a short fade down and back up again (duck)....... and maybe your problem is not the speed of the duck but when the duck occurs........ it needs to start before the crossover and be at zero already at the crossover point.

So the crossover needs to be delayed slightly...... the duck needs to know it is about to happen a few milliseconds earlier...... 5ms in the above patch....... see the "granular" part in the middle.
The delay will not affect your musical timing noticeably...... 5ms is like moving 5 feet away from your speakers..... or being 5 feet from another player in the band.
David.

Yes but the point here being that digital granular synthesis does a lot of other things controlled by you: time stretching, jumbling up grains at your will, reverse playback and whatnot - the pitch shifter uses grains, delays and windows for one single purpose: shifting pitch

If you are doing a full fledged granular synth in PD the patch in question provides some basic technique,s but not as useful as you might think as it is designed for pitch shifting only. Pay attention to what @ddw_music told you in the other thread: https://forum.pdpatchrepo.info/topic/13489/realtime-detecting-lack-of-correct-delay-in-the-delay-object/11

Another note: Granular synthesis works with pre-recorded samples, whereas the pitch shifter is real time pitching