@qhr33k Thanks!

about this sidechain thing; yes you would need to feed the compressor an audio signal and use the sidechain output to let's say duck the tail of a reverb (that's just an example, you can do whatever you want with this). In this case you would multiply the 100% wet reverb with the signal from the sidechain outlet of the compressor like this:

sidechain_compression.pd

The presets are more or less didactic, you can use them as a starting point and then change the parameters until they fit your needs. In the case above you'd use the "compress" preset. I think what confuses you is the preset "Env.follow(sidechain)". This one is an envelope follower, the comment (sidechain) hints that the envelope is the signal from the sidechain outlet. Hope that makes sense?

Hi, it's been a while, here we go:

---

RELEASE NOTES:

Hi, it's been almost 8 months without an update and I never took this long!!! So there's a lot of new stuff to cover, because it's not like I've been just sleeping around

The reason for the delay is that I'm trying to pair up with the release cycles of PlugData and we're having trouble syncing up. PlugData 0.9.0 came out recently after a delay of 6 months and we couldn't really sync and pair up then... we had no luck in syncing for a new update now, so now I'm just releasing it up cause enough is enough, and hopefully in the next plugdata release we can sync and offer the same version.

As usual, the development pace is always quite busy and I'm just arbitrarily wrapping things up in the middle of adding more and more things that will just have to wait.

First, I had promised support for double precision. I made changes so we can build for it, but it's not really working yet when I uploaded to deken and tested it. So, next time?

And now for the biggest announcement: - I'm finally and officially releasing a new pack as a submodule, which is a set of abstractions inspired by EuroRack Modules, so I'm thinking of VCV like things but into the Pd paradigm. Some similar stuff has been made for Pd over the years, most notably and famously "Automatonism", but I'm really proud of what I'm offering. I'm not trying to pretend Pd is a modular rack and I'm taking advantage of being in Pd. I'm naming this submodule "Modular EuroRacks Dancing Along" (💩 M.E.R.D.A 💩) and I've been working on it for a year and a half now (amongst many other things I do). PlugData has been offering this for a while now, by the way. Not really fully in sync though.

MERDA modules are polyphonic, thanks to multichannel connections introduced in Pd 0.54! There are 20 modules so far and some are quite high level. I'm offering a PLAITS module based on the Mutable Instruments version. I have a 6-Op Phase Modulation module. A "Gendyn" module which is pretty cool. I'm also including an "extra" module that is not really quite a modular thing at all but fits well called "brane", which was a vanilla patch I first wrote like 15 years ago and is a cool granular live sampler and harmonizer. You'll also find the basics, like oscillators, filters, ADSR envelope and stuff I'm still working on. Lastly, a cool thing is that it has a nice presets system that still needs more work but is doing the job so far.

There are ideas and plans to add hundreds more MERDA modules, let's see when and if I can. People can collaborate and help me and create modules that follow the template by the way

Thanks to Tim Schoen, [play.file~] is now a compiled object instead of an abstraction and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS audio file extensions. A new [sfload] object can import these files into arrays (but still needs lots of more work). There are many other player objects in ELSE that can load and play samples but these don't yet support these new formats (hang in there for the next version update).

