it works just fine i made a few examples

5 Likes

As someone who messed about with pd a bit past, is there any central resource for news on whats being done with it nowadays ?

Used to look on puredata.info but the last news entry on there is from 2017 making the whole scene look a bit dead.

I eventually learnt about Automationism, Purr-data, and a bunch of hardware that’s patchable with it now (both eurorack modules, and guitar pedals) from sites covering said hardware.

1 Like

well pd-extended stopped being supported and it moved to a deken external manager deal a while ago.
Gem is old but ofelia wraps all of Open frameworks in for graphics
Pd works in/on almost everything --even norns with a little work
i use it for organelle making patches that do something very well and can be loaded onto a device
sampling drums etc…
it’s certainly not dead

as always it’s available at
http://msp.ucsd.edu/

4 Likes

Oh no, I didn’t mean to imply the software itself died, just that Iost all sight of what people are doing with it.

Thank you for mentioning ofelia in your catch up, I had no idea that was out there.

I’m curious about this too. Pd was my primary way of making music for quite a while but I haven’t really been up on what’s new with it lately.

That being said, the places I used to follow were the PUREDATA forum~ and the Pd mailing lists. Particularly the pd-list, pd-dev, and pd-announce lists.

I’m not sure if there are any better resources in 2020, but these ones are at least still somewhat active.

1 Like

i run a facebook group dedicated to advanced pd synthesis
it requires that folks share patches :slight_smile:
theres a few quite active groups beyond that too on FB

pp

For people who use Automatonism:

Do you do much integration of Automatonism objects with other pd objects? I have dabbled a little, especially with midi objects, but they don’t always seem to connect properly. Eg the program won’t let me connect an output to an input, or bangs won’t trigger an autom module.

I don’t know if this is due to my extremely limited pd knowledge or if there is something particular I should be doing to connect autom with non-autom objects.

(I’m not a pd expert either) you have to convert the data types in many cases to make things work. There’s always a way to do it somehow.

1 Like

Hmmmmm, I’ll do some digging around. Thanks!

There is a section on this in the manual/help file of Automatonism. All connections work at signal rate so you have to convert bangs into signal and signal into discrete values using something like the snapshot object. They provide examples of this that you can just copy into the main patch.

3 Likes

I’ve found this in the help file now. I’ve looked at this before but clearly wasn’t implementing it correctly yet, will try again, thanks for the added context!

Looking for some advice/ideas on something…I’m trying to make a patch that will tell me the rate of change of a variable. The scenario is that I have an endless encoder (which will be attached to a jog wheel of some sort eventually) and I need to calculate how fast it is being turned.

I’ve been trying all sorts this afternoon with no luck so I’m hoping someone might be able to point me in the right direction!

a thing: grains~

grains~ is a granular synth engine for puredata. it supports all your usual granular parameters, which are set per-grain and optionally subjected to built-in randomization with some light probability controls. alternatively, you can prepare and fire grains individually.

grains~ is documented primarily in the readme and comes with a few examples.

grains~ itself is a set of abstractions which run in pd vanilla without any dependencies. the examples and the help patch need cyclone and iemlib (if you run purr-data you already have these) as well as my own set of abstractions (here, needed primarily for a circular buffer for the granular delay example).

please let me know what you create with it (and if it gives you any trouble)!

16 Likes

Could anyone walk me through how to make PureData and Crow talk to each other? Warning, I am a enthusiastic novice.

1 Like

Is there a consensus on pd flavour to use nowadays? Or is vanilla the way to go? I’ve seen pd-extended mentioned in tutorials, but that’s apparently dead, purr-data seems like a continuation in a sense?

most (in my pod) are in favor of vanilla, with a few external libraries (eg. zexy, else, cyclone, etc.). pd-extended is dead. i know only very few who are actively using purr data. you may want to cross post to the (useful) facebook users group, and (messy, but no less informative) discord users group.

latest full is - i believe - pd-0.51-2, and miller has posted a test of …-3 on his ucsd page.

1 Like

try to forget pd-extended unless you have something that only works with it and there is almost always a replacement for whatever you could imagine use Vanilla if you are just starting :slight_smile:

I guess I’m in the minority who use purr-data as a main. My thoughts:

  • the interface is the main attraction, it’s a huge QOL improvement for long patching sessions
  • second attraction is speed of setup, since like extended it comes with a pile of externals
  • drawback to the nicer interface is that it’s a little heavier, so rapid things like scopes and such sometimes interrupt audio
  • pd version that purr is based on is generally a little behind
  • also no deken for some reason
  • also some bugs, particularly with cyclone helpfiles, but the devs are active

You could have both installed and use purr only for developing and vanilla for performing — I’m set up to do this but in practice just use purr for everything since the drawbacks are minor to me. ymmv!

2 Likes

There’s no reason not to install both Vanilla and Purr-Data and try them both out. When I started out with PD, I was a devotee of extended. Then I took a break for a few years, and when I came back, extended was dead and I discovered that many of my patches weren’t working well out of the box in Vanilla or Purr-Data. Since then I’ve made an effort to do all my work in Vanilla, and to be very intentional about when I install externals.

For embedded/headless use-cases, vanilla may also be preferable–I’ve never looked into doing any headless pd work with Purr-Data, so maybe I’m wrong on that, but my understanding has been that libpd is a vanilla-only thing.

I think Purr-Data is wonderful for its GUI and other quality of life improvements, and there is no reason not to use it and even work primarily within it. But I would keep an install of vanilla on hand, at least, and maybe keep track of any externals you rely on, so that if you do ever need to fall back to vanilla, you’ll be able to minimize the pains.

Thank you for all the answers! :slight_smile:

I am just learning for now, mostly out of curiosity, want to go through Johannes Kreidler’s book and then we’ll see. So I guess I’ll start with vanilla and will try out purr-data later if vanilla’s GUI annoys me or something.

1 Like