Stable Patches

Oct 11, 2007 at 2:47pm

Stable Patches

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

#34133
Oct 11, 2007 at 3:17pm

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
>

#114741
Oct 11, 2007 at 4:22pm

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
>>
>
>

#114742
Oct 11, 2007 at 5:35pm

Well put, Jennek.

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.

Good luck. You will need it.

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

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
> 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
>>>
>>
>>
>

#114743
Oct 12, 2007 at 2:23am

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.

–CJ

#114744
Oct 12, 2007 at 2:34am

At the control rate:

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…

#114745
Oct 14, 2007 at 5:00pm

Good advice in this thread.

Add detailed written documentation.

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

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

Salient points include:

—- 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.

#114746

You must be logged in to reply to this topic.