Tim also worked on new [pdlink] and [pdlink~] objects, which send control and signal data to/from Pd instances, versions and even forks of Pure Data (it's like [send]/[receive] and [send~]/[receive~], all you need is a symbol, no complicated network or OSC configuration!). And yes, it works via UDP between different computers on the same network. And hell yeah, [pdlink~] has multichannel connections support! By the way, you can also communicate to a [pd~] subprocess. This will be part of ELSE and PlugData of course, and will allow easy communication between PlugData and Pd-Vanilla for instance.

The great pd-lib-build system has been replaced for a 'cmake' build process called 'pd.build' by Pierre Guillot. This was supposed to simplify things. Also, the [sfont~] object was a nightmare to build and with several dependencies that was simply hell to manage, now we have a new and much simpler system and NO DEPENDENCIES AT ALL!!! Some very rare file formats with obscure and seldom sound file extensions may not work though... (and I don't care, most and the 'sane' ones will work). The object now also dumps all preset information with a new message and backwards compatibility broke a bit

I'm now back to offering a modified version of [pdlua] as part of ELSE, which has recently seen major upgrades by Tim to support graphics and signals! This is currently needed in ELSE to provide a new version of [circle] that needed to be rewritten in lua so it'd look the same in PlugData. Ideally I'd hope I could only offer compiled GUI objects, but... things are not ideal

The lua loader works by just loading the ELSE library, no need for anything "else". I'm not providing the actual [pdlua] and [pdluax] objects as they are not necessary, and this is basically the only modification. Since PlugData provides support for externals in lua, if you load ELSE you can make use of stuff made for PlugData with lua without the need to install [pdlua] in Pd-Vanilla.

For next, we're working on a [lua] object that will allow inline scripting and will also work for audio signals (again, wait for the next version)! Also for the next version, I'm saving Ben Wesch's nice 3d oscilloscope made in lua (it'll be called [scope3d~]). There's a lot going on with the lua development, which is very exciting.

As for more actual new objects I'm including, we have [vcf2~] and [damp.osc~]. The first is a complex one pole resonant filter that provides a damping oscillation for a ringing time you can set, the next is an oscillator based on it. There's also the new [velvet~] object, a cool and multichannel velvet noise generator that you can also adjust to morph into white noise.

I wasn't able to add multichannel capabilities to many existing objects in ELSE in this one, just a couple of them ([cosine~] and [pimp~]). Total number of objects that are multichannel aware now are: 92! This is almost a third of the number of audio objects in ELSE. I think that a bit over half might be a reasonably desired target. More multichannel support for existing objects to come in the next releases.

Total number of objects in the ELSE library is now 551!

As for the Live Electronics tutorial, as usual, there are new examples for new objects, and I made a good revision of the advanced filter section, where I added many examples to better explain how [slop~] works, with equivalent [fexpr~] implementations.

Total number of examples in the Live Electronics Tutorial is now 528!

There are more details of course, and breaking changes as usual, but these are the highlights! For a full changelog, check https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 (or below at this post).

As mentioned, unfortunately, ELSE RC12 is not yet fully merged, paired up and 100% synced in PlugData. PlugData is now at version 0.9.1, reaching the 1.0 version soon. Since ELSE is currently so tightly synced to the development of PlugData, the idea is to finally offer a final 1.0 version of ELSE when PlugData 1.0 is out. Hence, it's getting closer than ever Hopefully we will have a 100% synced ELSE/PlugData release when 0.9.2 is out (with a RC 13 maybe?).

Please support me on Patreon https://www.patreon.com/porres
You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/

cheers

ps. Binaries for mac/linux/windows are available via deken. I needed help for raspberry pi

---

CHANGELOG:

LIBRARY:

Breaking changes:

• [oscope~] renamed to [scope~]
• [plaits~] changed inlet order of modulation inputs and some method/flags name. If a MIDI pitch of 0 or less input is given, it becomes a '0hz'.
• [gbman~] changed signal output range, it is now filtered to remove DC and rescaled to a sane -1 to 1 audio range.
• [dust~] and [dust2~] go now up to the sample rate and become white noise (removed restriction that forced actual impulses, that is, no conscutive non zero values)
• [cmul~] object removed (this was only used in the old conv~ abstraction to try and reduce a bit the terrible CPU load)
• [findfile] object removed (use vanilla's [file which] now that it has been updated in Pd 0.55-0)
• [voices] swapped retrig modes 0 and 1, 'voices' renamed to 'n', now it always changes voice number by default as in [poly] (this was already happening unintentionally as a bug when one voice was already taken). The 'split' mode was removed (just use [route], will you?)
• [voices~] was also affected by changes in [voices] of course, such as 'voices' message being renamed to 'n'.
• [sr~]/[nyquist] changed output loading time to 'init' bang
• [sample~] object was significantly redesigned and lots of stuff changed, new messages and flags, added support for 64-bit audio files (Pd 0.55 in double precision and ELSE compiled for 64 bits is required for this). Info outlet now also outputs values for lenght in ms and bit depth.
• [sfont~] uses now a simpler build system and this might not load very very rare and unusual sound formats.

Enhancements/fixes/other changes:

• builds for double precision is now supposedly supported, by the way, the build system was changed from pd-lib-builder to pd.build by Pierre Guillot.
• [play.file~] is now a compiled object instead of an abstraction thanks to Tim Schoen, and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS file extensions.
• Support for double precision compilation was improved and should be working for all objects (not yet providing binaries and fully tested yet by the way).
• The ELSE binary now loads a modified version of [pdlua], but no [pdlua] and [pdluax] objects are provided.
• added signal to 2nd inlet of [rm~].
• fixed 'glide' message for [mono~].
• fixed [voices] consistency check bug in rightmost outlet and other minor bugs, added flags for 'n', 'steal' and offset.
• [gain~] and [gain2~] changed learn/forget shortcut
• [knob] fixed sending messages to 'empty' when it shouldn't, ignore nan/inf, prevent a tcl/tk error if lower and upper values are the same; added "learn/forget" messages and shortcut for a midi learn mechanism.
• [mpe.in] now outputs port number and you can select which port to listen to.
• Other MIDI in objects now deal with port number encoded to channel as native Pd objects. Objects affected are [midi.learn], [midi.in], [note.in], [ctl.in], [bend.in], [pgm.in], [touch.in] and [ptouch.in].
• [pi]/[e] now takes a value name argument.
• [sr~]/[nyquist~] take clicks now and a value name argument.
• fixed phase modulation issues with [impulse~] and [pimp~].
• [cosine~] fixed sync input.
• added multichannel features to [cosine~] and [pimp~].
• [plaits~] added a new 'transp' message and a functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]), fixed MIDI velocity.
• [pluck~] added a new functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]).
• 26 new objects, [velvet~], [vcf2~], [damp.osc~], [sfload], [pdlink] and [pdlink~], plus abstractions from a newly included submodule called "Modular Euro Racks Dancing Along" (M.E.R.D.A)! Warning, this is all just very very experimental still, the object are: [adsr.m~], [brane.m~], [chorus.m~], [delay.m~], [drive.m~], [flanger.m~], [gendyn.m~], [lfo.m~], [phaser.m~], [plaits.m~], [plate.rev.m~], [pluck.m~], [pm6.m~], [presets.m], [rm.m~], [seq8.m~], [sig.m~], [vca.m~], [vcf.m~] and [vco.m~] (6 of these are multichannel aware).

