#333

maybe bugs in a more strict sense isn’t the right word, mostly because I am not in the position to determine if something really is a bug, or something else.
My experience with it is really more or less what @barnaby described. Plus often I do something and Pd crashes, or locks up. I had most issues with working with tables and tabread(4)~. Pd is not very efficient in how it uses your computer’s resources, and only runs on a single core (except if you use pd~, but I haven’t been able to make that work for me yet), so I guess my issues could also be related to the fact that I’m pushing Pd a bit too much. There’s little things you figure out with time, like for eg. that you shouldn’t send float numbers to [bob~]'s cutoff inlet, or it will use much more CPU…
Also, I should add that most of my frustration comes from trying to use Pd on an Rpi / Pisound system. Most patches I’ve made on macOS work fine and did give me little issues.
But I’m not here to complain about Pd, in general I think it’s a great piece of software and I’m really glad it exists. I mostly am considering the possibility that I just need to change my attitude towards it.

I think that’s a good way to use it. I need to prevent myselt to get into obsession mode and just use it when I actually feel motivated to do so.

I’m trying to do that. I’ve started to convert some patches from the Organelle to Pisound, which is a great example to see how other people approach things but in a more goal-oriented way.
The issue is that I don’t always have enough Pd knowledge to understand if the patch is well made or not… and hence if I should learn from its success or failure :slight_smile:

3 Likes
#334

I think PD is like many programming languages, it takes a little while to find a way that it works for you.

in many ways PD is quite simple (if you don’t start adding lots of external), as its got quite a limited set of objects, so once you get the flow concept, things start to fall in place. (for me at least)

(I think if you start using lots of 3rd party externals that makes the learning curve steeper in some ways, too many options, and inconsistencies)

initially for me (as a C++ developer) I found PD’s whole flow/visual side really clumsy,
but in fairness, Id tried Max a while back, and had the same experience (despite it being better implemented and having ‘debug support’) , but then because I preserved, I started to appreciate its immediacy.

thats said, I prefer using it as a ‘glue’ , so doing anything more complex in C++, and just expose it as an PD external (which are surprisingly easy to create)

learning by doing its the only way :slight_smile:

having converted most of C&Gs Organelle patches to Oracs modules, Id say the majority are well written (or at least easy to understand) , and as you say introduce you along the way to some slightly more advanced topics, so its a good exercise… (not sure about 3rd party organelle patches, as not looked at them)

btw: a good proportion of the C&G Organelle patches are within Orac, and Im releasing this soon on the Rasperry PI very soon.

finally… I found with PD, the whole user interface (in broad sense, not GUI) was really time-consuming/frustrating, and thats why I built mec-kontrol (which orac is based on) - you might find this interesting if you need things like patch parameters/midi mapping/preset recall.
(you can find a few videos showing Orac/Mec on my youtube channel )

1 Like
#335

FWIW. I’ve found Pd Vanilla to be stable (close to bug-free) for my own uses. I dont use many of its GUI facilities though.

1 Like
#336

Yeah I guess that’s another point. Or one can know what it should do and then figure out if it does. After all, why bother if it doesn’t not take you anywhere near what you want to achieve artistically? I mean it can be fun and an interesting learning process, but there’s so many things that are fun and an interesting learning process as well.
This said, I see many things where Pd can work for me, and yes learning by doing is the way for sure.

@barnaby: I thought you were talking about Organelle patches in general but now I got it that you mean the official ones. I’ll definitely look at those again! Thanks for the tip!

#337

well thats a huge topic in itself… artistic endeavour is not the only reason to keep out brains active learning things :slight_smile:

I say this a bit tongue in cheek, but actually its something I ‘struggle’ with quite a bit - the balance of what I’m doing for musical purposes, and for technical creativity… neither is better/more ‘noble’ in my mind, but down to the balance I want to have at a particular point in time.

1 Like
#338

I saw this article on CDM today:

It was very easy to set up. I had no idea that Pd added a package manager since the last time I tried it out. I was also surprised to see that the manual and interactive tutorials are very high quality.

