Looks like it's time for a gentle reminder about the BUG REPORTING
GUIDELINES, as the list seems to be falling back on bad habits again.
The most important parts of this necessary evil are an example patch
and a carefully described, overly specific list of steps one needs to
take when using the example patch, in order to reproduce the behavior.
Without an example patch and these steps, the chances that we're
going to be able to successfully reproduce your bug are so low, we
probably won't bother to try... So, thanks for using the attached
guideines, or something similar, when reporting problems. It can only
BUG REPORTING GUIDELINES
Please report any problems you experience with clear and complete
information, including steps to reproduce, software and system
information, and where possible, an isolated example patch and crash
log. Something like the following would be ideal. This makes it
easier for us to find and fix the problems you experience. Without
such clear and complete information, it is less likely we will be
Provide a descriptive summary of the issue.
Steps to Reproduce:
In numbered format, detail the exact steps taken to produce the bug.
Describe what you expected to happen when you executed the steps above.
Please explain what actually occurred when steps above are executed.
Describe circumstances where the problem occurs or does not occur,
such as software versions and/or hardware configurations.
Provide additional information, such as references to related
problems, workarounds and relevant attachments.
Max, the program, comprises many, many objects. Some of them can be
seen by you, the user -- boxes, patchers, lines between boxes, etc.
Other objects are behind the scenes, or inside of other objects
(Jitter objects are typically composed of a Max object and a Jitter
object, which is wrapped inside of the Max object).
When a new object is created, we say it has been instantiated. When
an object is destroyed, we say it has been freed. What kind of object
it is, is beside the point. It is either an object that you have
control over, or an object that you don't (some object that you have
created might create objects inside of itself, and might be freeing
something on its own).
What I'm trying to say is that you don't need to understand the error
in order to report it. Your initial message, that changing the number
of voices of a poly~ in a poly~ was leading to the error, seemed to
be pointing in a reasonable direction. All that was missing was an
In any case, this error, although perhaps bewildering, doesn't seem
to be causing any harm -- Max is noticing that the request to free
this object is invalid, and is not crashing. It would be nice, for
us, the developers, to understand why the error is occurring in the
first place, and to fix it. From your perspective, it's just a
nuisance in the Max window.
If you want to learn more about how Max is working under the hood,
download the Max SDK. Problems like this aren't explicitly discussed,
but it's probably interesting reading, in any case.
Glad that I was able to help. Now I would really like you to help us:
please make a simple version of the patch which generates the error
and send it to the list, so that we can figure out why the error is
happening, and solve it for everyone.