If the following have been already addressed, please accept my apologies for
a redundant post. That being said, here are a couple of curious things my
students and myself have recently noticed in Max/MSP.
The following applies to 4.6.2 OSX and XP versions
1) allpass~ object has apparently inverted descriptions of inlets and
2) linedrive object's third parameter seems not to work with numbers between
0 and 1. Namely, instead of doing a root of the number (i.e. 0.5 would be a
square root), the output is identical to input. No error is being reported
for providing values between 0 and 1.
3) Now this one is a fun one. So far only tested on XP. In one of my classes
I assigned an academic exercise that may appear to be somewhat unusual.
Namely, I had my students split into teams in order to design the most
difficult patch to debug and then compete who would debug opposing team's
patch faster. Needless to mention that the exercise was quite fun, but what
came from it was even more entertaining. We've come across a scenario which
literally messes up the computer so badly that it requires force quitting
Max even if it the "Trace" is enabled, and on top of that also requiring a
reboot before Max can be used again. As I mentioned before, this was so far
only tested on a Windows machine. The irony is that the patch could not be
Message box with value "1" (this one is actually optional)
Lo and behold the first Max/MSP virus :-D
The patch simply keeps opening the file dialog windows and you can't close
them fast enough even to close the patch (not even ALT+F4 and/or logout
helps), so you need to force-quit Max. Subsequently, one of Max processes
remains stuck in the system and are impossible to end (a.k.a. force quit, or
kill) even with administrator privileges. Thus one has to resort to
rebooting the machine. As you may have guessed it already, one of the
student teams reaped undisputed victory :-).
A couple reboots later, we've come to conclusion that the problem manifests
itself because "loadbang" is not affected by the "Trace" mode, and thus this
patch keeps executing even with the debug (a.k.a. "Trace") mode enabled
*before* the patch is opened. Now, obviously no sane person would want to do
this in their patch willingly (that is, unless confronted by an unusual
teacher-assigned exercise :-) but there could be conceivably scenarios where
"opendialog" (or some other system call I suspect) and metronome by some
strange chance would end-up being connected in an extremely complex patch
and as a result the lethal loop would ensue. This would not only make it
impossible to save any unsaved work-in-progress if the metronome were to be
started, but also if such code found its way into a patch saved in a binary
format, it would render the patch un-editable (short of HEX editing to
remove the offending "loadbang"), and thus all the work inside it would be
virtually lost. All this makes me wonder if the "Trace" mode should also
have control over "loadbang" signals which IMHO seems like a logical
expectation for a debugging tool, no?
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, and CHCI
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-5034 (fax)