Does anyone use flowcharts while creating of/thinking through their

patch logic flow? I personally find they really help me think through

the steps of program logic needed before/while I sit down and write

the entire patch. I'm not a seasoned programmer, outside of javascript

and a few other web languages so I'm interested to find out if these

Does anyone use flowcharts while creating of/thinking through their
patch logic flow? I personally find they really help me think through
the steps of program logic needed before/while I sit down and write
the entire patch. I'm not a seasoned programmer, outside of javascript
and a few other web languages so I'm interested to find out if these
are a common programming step or not.


logic-flowcharting

> Does anyone use flowcharts while creating of/thinking through their

I don't use flowcharts, but I do think about designs before I 

implement. Sometimes on complicated patches, I'll stub it out with 

subpatchers to try and get a better handle on conceptual chunks before 

I start coding. It helps me envision how data will flow through a 

On Jul 1, 2008, at 4:51 PM, Wade wrote:
> Does anyone use flowcharts while creating of/thinking through their
> patch logic flow?

I don't use flowcharts, but I do think about designs before I  
implement. Sometimes on complicated patches, I'll stub it out with  
subpatchers to try and get a better handle on conceptual chunks before  
I start coding. It helps me envision how data will flow through a  
patcher sometimes.

Chris Muir
cbm@well.com	
http://www.xfade.com

I concur. I generally think longer about how to do something than I 

I don't generally write anything down, but thats just because I'm bad 

at writing things down. I probably should, but I just don't.

Plus, by its nature Max is almost making a flow chart in itself.

On Jul 1, 2008, at 8:47 PM, Chris Muir wrote:

> On Jul 1, 2008, at 4:51 PM, Wade wrote:

>> Does anyone use flowcharts while creating of/thinking through their

> I don't use flowcharts, but I do think about designs before I 

> implement. Sometimes on complicated patches, I'll stub it out with 

> subpatchers to try and get a better handle on conceptual chunks 

> before I start coding. It helps me envision how data will flow 

I concur.  I generally think longer about how to do something than I  
actually do coding it.

I don't generally write anything down, but thats just because I'm bad  
at writing things down.  I probably should, but I just don't.

On Jul 1, 2008, at 8:47 PM, Chris Muir wrote:
>
> On Jul 1, 2008, at 4:51 PM, Wade wrote:
>> Does anyone use flowcharts while creating of/thinking through their
>> patch logic flow?
>
> I don't use flowcharts, but I do think about designs before I  
> implement. Sometimes on complicated patches, I'll stub it out with  
> subpatchers to try and get a better handle on conceptual chunks  
> before I start coding. It helps me envision how data will flow  
> through a patcher sometimes.


I think that it is near essential , specially for more complex patches , you will save time .

even through my still short experience with MAX I have encounterd sitiuations where 'new ideas' where poping up while coding , and these new ideas would tend to me re-organise my patch accordingly , often slowing me down .

So I learnt my lesson !!!!! and to be honest with you I really do enjoy it !

So you create a few blank patcher boxes and hook them up to get a

On Tue, Jul 1, 2008 at 11:47 PM, Chris Muir wrote:

> I'll stub it out with subpatchers to try

> and get a better handle on conceptual chunks before I start coding. It helps

> me envision how data will flow through a patcher sometimes.

So you create a few blank patcher boxes and hook them up to get a
visual idea of the flow?

On Tue, Jul 1, 2008 at 11:47 PM, Chris Muir  wrote:
>
> I'll stub it out with subpatchers to try
> and get a better handle on conceptual chunks before I start coding. It helps
> me envision how data will flow through a patcher sometimes.


> So you create a few blank patcher boxes and hook them up to get a

At the very least these are well named empty patchers. Often these 

"empty" patchers will get named inlets and outlets.

This makes me consider the signal and control flow, as well as what 

To be honest, it's been a long time since I approached a design this 

way. I still spend time designing in my head before I start coding, 

On Jul 2, 2008, at 6:54 AM, Wade wrote:
> So you create a few blank patcher boxes and hook them up to get a
> visual idea of the flow?