Objects count: total of 551 (307 signal objects [92 of which are MC aware] and 244 control objects)!

• 311 coded objects (203 signal objects / 108 control objects
• 240 abstractions (104 signal objects / 136 control objects)

---

TUTORIAL:

• New examples and revisions to add the new objects, features and breaking changes in ELSE.
• Added a couple of examples for network communication via FUDI and [pdlink]/[pdlink~]
• Section 36-Filters(Advanced) revised, added more examples and details on how [slop~] works.
• Total number of examples is now 528!

---

Last update:

QLab tech support reproduced the error in QLab but reported that it doesn't happen in Ableton Live. They also discovered the following workaround:

We found that it's possible to persist the settings for a QLab cue with
an extra step. After configuring the effect settings as you'd like them, 
save them as a user preset for that AU. Then load that user preset, and 
the configuration will persist even after stopping and reloading a cue, 
and after saving, closing, and reopening the workspace.

That sounds like what I did in that one case, and it makes sense because (duh) saving a preset saves the current patch state. Figure 53 (QLab's maker) doesn't have the resources to investigate further, so can't provide any more insight. @timothyschoen, would it be helpful I entered this issue into plugdata's github or is that redundant?

15 or so years ago I came across a vb script to extract a presets list from a soundfont2 file, which I adapted to use in various VB.net Fluidsynth projects.
Now that Pure Data has the file handle object to read binary files I decided to give it a go in Pd on Windows 10.
I have also tried it using linux and it seems to work with the latest portable version.
Edit: Thursday 22nd August 2024, I've just updated choose-sf2-example.pd in the zip because it was incorrectly wired an triggered
sf2-presets-reader.zip
contains:
sf2-presets-reader.pd to create soundfont.txt
choose-sf2-example.pd to launch choose-sf2.pd and show index, bank and name extraction from [r $0-chosen]
choose-sf2.pd
soundfont,txt contains the presets from a soundfont I use SGM-V2.01.sf2 (236MB), this will be overwritten with your choice.

My preferred soundfont player to use with Pure Data is RGC-Audio SFZ.dll or SFZ+.dll loaded in @spacechild1 very excellent vstplugin~

Other options are Qsynth via midiout
Fluidsynth,exe via midiout launched with motex/system

Warning Purr-Data will not open sf2-presets-reader.pd because it does not have the file object.

Method;
open the soundfont2 file;
then look for phdr by searching backwards;
one byte at a time from the end of the file and look for p;
then see if the remainder from route is hdr;
then forwards 38 bytes for each instrument preset;
to retrieve bank, index and name until EOP tag;
send to text: (bank as integer, index / 1000 added to bank) and name as symbol;
;
then sort in order:- text define [sort(;
;
next write the text to soundfont, txt;

Cheers
Balwyn

I'm having problems with a strange distortion sound a patch of mine is making, perhaps related to FFT processing.

The patch uses a preset system to change between settings. The system will mute the input to FFT objects during preset changes to avoid audio issues. However, when the preset changes I'm often getting a sort of distortion, which strangely clears up if I add & delete an object.

I've demonstrated it here:

My DAW is looping audio which is sent to PD for processing. The loop is on top of a preset change to demonstrate the issue.

Any clues as to what this could be?

Thank you both for further adding to this discussion! Sorry for not mentioning a use case earlier - I was considering to describe it in the question, but then decided to be lazy since I thought that the question remains the same.

So I actually have 2 use cases: One is related to a simple "preset management" experiment that is made of a central object managing the presets and little preset plugins that are cross-connected (output->input, input->output) to sliders or other value controlling objects. The "manager" needs to communicate with these and also store their names and values, of course. I didn't want to give them all unique names and also didn't want to give the "manager" all their names though. So currently, all these objects (including the managing object) get the $0 of the parent and then all relevant names are created based on it. The stored names of these plugin objects are created based on the parent's $0 combined with the difference between their $0 and the parent's $0. It's a bit of a mess, but it actually works quite well. Not sure if I managed to describe it in some understandable way. But since everything is based on just the parent's $0, it would be nice to omit that in the parameters and just access it from inside the abstractions.

The other use case I had in the past is abstractions that use cloned abstractions inside of them like [clone foo 16 $0]. Then all clone instances can be connected to the main abstraction's sends/receives/arrays etc. without collisions.

In the second case, it's not a problem at all, since it works well and is reasonably understandable. What bothers me in the first case though is that a user actually needs to write the $0 as a parameter for every object which is rather annoying. But then again, it's not a serious preset manager anyway and there's better stuff available already (I mainly checked out else's preset system so far) with a completely different approach.

Thanks, would it be possible to control file naming when using pdreceive from terminal to create a text file? Maybe trigger it from Pd, send a command to terminal? Or have a size or time limit and then auto-create a new file?

I was able to send text back to [qlist] using cat and have it play back again. I will rely on loading complete text files (into [qlist] or whatever), it is good enough. I will filter out repeated messages in the data stream before recording. This will make the files way lighter.

I need to read up on using bash/terminal. This is so smooth.

---

If I would like to have it streamed back to Pd I think I should write a python script that mimics qlist. But this is not really needed for me at this point.

Just for the record, the raw serial data (not filtered) is formatted like this :
(timestamp milliseconds | device | type of data | multiple sensors data):

10.024 a1 analog 565 565 565 565 565;
0.332 a1 analog 562 544 565 565 565;
6.606 a1 analog 565 565 565 565 565;
0.34 a1 analog 562 544 565 565 565;
12.482 a1 analog 565 565 565 565 565;
0.29 a1 analog 562 544 565 565 565;

---

@oid this is sweet! I managed to set this up and save a qlist readable file:

No cpu load, pd is stable after 1 hour recording, 18 mb file, all good. Using netsend seems great for recording a session in the background.

In order to make the transition from my [qlist] recorder smooth I figure I should try to be able to use terminal/pdsend to load the text file to [qlist]. How do I use pdsend in Terminal to send the recording5_pd.txt back to pd [qlist]?

Doing this...

jnl@nmbp ~ % /Applications/Pd-0.54-0.app/Contents/Resources/bin/pdsend 3000 >> recording5_pd.txt   
connected to 127.0.0.1

...I did not seem to get anything out of [netreceive] in Pd.

Is there documentation to be found on this somewhere?

@alexandros I would like to have to option to be able record the raw data so I can redo filtering at a later stage, but in most cases it would be better to filter out repeated messages, yes.
I am experimenting with having Pd detect silence and no interaction and then do offline non-realtime stuff (like saving, or using your neural network lib) at that point. But using [netsend] to save the sensor data at least eliminates the [qlist] save instability issue.

@seb-harmonik.ar [binfile] seems interesting, I may try that one down the line. Thanks!

I have a pretty large patch that stores settings in a bunch of tables and uses textfile and l2s (from zexy) objects to load and save presets. Loading is working fine, but the l2s in the save function has started adding a backslash to the names of settings. Does anyone know why this would be the case and how to stop it? I built this patch a few years back, and have been revising it to make it functional as an abstraction, but even loading the stable version I saved before I started the revision now has the backslash added when I use the save function, which completely breaks it. I know this wasn't the case before since I was able to save a number of presets using the subpatch when I first built the instrument a few years ago, and those presets still load fine.

I've attached a picture of the subpatch. Output from the print objects I added look like this:

d: list reverbBypass 0
e: symbol reverbBypass\ 0
ef: symbol reverbBypass\ 0
f: add reverbBypass\ 0
c: symbol reverbBypass
b: symbol reverbBypass
a: reverbBypass

and the saved file looks like this for that line: reverbBypass\ 0;

I also tried just building a little l2s thing without all of the file saving apparatus and I also get the backslash there. See the second picture, in which clicking on the bang gives this:

postl2s: symbol testing\ this\ motherfucker
prel2s: list testing this motherfucker

The l2s object's help file says its default delimiter is a space, which is how it worked fine for me in the past. But now I get this backslash in there. I've tried setting new delimiters but I can't figure out how to set it to be a space. Other delimiters like a . or a zero character delimiter work fine like the help file shows.

Any ideas on how to get this backslash to stop showing up?

Hi all,

I have a large patch with many layers of depth that's basically an imitation of old user-configurable synthesizers. Included is the ability to save presets, which is accomplished by writing values from all "send" objects to a text file, which can be read later (e.g. filter adsr, vibrato/tremolo frequency and depth, ring mod, etc.)

The challenge I'm encountering is simply that it's cumbersome to add each new "variable" to the logic that writes and reads these presets, and as the number of variables increases, so too does the difficulty associated with debugging the preset function.

Is there a way to get a list (in common sense of the word, not necessarily the pd object sense) of all send symbols used in a patch and all of its subpatches? To get such a list in the context of the patch itself would be most useful, but even a trick outside of pd that would grab all of the names from the patch's source code would help.

Thanks in advance!
charlie