Patterns and predispositions
I have been working with Pd as the audio engine for my Android sequencer app. Â Learning about the language, I find my path to understanding it is a mixed route of functional learning mixed with theory. Â This blended approach to gain experience with it is the result of my passive-aggressive tendencies which produce a turbulent mix of theory and practical application. Â In my youth I was of the "learn the theory then start creating" school of thought, but the gradual slide into over-saturation of information has made me at times impatient and aggressive, seeking a quick payoff for a nominal investment of time.
How this relates to Pd is that instinctively I see it as an array of functionality more than a language, and not all of the constructs that exist in the visual programming environment are at the forefront of my decisions.  A prime example is that I am at the point where I have an idea of the sort of features that I require to accomplish the tasks in my next sprint, but to sketch this out I find myself wanting to go to a chart or mindmap, something at a macro level to define the flow and subsystem requirements.  Pd though not an object-oriented programming language has methods to service this.  I can create boxes and comments around elements, and I can define hierarchical patches simply by adding the pd statement inside of an object and giving the sub-patch a name.
For now I think that I still see Pd as a toolbox, not a machine shop or a draft board. Â To understand how to best interpret the language, I think it's just going to take more time working with matters at hand, and reading documentation as I go along.