At the very least these are well named empty patchers. Often these  
"empty" patchers will get named inlets and outlets.

This makes me consider the signal and control flow, as well as what  
makes sense as a functional block.

To be honest, it's been a long time since I approached a design this  
way. I still spend time designing in my head before I start coding,  
though.

I expect that you'll find that the insight about slow preparation/fast execution [to quote the Oblique Strategies] is an emergent feature of actually developing a relationship to Max (as opposed to the "play" associated with newbie random repatching, which is probably the soil which nurtures the insight if/when it germinates).

Right, right. Thanks for describing. I generally write down a logic

flow only when I need to simplify in order to avoid wasting time

guessing what objects to use. Also as Gregory said in order to have a

hot relationship with Max, it seems necessary at the early stages at

On Wed, Jul 2, 2008 at 1:00 PM, Chris Muir wrote:

> At the very least these are well named empty patchers. Often these "empty"

> patchers will get named inlets and outlets.

> This makes me consider the signal and control flow, as well as what makes

> To be honest, it's been a long time since I approached a design this way. I

> still spend time designing in my head before I start coding, though.

Right, right. Thanks for describing. I generally write down a logic
flow only when I need to simplify in order to avoid wasting time
guessing what objects to use. Also as Gregory said in order to have a
hot relationship with Max, it seems necessary at the early stages at
least.

On Wed, Jul 2, 2008 at 1:00 PM, Chris Muir  wrote:

> At the very least these are well named empty patchers. Often these "empty"
> patchers will get named inlets and outlets.
>
> This makes me consider the signal and control flow, as well as what makes
> sense as a functional block.
>
> To be honest, it's been a long time since I approached a design this way. I
> still spend time designing in my head before I start coding, though.


I almost never plan a patch until its nearly finished and it requires a plan to move forward. Instead I prefer to work methodically and play around a lot, and then find ways to make it work properly. If anything, I start with a vague concept of some effect, mood, sound or process that I'd like to try. Usually it is centered around a specific control source and making things that work with that in fulfilling ways. The only time I write anything down like a plan is when I am at a beach or the park away from my computer, and I imagine a way to solve something.

"When you make a thing, a thing that is new, it is so complicated making it that it is bound to be ugly. But those that make it after you, they don't have to worry about making it. And they can make it pretty, and so everybody can like it when others make it after you."

I almost never plan a patch until its nearly finished and it requires a plan to move forward.  Instead I prefer to work methodically and play around a lot, and then find ways to make it work properly.  If anything, I start with a vague concept of some effect, mood, sound or process that I'd like to try. Usually it is centered around a specific control source and making things that work with that in fulfilling ways.  The only time I write anything down like a plan is when I am at a beach or the park away from my computer, and I imagine a way to solve something.  

True, often you throw the first two away.

I think my perspective on it comes from making things for other people 

a lot. The original intent is usually very clear.

On Jul 2, 2008, at 11:05 AM, Andrew Benson wrote:

> I almost never plan a patch until its nearly finished and it 

> requires a plan to move forward. Instead I prefer to work 

> methodically and play around a lot, and then find ways to make it 

> work properly. If anything, I start with a vague concept of some 

> effect, mood, sound or process that I'd like to try. Usually it is 

> centered around a specific control source and making things that 

> work with that in fulfilling ways. The only time I write anything 

> down like a plan is when I am at a beach or the park away from my 

> computer, and I imagine a way to solve something.

> "When you make a thing, a thing that is new, it is so complicated 

> making it that it is bound to be ugly. But those that make it after 

> you, they don't have to worry about making it. And they can make it 

> pretty, and so everybody can like it when others make it after you."

I think my perspective on it comes from making things for other people  
a lot.  The original intent is usually very clear.

