PureData Patch - Voice Prism

Hi zynthianers,

I played around with pure data and created a patch which I was able to run on zynthian. With this patch you can “multiply” you voice (actually it can be any input signal) and set the resulting new voices to a certain pitch that is defined by MIDI notes.
Setting the pitch is done by convolution that is provided here.

Here is a really really little example of how it can be used:

As you can hear I’m not a professional singer :wink: nor am I a professional audio-processing expert. So I would be happy about your feedback or recommendations if you have any input for improvement. :slight_smile:

The patch as .zip file:
voice_prism_conv.zip (29.8 KB)

GitLab Project:

Thanks a lot for this great platform!


That sounds champion! I need an audio input!


Laurie Anderson, Oh Superman!

Ohhhh! This sounds really great … you are not a professional audio-processing expert, but your work seems quite pro, my friend :wink: Congratulations!!

If you agree, i would like to add your patch to the “official” zynthian library …


Hey @jofemodo , of course you can add the patch to the zynth library!

Jajaja! I assumed you would say “yes” and it’s already added … :relaxed:

BTW, i also added a little jewel, contributed by @ronsum, that i forgot to add:

OuterSpaceZynth by Ron Summers
Based on OuterSpace_V1 by Alberto Zin released under the Gnu Public License v. 2.0

Thanks @weichselbaumj & @ronsum!!

P.S: Of course, simply update and enjoy!!


By the way: are there any plans to update the pure data version? E.g. to purr data: https://agraef.github.io/purr-data/

Jonathan Wilkes’ Purr Data a.k.a. Pd-l2ork 2 is an improved version of Miller Puckette’s Pd . It is based on Ico Bukvic’s Pd-l2ork , which in turn is a fork of Hans-Christoph Steiner’s Pd-extended .

There are builds available for raspberry pi:

Install instruction e.g. for Raspbian 10 (Buster):

echo 'deb http://download.opensuse.org/repositories/home:/aggraef/Raspbian_10/ /' | sudo tee /etc/apt/sources.list.d/home:aggraef.list
curl -fsSL https://download.opensuse.org/repositories/home:aggraef/Raspbian_10/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home:aggraef.gpg > /dev/null
sudo apt update
sudo apt install purr-data

Stepping out from Vanilla should be discussed deeply …
We wouldn’t like to get trapped into a closed roadway, like the “extended” episode …
But i’m open to hear the arguments. of course. What’s the advantage, from a “zynthianic” POV of using Purr Data fork?


Oh, I didn’t know that there is something like a “extended” episode … what happened?

In my opinion there are two major advantages:

  • purr data is actively maintained and development is ongoing (last commit 2 days ago)
  • new modules that are not available in vanilla (e.g. “limiter~”, “triangle~”, etc., … I guess there are many more but I had to remove these two to make voice_prism running on zynthian)

As soon as I find the time, I will try to install purr-data on zynthian and I can report success/issues/failure if you are interested


the main issue is that L2Ork which Purr Data is based on, is a breaking variant of PD-vanilla. it may look cool visually, and has a few modules not available, but PurrData has exactly one maintainer and contributor - Jonathan Wilkes. since you’re using Linux on the Pi you could just build/run L2Ork actually, but i would have to say, if PurrData isn’t 100% compatble with L2Ork then you’re two branches away from PD proper and entirely beholden to Jonathan to update and support it.

the ‘extended’ reference that @jofemodo mentioned is a version of PD compiled by Hans Christoph-Steiner called PD-extended. it contained vanilla PD plus a lot of other objects and libraries making it more usable and friendly than vanilla PD was at the time. for a while (5 years or so) it was the preferred distribution with those just getting started in PD. but at least some of the objects/libraries introduced breaking changes compared to vanilla, and more importantly Hans got a full time job and had no more time to maintain the project and nobody else took up the challenge. so this left users wanting updates to PD-extended out on a limb with a dead and unsupported fork.

however there’s been some good news - the death of PD-extended spurred a lot of development in PD-vanilla and especially how it handles external objects and libraries, and they now have a pretty robust system for handling how to extend functionality in PD-vanilla called Deken - you can search for libraries and externals and easily install them and configure object search paths. additionally later versions of PD-vanilla have introduced a lot of useful objects, and last, even libraries of external objects that were falling into disuse like Cyclone (which brings in many MaxMSP objects and functionality to PD) now have new updates to bring them in line with the newest PD-vanilla versions.

L2ork is a pretty well known fork for PD but it’s wholly incompatible with PD-vanilla. Ivica the main developer of L2ork made a decisive break with PD-vanilla specifically for the students at Virginia tech for the laptop orchestra. Jonathan was a developer of PD getting dissatisfied with PD vanilla’s limitations at the time (in the dead time after PD-extended stopped being maintained) and so switched to L2ork as the base for a new, better looking version of PD called PurrData, that would run on Mac and Windows (L2ork only runs on Linux). so now you know the story, at least as much as i’ve pieced together over mailing list posts over the years.

so, the practical upshot is that if L2ork or PurrData was supported on Zynthian it would have to be as a completely separate library/path as PD-Vanilla and it are incompatible with each other. maybe not 100% but say 30%. furthermore if PurrData introduces objects or functionality NOT in L2ork, then you’re really branching out in a potentially dead area. one maintainer == risky bet. if it’s still 100% compatible with L2ork it may be useful to pursue it as a separate layer availble, but regardless it will not work with the existing PD layer, or to be more accurate it’s risky to do so because you’ll eventually get conflicts.

@weichselbaumj i would recommend seeing if you can get your patch to run in PD-vanilla. i might suggest you add the CEAMMC object library which has many externals that are useful. additionally you can try the ELSE library, although the maintainer of that likes the newest PD versions (not betas, i mean new releases) and these updates can break compatibility with older PD versions for certain objects. but i am nearly certain that externals are out there that can do what [triangle~] and [limiter~] can do. also PD-Vanilla is maintained by a few individuals and is updated fairly frequently - it’s not going anywhere unlike PD-extended which is dead. again having one maintainer and especially no contributors is not healthy.

anyway, that’s my rather long reply but as a user of PD who watched the saga unfold over the last decade i can see pitfalls in using forks, although as i said L2ork could be worth supporting.



Many thanks @metaphysician for your elaborated and detailed explanation. I think my PD picture is now much clearer and I agree with your arguments to stick with PD vanilla.

I also didn’t know that something like Deken exits and I’m already starting to like it. Again, thanks a lot!