johno

I am about to start building a patch that is to be used by others for about a year and I have just realized that I dont know the first thing about making patches stable. I know the right to left order has quite a bit to do with it but Im mot too sure how to implement this (ie is it every object you make must be patched to others in right to left order). Can any one give me a few useful hints and tips before I start building this patch?

stable-patches

right-to-left has nothing to do with stability per se.

it's just the order that messages are passed to objects.

stability is only achieved through testing.

On Oct 11, 2007, at 10:48 AM, john wrote:

> I am about to start building a patch that is to be used by others 

> for about a year and I have just realized that I dont know the 

> first thing about making patches stable. I know the right to left 

> order has quite a bit to do with it but Im mot too sure how to 

> implement this (ie is it every object you make must be patched to 

> others in right to left order). Can any one give me a few useful 

> hints and tips before I start building this patch?

>
> I am about to start building a patch that is to be used by others  
> for about a year and I have just realized that I dont know the  
> first thing about making patches stable. I know the right to left  
> order has quite a bit to do with it but Im mot too sure how to  
> implement this (ie is it every object you make must be patched to  
> others in right to left order). Can any one give me a few useful  
> hints and tips before I start building this patch?
>
> Cheers, John
>


here are my rules for making a patch stable:

- understand which events arrive asynchronously (like a MIDI input or 

make sure you understand how this propagates through your patch, 

and how it may interfere with other events.

My approach is to make asynchronous events synchronous at some 

at explicit control of the patch master [metro] object.

- freeze your target platform. no more updates, nor for max nor for 

the OS, unless it is essential to solve a problem

that your patch is having. I'd rather have 100 known bugs than 1 

unknown, in a patch that is to last a year,

and is run by someone else. a known bug leads to a known 

workaround, however silly -- an unknown bug leads to you traveling to

wherever the show is at that point in time, at the worst possible 

Never ever think that an upgrade will do no harm - it will.

And yes, you need to test this over and over. Preferably let somebody 

else do the testing. S/he'll generate other

On 11-okt-2007, at 17:17, joshua goldberg wrote:

> right-to-left has nothing to do with stability per se.

> it's just the order that messages are passed to objects.

> stability is only achieved through testing.

> On Oct 11, 2007, at 10:48 AM, john wrote:

>> I am about to start building a patch that is to be used by others 

>> for about a year and I have just realized that I dont know the 

>> first thing about making patches stable. I know the right to left 

>> order has quite a bit to do with it but Im mot too sure how to 

>> implement this (ie is it every object you make must be patched to 

>> others in right to left order). Can any one give me a few useful 

>> hints and tips before I start building this patch?

here are my rules for making a patch stable:
- understand which events arrive asynchronously (like a MIDI input or  
a GUI event).
   make sure you understand how this propagates through your patch,  
and how it may interfere with other events.
   My approach is to make asynchronous events synchronous at some  
point, by gating them into the main flow
   at explicit control of the patch master [metro] object.
- freeze your target platform. no more updates, nor for max nor for  
the OS, unless it is essential to solve a problem
   that your patch is having. I'd rather have 100 known bugs than 1  
unknown, in a patch that is to last a year,
   and is run by someone else. a known bug leads to a known  
workaround, however silly -- an unknown bug leads to you traveling to
   wherever the show is at that point in time, at the worst possible  
moment in your agenda.
   Never ever think that an upgrade will do no harm - it will.

And yes, you need to test this over and over. Preferably let somebody  
else do the testing. S/he'll generate other
asynchronous events than you.
HtH
-jennek

> right-to-left has nothing to do with stability per se.
>
> it's just the order that messages are passed to objects.
>
> stability is only achieved through testing.
>
> On Oct 11, 2007, at 10:48 AM, john wrote:
>
>>
>> I am about to start building a patch that is to be used by others  
>> for about a year and I have just realized that I dont know the  
>> first thing about making patches stable. I know the right to left  
>> order has quite a bit to do with it but Im mot too sure how to  
>> implement this (ie is it every object you make must be patched to  
>> others in right to left order). Can any one give me a few useful  
>> hints and tips before I start building this patch?
>>
>> Cheers, John
>>
>
>


Don't trust any object. Be prepared to jump through hoops because the 

most straightforward solution will just not work reliably. Test. 

Test. Test. Watch out for unexpected side-effects. Watch out for 

event order, some operations (like buffer operations) may take (a 

varying amount of) considerable real time, destroying the expected 

order of events. Lots of Max objects will not signal when they're 

See what happens if the power is cut off and your installation is not 

shut down properly. Have a backup/restore plan/scheme. Test with the 

hardware you will be using. Don't think it works fine with a RME 

FF800, so it will work fine with the newer FF400. Train people what 

to do if your soundcard needs to be reset(preferably before frying 

Some people will try to destroy your installation by all means at 

their disposal. (sticks, lighters, keyrings, knives, everything). 

Talk to manufacturers that make vending machines for public places. 

See if you can have Internet access to your program. Learn to use ARD 

(Apple Remote Desktop) and/or VNC so you van do offsite 

troubleshooting. Install Keep-It-Up-X or something similar to make 

sure people will not get to the finder and wreak havoc there.

Op 11-okt-2007, om 18:22 heeft jennek geels het volgende geschreven:

> here are my rules for making a patch stable:

> - understand which events arrive asynchronously (like a MIDI input 

> make sure you understand how this propagates through your patch, 

> and how it may interfere with other events.

> My approach is to make asynchronous events synchronous at some 

> point, by gating them into the main flow

> at explicit control of the patch master [metro] object.

> - freeze your target platform. no more updates, nor for max nor for 

> the OS, unless it is essential to solve a problem

> that your patch is having. I'd rather have 100 known bugs than 1 

> unknown, in a patch that is to last a year,

> and is run by someone else. a known bug leads to a known 

> workaround, however silly -- an unknown bug leads to you traveling to

> wherever the show is at that point in time, at the worst possible 

> Never ever think that an upgrade will do no harm - it will.

> And yes, you need to test this over and over. Preferably let 

> somebody else do the testing. S/he'll generate other

> On 11-okt-2007, at 17:17, joshua goldberg wrote:

>> right-to-left has nothing to do with stability per se.

>> it's just the order that messages are passed to objects.

>> stability is only achieved through testing.

>> On Oct 11, 2007, at 10:48 AM, john wrote:

>>> I am about to start building a patch that is to be used by others 

>>> for about a year and I have just realized that I dont know the 

>>> first thing about making patches stable. I know the right to left 

>>> order has quite a bit to do with it but Im mot too sure how to 

>>> implement this (ie is it every object you make must be patched to 

>>> others in right to left order). Can any one give me a few useful 

>>> hints and tips before I start building this patch?

Let me add the following:
Don't trust any object. Be prepared to jump through hoops because the  
most straightforward solution will just not work reliably. Test.  
Test. Test. Watch out for unexpected side-effects. Watch out for  
event order, some operations (like buffer operations) may take (a  
varying amount of) considerable real time, destroying the expected  
order of events. Lots of Max objects will not signal when they're  
actually busy or done processing/ready.

See what happens if the power is cut off and your installation is not  
shut down properly. Have a backup/restore plan/scheme. Test with the  
hardware you will be using. Don't think it works fine with a RME  
FF800, so it will work fine with the newer FF400. Train people what  
to do if your soundcard needs to be reset(preferably before frying  
all the tweeters).

Some people will try to destroy your installation by all means at  
their disposal. (sticks, lighters, keyrings, knives, everything).  
Staff and visitors.
Talk to manufacturers that make vending machines for public places.  
These are built like tanks for a reason.

See if you can have Internet access to your program. Learn to use ARD 
(Apple Remote Desktop) and/or VNC so you van do offsite  
troubleshooting. Install Keep-It-Up-X or something similar to make  
sure people will not get to the finder and wreak havoc there.

Zip Boterbloem
Media Mechanics
Zwaluwstraat 54
2025 VR  Haarlem
The Netherlands
+31627014758
zip@knoware.nl

> here are my rules for making a patch stable:
> - understand which events arrive asynchronously (like a MIDI input  
> or a GUI event).
>   make sure you understand how this propagates through your patch,  
> and how it may interfere with other events.
>   My approach is to make asynchronous events synchronous at some  
> point, by gating them into the main flow
>   at explicit control of the patch master [metro] object.
> - freeze your target platform. no more updates, nor for max nor for  
> the OS, unless it is essential to solve a problem
>   that your patch is having. I'd rather have 100 known bugs than 1  
> unknown, in a patch that is to last a year,
>   and is run by someone else. a known bug leads to a known  
> workaround, however silly -- an unknown bug leads to you traveling to
>   wherever the show is at that point in time, at the worst possible  
> moment in your agenda.
>   Never ever think that an upgrade will do no harm - it will.
>
> And yes, you need to test this over and over. Preferably let  
> somebody else do the testing. S/he'll generate other
> asynchronous events than you.
> HtH
> -jennek
>
>
> On 11-okt-2007, at 17:17, joshua goldberg wrote:
>
>> right-to-left has nothing to do with stability per se.
>>
>> it's just the order that messages are passed to objects.
>>
>> stability is only achieved through testing.
>>
>> On Oct 11, 2007, at 10:48 AM, john wrote:
>>
>>>
>>> I am about to start building a patch that is to be used by others  
>>> for about a year and I have just realized that I dont know the  
>>> first thing about making patches stable. I know the right to left  
>>> order has quite a bit to do with it but Im mot too sure how to  
>>> implement this (ie is it every object you make must be patched to  
>>> others in right to left order). Can any one give me a few useful  
>>> hints and tips before I start building this patch?
>>>
>>> Cheers, John
>>>
>>
>>
>


yes, all about testing. Also you should be closing and opening the patch periodically to see what needs to be initialized at the start, generally it should be very little (probably a loadmess 1 to a preset that has good default settings). Most things seem to work OK regardless of tempo, refresh rate, etc, but you will certainly run into problems if you're asking for video and / or rendering, these tax the processor and can make the interface sluggish. qmetro versus metro is not only a decision, it's a way of thinking about what's happening and what you want (or DON'T want) to happen when your patch is running.... like unresponsiveness.

I almost never have a metro go below 20 ms for anything, this equals 50 fps and that is fast enough for (most) human eyes and brains. This can help prevent backlog with some processes, but again, test a lot, and it all depends on what you're doing and what hardware you've got.

Learn to use the trigger object really well. Almost any time an outlet 

splits connects to more than one inlet, you should use trigger. The 

reason for doing this is that it allows you to control the order that 

events happen in. The right-left order in your patch won't break if 

things are moved around, and this saves a lot of debugging time.

There was an article on the C74 website a while back, but I can't seem 

to find it right now. Definitely helpful, though...

Learn to use the trigger object really well.  Almost any time an outlet 
splits connects to more than one inlet, you should use trigger.     The 
reason for doing this is that it allows you to control the order that 
events happen in.  The right-left order in your patch won't break if 
things are moved around, and this saves a lot of debugging time.

There was an article on the C74 website a while back, but I can't seem 
to find it right now.  Definitely helpful, though...


http://www.hellbender.org/sample_manual.pdf

It's not perfect, but you'll get the idea.

---- List every file that belongs to the project and the exact location it belongs in. Write a one sentence description, e.g., "Third party external required by patch to operate properly", "Custom abstraction that does xyx", "Text file read by col object", etc.

---- List *every* system requirement and dependency -- Minimum CPU, specific OS, specific version of QT or whatever else is being use, specific version of Max/MSP/Jitter. Do not make any assumptions that a system will be setup the way you need.

--- Provide a written instructions for patch settings setup and use. No matter how obvious you think it is to use your application, there will be users who can't figure it out. Even if it's just a simple "start" button, document it.

If possible and legal, provide the installers for the specific versions of the software you need in the system - The specific Max/MSP/Jitter installers, the specific QT installer, etc.

I have a sample you see at http://www.hellbender.org/sample_manual.pdf

---- List every file that belongs to the project and the exact location it belongs in.  Write a one sentence description, e.g., "Third party external required by patch to operate properly", "Custom abstraction that does xyx", "Text file read by col object", etc.

---- List *every* system requirement and dependency -- Minimum CPU,  specific OS, specific version of QT or whatever else is being use, specific version of Max/MSP/Jitter.  Do not make any assumptions that a system will be setup the way you need.

--- Provide a written instructions for patch settings setup and use.  No matter how obvious you think it is to use your application, there will be users who can't figure it out.  Even if it's just a simple "start" button, document it.

If possible and legal, provide the installers for the specific versions of the software you need in the system - The specific Max/MSP/Jitter installers, the specific QT installer, etc.


Stable Patches