Hi,

I had a thought the other night as I was working on a large patch. I've recently been trying to improve my general programming skills, specifically PHP which I write a lot of at work, and part of that has been reading up on some of the standard Design Patterns that are in use.

It got me thinking, are there some useful, standard design patterns that can be applied to PD to help with large projects. Obviously PD is totally Object Oriented but in a different manner to most usual programming languages. dynamic creation of objects is possible but requires some amount of meta programming which can be tricky/clunky IMHO and it's not just a simple matter of passing references to objects around.

I'm planning to start writing up some blog posts with more of my thoughts, ideas and examples but i figured that it might be worth asking on here as to what people think. Are design patterns useful in PD? Is it worth trying to use existing design patterns in PD or is it just too different? Should I stop trying to involve the boring world of software engineering in the fun world of experimental music? tell me what you think

It is a topic worth discussing. In my experience most people programming in PD do not have a software engineering background and end up doing a lot of things that are frowned upon by software engineers, eg: unmaintainable copy-past code, always starting from scratch, monolithic code.

A the end of they day though we shouldn't just apply higher level SE principals just for the sake of it, it should be done to help us be more productive and efficient in writing our code. One thing that I've personally found useful is decoupling programing interface from implementation code. Basically I'll create an abstraction with an expected number of arguments and certain inlets and outlets for a doing a job and then several different abstractions for doing that job. As an example I'll create a compressor abstraction that is instantiated like this:

|
[compressor name ratio threshold attack release]
|

The guts of this object would look like this:

[inlet]
|
[$1Compressor $2 $3 $4 $5]
|
[outlet]

So in order to work there must exist in PD's path an patch called nameCompressor.pd. This patch would then hold the implementation details for a particular kind of compressor. The advantage of coding like this is that it allows your code to be modular. I can have a few different algorithms (linear, non-linear, with or without antialiasing, etc) but since the patches deal with them through the compressor abstraction it becomes very easy to plug them in and out of my existing projects without breaking anything. It also forces me to develop any future compression patch to work with this interface for the same reason, ease of using it with my existing projects.

The example I gave here is pretty trivial. When we start dealing with varied controllers (midi, keyboard/pointer, osc, netsend) the advantages become more obvious. You can create a new instrument (synthesizer, sampler, etc) and easily change the controlling device without having to directly change the code of the instrument itself precisely because the code that handles the input from the controller is decoupled from the patch that is using that input.

using abstraction arguments as part of the name for other abstractions is a pretty nifty idea. it's things like that that I want to document.

other things that I've been playing with are how to use dummy and "pass through" inlets and outlets to make routing messages to a subset of objects easier.