#1

Hi,
I’m a medium experienced programmer and 15 years ago I worked a lot with Reaktor.
I’ve decided to start studing an Open Source stable software that could give me the total freedom to do whatever I want on a Linux OS.

At the moment I will use it for my elcetronic Live, so I just have to control some samples with a midi controller (start some samples in loop, control the volume…), but I will probably have to do more things in the future.
So at the moment I will be using it intensively with midi controllers.

I’m very undecided whetever to start studyng Supercollider or Pure Data.

PROS
Pure Data seems to be more intuitive with its diagrams, therefore more pleasant in reading a project.
Supercollider on the other hand, I think easier to build complex project.

CONS
I think Pure Data can create a lot of confusion with all those objects when a project starts to be large and complex. And boring when you have to make a little complex logics.
Supercollider gives me the idea that it can be more boring in the construction phase of a project.

I’ve only watched a few videos and built a really simple project with these two software, so I know very little about them.
I remember when I was working on Reaktor, I was sometimes angry because, in order to build an easy logic flow, I had to waste a lot of time. Instead, writing code would be much easier and faster.
I thought the perfect solution for me might be software like Pure Data, but where there is an object where I could write high-level quick and easy code. I saw that there was an “Expr” function, which could do similar things, but from what little I saw it seemed very limited compared to what I would like.

Do you know more pros or cons that could me help to take a more correct decision?

1 Like
#2

I do like both and use them

With pure data you have a GUI (not the best one) from the start, in Supercollider you have to code your own.
Supercollider you can code quicker, since it is a typing environment, not diagram based. The help/documentation is also better i think.

I am more biased to Supercollider, but have some projects in PD which i don’t know how to replicate in Supercollider.

For your use case, i do believe it is achievable quite easily in both environments. (i do find loading a sample folder easy with Supercollider and not in PD, but that could be due to lack of knowledge)

3 Likes
#3

I much prefer SuperCollider for all the reasons mentioned. It also feels like it gets out of the way better than PD, if that makes sense. Virtual patching is just not my thing.

#4

I think the biggest advantage of PD is also its downside in another domain: The visual structure makes it very easy to understand signal flow (as long as you follow some best practices and encapsulate some objects). But it also makes it extremely hard to represent and work with data. For some simpler tasks, tables/arrays work well enough, but it can get very hard to represent more complex data structures in a way that you might want to interact with them.

Personally, I tend to prefer relatively simple patches that are driven by complex data more so than complex patches driven by simple data. So I prefer SuperCollider. But I could also totally see other workflows that make the visual patching more valuable.

I also find it much easier to refactor code in SuperCollider than to change things in PD/Max. Once a patch gets complex, it can be a daunting task to reorganize something. With SC, I don’t have that problem. Although that may also have to do with me being more used to working with code in text form.

4 Likes
#5

perhaps having a look at this wonderful youtube tutorial series by Eli Fieldsteel on supercollider will help you make your decision:

p.s.: i totally suck at coding but when i ran through this series i was able to quickstart doing simple stuff and learn some basics. i also like a lot his acoustic instruments + supercollider compositions you can find on his channel

5 Likes
#6

To basically echo what others have said: learn both. If you find one speaks to you more, go with it, but even though neither is my “daily driver” environment, I still use both of them.

PD can be great for prototyping certain ideas. SuperCollider often just sits like a service in my JACK ports acting as a stand-alone real-time feature detection dongle that feeds data elsewhere via osc…

It’s worth learning both! I’d say the same of ChucK, too… and there are lots of other great systems out there, it’s worth dabbling at least and not worrying too much about choosing The One. You’ll gravitate to something as your daily driver naturally… just try stuff out!

2 Likes
#7

I’ll echo what pretty much everyone else has said. Just about everything worth mentioning has been covered.

I use and love both, and while I started with PD and will always be a little biased in its favour, I also recognize that they each have different strengths (which other commenters have covered).

One thing I’ll add about Pure Data: it is (as others have said) absolutely true that PD doesn’t scale well, meaning as a patch gets more complex it becomes much more difficult to understand/debug by orders of magnitude. However, there is a silver lining to this: if you like a little chaos and crazy in your coding, PD can actually be really good for that.

It’s so trivial to route some signal/control data from one place to another within a patch. And then route it somewhere else. And then make some more connections. And then forget what you did. And then add in some more [receive] and [catch~] objects and randomly plop them in the patch… I like the idea that, kind of like with physical hardware, PD allows you to make those gut-based leaps of intuition. If you’re fluent with TUI and scripting then you can achieve the same sort of thing in Super Collider I think, but I would argue that this is something that GUI’s lend themselves toward especially well.

2 Likes