Hello all! This is my first time posting on this forum, so sorry if I did anything incorrectly.

I am trying to create a patch using modal synthesis, but I've noticed some odd behavior specifically with the sends and the bandpass filter I'm using. If I open up the clone and save it, the first time I send a bang I get a different sound from every other time I hit it. And oddly enough, I think that first time I hit it sounds better than all other times. I figure there's some under the hood processing that I'm not quite understanding. Could anyone explain to me how I can fix this issue?

Here's a quick explanation of the patch: Modal synthesis involves finding the most prominent harmonics, AKA modes, of an impulse and modeling how each one changes over time. I decided to model seven modes, so I set up three arrays with seven points. The first array sets which harmonic a given mode is on, between the first and 64th, the second sets the initial volume of each mode, and the third sets the amount of time it takes for each respective mode to decay in msec (following an attack/decay filter). The sound for each of the modes is currently a mix between an [osc~] and bandpassed noise with a very large Q.

Let me know what y'all think or if there's any other information needed.

Evelyn

modal synthesis_6.pd

mode.pd

@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

Hello @JoshuaACNewman ,

Yes, there's the autocompletion plug-in:
https://github.com/HenriAugusto/completion-plugin

And there's also a pd distribution used in the CEAMMC (Centre for Electroacoustic Music Moscow Conservatory) that comes with this feature as well as a toolbar and a big external library:
https://github.com/uliss/pure-data/releases

Even though it is still in beta, I would recommend Plug Data, it has auto-completion, has a dark theme, comes included with the else library and can be used as a DAW plug-in, although it uses different shortcuts than pd vanilla:
https://github.com/timothyschoen/PlugData

Two other projects I would recommend checking out:
https://www.automatonism.com/ - A modular synthesizer in Pd (you can actually click on buttons to create the modules instead of typing them)
http://malinette.info/en/? - programming interactivity toolkit.

I'm now curious about what software you could use to build this macro keyboard, let me know

@Matt-Stalcup

wavebypartialx10.zip

Sorry, it's taken me so long to get back with you.

1. re: $1,$0- that is there so you can route "from afar" from those tables (you'll see this in the x10 file I included in the zip. Harder to do if the array is $0.
2. the line makes sense. Thanks.
3. tabosc4~ good idea. The x10 uses an abstraction I built around the same time I did this, gensyn~ (generic synthesizer) which includes those as its double-osc (see https://forum.pdpatchrepo.info/topic/13099/gensyn-generic-multi-modulator-synthesizer-abstraction for more info).
4. the xysl has an object in it at the very top: [iemguts/receivecanvas] where the creation argument defines what level-up of parent you want the mouse to be active, i.e. which level of grandparent. The original xysl abs hardcodes it at 1, meaning only the parent patch will be allow it to move. I have included my modified version which only includes changed integers out and the depth as $6 creation argument. Seems to help with the performance issue. As the x10/gensyn~ runs at about 5-10% on my old-ish desktop.

I am thrilled you like the patch. Always good to know the work is helping out.

I made the x10 version for you to consider. The notion of routing different tables to different clones, doesn't make a lot sense, but it does show this will work even with a high number of (cloned) tabosc~s.

Thanks, again for you input and help in making it better.

Peace through Music.
Love thru Sharing.
-s

Highly appreciate your answers I guess it's hard to find one definitive answer but I feel better about my assumptions at least.
An additional detail in my case is that I almost exclusively use in-ear monitors, i think that could make a difference as they probably face all kinds of resistances in trying to pressurize the ear in one direction and the body of the earbud in the other. Much like closed back speaker cabinets vs open backs.. My Genelecs are banished from apartment use but I think I have to do a comparison next time I have some time over in the studio
I kind of wish I had some old synthesizer that could produce both directions of sawtooth waves to see how they compare in an oscilloscope.

@oid slew is such a powerful phenomenon that is quite new to me. I've found that incorporating slew distortion can really bring a digital synthesizer that extra bit towards that illusive analog warmth It's just hard finding data on it.. I've been working on a "ladder filter" that has some burn to it from just clipping but maybe the slewlimit of the transistors could be what it is lacking. Time to look up some datasheets i guess
And speaking of which, I recently modified Else's "slew~" to limit with a atan function instead of hardlimiting. It doesnt make a huge difference but I imagine it "softens" the effect a bit.. I'm still a bit new to coding for pure data so i'm sure there is some dead code in there and whatnot left from the original, i wasn't planning on sharing it really. But in case that sounds interesting I'll share the source: softslew~.c ((Inlet 2 or argument is "gain" and just multiplies the input + divides the output. Things start to happen at around 25 gain with unity level in..))

Goodnight

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.

G09.pitchshift.pd as I understand it is emulating an even older hat in audio tech, namely the rotary tape head pitch shifter. Explanation here: https://valhalladsp.com/2010/05/04/pitch-shifters-pre-digital/

It just so happens that this technique is a subset of what you can do with granular synthesis- and the digital implementation is using some of the same tricks as granular synthesis (splicing, window fading, etc). So your observation is correct in the same way as "A radio tuner is a filter".