2 Likes
#339

Looks like it has really grown up over the last year!

#340

Nice! Feel free to fold this into the main Pd thread if you think that it belongs there.

#341

Just jumping into this thread as a max person real quick.

Some of these modular systems look really interesting, I didn’t really know about anything beyond Automationism. Has anyone had any luck combining multiple graphical patching system type things? I’m curious if theres like a loose signal standard that systems are following which could let them hook into each other, like midi messages or just 0-1 signals and floats.

I’m developing a modular environment in max right now (very slowly) that’ll sort of just be sitting in isolation (since there doesn’t seem to be many other modular-type systems in MAX other than BEAP) but it would be cool to be able to interface my system with other people’s systems, kinda like, you know, eurorack. I’ve wanted this for a while, curious if Pd could be a platform for that kind of thing (I’ve though about building my own, but, you know, big endeavor).

#342

Yeah, my (getting dusty) memory of Automatism is that it plays very nicely with ordinary Pd patches, you can wire things to and from it as if it were any other patcher. I believe the story is similar for Context. I do vaguely remember using Context and Automatism together at some point.

Hope I’m not making that memory up! It’s been a year.

#343

Organelle mother patch for the computer (so, Organelle without an Organelle).

(edit: it appears it’s old stuff but I had never seen it)

1 Like
#344

well, BEAP, as you probably know, makes the curious choice to implement the “volt”/octave standard AND to have almost everything be a signal. I dunno if that’s a route you feel like extending.

1 Like
#345

Why is it a strange choice ?

#346

well, in the context of teaching students (Eurorack) modular synthesis it makes a lot of sense, but it also (needlessly) adds performance overhead calculating control-rate changes for every vector and sometimes introduces double conversions when the underlying objects are prepared to talk to each other using another standard.

philosophically it also kind of obscures a potential benefit of Max over a hardware modular: hardware modulars are striving to allow users flexible, reconfigurable access to fairly general kinds of signals so that the user can do the best with their necessarily limited number of modules. In Max you do not have this limit, so maybe all your 250 “oscillators” shouldn’t have individual knobs.

I don’t wanna knock BEAP too hard though – it is a great collection of tools I’m glad to have and be able to take apart

2 Likes
#347

I like that everything is a signal (keeps thing in sync), I don’t like that control signals are in a 0-5 range (if I remember correctly). complicates using the modules with standard max objects imo. 0-1 for signals and 1 float -per-octave seems like the best way to go. (both of these also have the disadvantage that no connection = a 0 value. For this reason I’m actually building a system right now that communicates using signals in the 1-2 range, with a 0 equivalent to null, because my modules needed to know when a cable was connected to an inlet)

What I REALLY like are systems that implement polyphony/dimensionality in patch connections. I believe @audulus and oscillot do this. Working with a standard like this can quickly bring a digital system beyond what hardware is capable of doing in addition to cleaning up polyphonic patches.

A lot of digital modular stuff seems to be bowing to hardware modular for design choices and integration which is unfortunate because I feel like digital patching can do so much more if the design is considered in isolation.

4 Likes
Audulus (thread)
#348

2 posts were merged into an existing topic: Audulus (thread)

#349

Just moved the Audulus-related posts to the new main Audulus topic which you can find here: Audulus (thread)

As for general discussion about virtual modulars, BEAP, etc. maybe consider creating a new topic so we can keep this one about Puredata, without derailing it too much all the time.

#350

Ok so I am starting a Pd patch on boot via rj.local.

It is triggering a script that launches:

sleep 5
sudo pd -nogui destination of the patch/main.pd &

My problem is that it is not choosing the right soundcard. It always goes back to the built in one.

If I write speaker-test that sound comes out of the right soundcard but not pd.

BUT if i type sudo pd -nogui destination of the patch & manually in the terminal everything works like I want.

Can anyone help me out?

#351

pd -nogui -listdev
pd -nogui -audiodev …

#352

Aight so listdev shoes the one I want as iten number three on both input and output.