Oct 11, 2007 at 2:47pm
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?
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:
Oct 11, 2007 at 4:22pm
here are my rules for making a patch stable:
And yes, you need to test this over and over. Preferably let somebody
On 11-okt-2007, at 17:17, joshua goldberg wrote:
> right-to-left has nothing to do with stability per se.
Oct 11, 2007 at 5:35pm
Well put, Jennek.
Let me add the following:
See what happens if the power is cut off and your installation is not
Some people will try to destroy your installation by all means at
See if you can have Internet access to your program. Learn to use ARD
Good luck. You will need it.
Op 11-okt-2007, om 18:22 heeft jennek geels het volgende geschreven:
> here are my rules for making a patch stable:
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.
Oct 12, 2007 at 2:34am
At the control rate:
Learn to use the trigger object really well. Almost any time an outlet
There was an article on the C74 website a while back, but I can’t seem
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.
You must be logged in to reply to this topic.