@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

@20har I suspect others know better than I, but haven't responded.

This is one way to test:

22-0721-realtime.pd

On my system, I observe jitter in "realtime" on the order of about 5 ms. This holds true at shorter intervals -- if I move the slider to 6 or 7 ms, I see the realtime number jumping between 5 and 10 ms (error within 5 ms, then).

I tried two different audio hardware buffer sizes, same behavior.

Up to 5 ms timing jitter doesn't seem very nice.

To sync with Ableton, I would use the abl_link~ external instead.

hjh

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.

Hello, I have some very basic questions about Camomile.

Following the documentation, I have successfully loaded AlmondOrgan into my DAW (Cakewalk by Bandlab). I copied Camomile.vst3 from the Camomile folder to the AlmondOrgan folder, changed the file's name to AlmondOrgan.vst3, and copied the AlmondOrgan folder from the Examples folder to C:/Users/Program Files/Common Files/VST3, and Cakewalk then found and loaded the patch. I also got MiniMock to work using the same process.

However, I cannot get a Pure Data patch other than the patches in the Examples folder to work. I have been following a YouTube series showing the development of a Pure Data synthesizer, and wanted to load that synthesizer into Cakewalk. I downloaded and unzipped the zip file (it is the final version, lesson_16.zip, on this website: http://lwmmusic.com/learning-lswpd-1.html), copied Camomile.vst3 from the Camomile folder to the lwm_fam2_synthesizer folder (which is what's inside the lesson_16 download), changed the file's name to lwm_fam2_synthesizer.vst3, and copied the lwm_fam2_synthesizer folder to C:/Users/Program Files/Common Files/VST3. When I then try to use the synthesizer in Cakewalk, the GUI is replaced with a "Plugin Not Valid" message, and the console warns that Camomile can't find configuration files. I also tried the same process except renaming the Camomile.vst3 file as modules.vst3 (corresponding to modules.pd, the name of the synthesizer file), with the same erroneous result. I am unable to determine how much, if any, of the "How to create new plugins" page of the documentation applies here. It's just a bit too much technicality without context for me to understand what parts of it are required just to get going and what parts are customization options.

My first question is, are patches created using Camomile itself, or are they created independently using Pure Data, with Camomile being applied to them only after they are already created? In other words, do I need to copy the contents of the downloaded synthesizer files and paste them into new Camomile patches?

My second question is, what other steps are required to load the downloaded synthesizer files into Cakewalk using Camomile?

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

@raynovich said:

When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

Avoiding clicks in granular synthesis is mainly a matter of applying a windowing envelope to every grain. If every grain ramps up from silence and back down to silence, then there is never a sudden transition.

Just the other week, I demonstrated in a class a way to do that: each grain runs a line~ from 0 to 1 and this splits to two places:

1. Map this normalized range onto the desired range of samples to pay back, and tabread4~ the source.

2. Map the normalized range onto another table containing a Hann window, and tabread4~ that.

3. Multiply, and... a clean, windowed grain.

hjh

hjh

@jameslo Sorry for the confusion. I am not the well-versed in the language to be clear. When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.