>
> I almost never plan a patch until its nearly finished and it  
> requires a plan to move forward.  Instead I prefer to work  
> methodically and play around a lot, and then find ways to make it  
> work properly.  If anything, I start with a vague concept of some  
> effect, mood, sound or process that I'd like to try. Usually it is  
> centered around a specific control source and making things that  
> work with that in fulfilling ways.  The only time I write anything  
> down like a plan is when I am at a beach or the park away from my  
> computer, and I imagine a way to solve something.
>
> Andrew B.
>
> "When you make a thing, a thing that is new, it is so complicated  
> making it that it is bound to be ugly. But those that make it after  
> you, they don't have to worry about making it. And they can make it  
> pretty, and so everybody can like it when others make it after you."
>
> --Pablo Picasso


Max programming is an exploratory process for me. Often I don't really know what it is I'm trying to build. I start with something simple, and play around with it, and keep adding stuff, and eventually come up with a concrete goal. At that point the patch is a complete mess and usually gets thrown away. That's when I try to design it properly and build something cleanly.

Flowcharts can be a good part of the design, but I rarely use them either. There have been a few times I used them, and they were a big help. Like for this sequencing app: 

http://compusition.com/web/news/2008/04/10

 - see the picture at the bottom, you can click to enlarge. And no, I can't share that patch yet. It mostly works but is not ready for public consumption yet (maybe in a few months).

For that flowchart I used a program called graphviz (

 which is pretty sweet IMO. The documentation is a bit confusing but it comes with examples that are a good starting point. It even has TextMate integration, if you use that editor.

Flowcharts can be a good part of the design, but I rarely use them either. There have been a few times I used them, and they were a big help. Like for this sequencing app: http://compusition.com/web/news/2008/04/10  - see the picture at the bottom, you can click to enlarge. And no, I can't share that patch yet. It mostly works but is not ready for public consumption yet (maybe in a few months).

For that flowchart I used a program called graphviz (http://www.graphviz.org/), which is pretty sweet IMO. The documentation is a bit confusing but it comes with examples that are a good starting point. It even has TextMate integration, if you use that editor.


Thanks for the pointer to graphviz. I'd never heard of it before but 

On 2 Jul 2008, at 22:43, Adam Murray wrote:

> Max programming is an exploratory process for me. Often I don't 

> really know what it is I'm trying to build. I start with something 

> simple, and play around with it, and keep adding stuff, and 

> eventually come up with a concrete goal. At that point the patch is 

> a complete mess and usually gets thrown away. That's when I try to 

> design it properly and build something cleanly.

> Flowcharts can be a good part of the design, but I rarely use them 

> either. There have been a few times I used them, and they were a 

> big help. Like for this sequencing app: 

> news/2008/04/10 - see the picture at the bottom, you can click to 

> enlarge. And no, I can't share that patch yet. It mostly works but 

> is not ready for public consumption yet (maybe in a few months).

> For that flowchart I used a program called graphviz (

> www.graphviz.org/), which is pretty sweet IMO. The documentation is 

> a bit confusing but it comes with examples that are a good starting 

> point. It even has TextMate integration, if you use that editor.

Thanks for the pointer to graphviz. I'd never heard of it before but  
it looks great! Just downloaded it.

>
> Max programming is an exploratory process for me. Often I don't  
> really know what it is I'm trying to build. I start with something  
> simple, and play around with it, and keep adding stuff, and  
> eventually come up with a concrete goal. At that point the patch is  
> a complete mess and usually gets thrown away. That's when I try to  
> design it properly and build something cleanly.
>
> Flowcharts can be a good part of the design, but I rarely use them  
> either. There have been a few times I used them, and they were a  
> big help. Like for this sequencing app: http://compusition.com/web/ 
> news/2008/04/10  - see the picture at the bottom, you can click to  
> enlarge. And no, I can't share that patch yet. It mostly works but  
> is not ready for public consumption yet (maybe in a few months).
>
> For that flowchart I used a program called graphviz (http:// 
> www.graphviz.org/), which is pretty sweet IMO. The documentation is  
> a bit confusing but it comes with examples that are a good starting  
> point. It even has TextMate integration, if you use that editor.
> --
> Adam Murray
> compusition.com


logic flowcharting