Forums > MaxMSP

Possible bugs


ico
February 2, 2007 | 3:37 am

Greetings all,

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
outlets

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

loadbang
|
Message box with value "1" (this one is actually optional)
|
Metro 10
|
opendialog

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?

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, and CHCI
Virginia Tech
Dept. of Music – 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@vt.edu

http://www.music.vt.edu/people/faculty/bukvic/


February 2, 2007 | 1:13 pm



ico
February 2, 2007 | 2:29 pm

> linedrive~ is for old people ;-) There’s only the 1.06 value which
> *works*. For more efficient control, I would recommend using your own
> expression.

I agree, and that is exactly what we ended up using. Still, if this object
is broken and deprecated, it might be nice to remove it from the package to
minimize confusion.

Best wishes,

Ico


February 2, 2007 | 2:57 pm



ico
February 2, 2007 | 3:22 pm

> No because, if you want to open your ispw patches, you’ll probably be
> happy if the linedrive is still there. So the object will remain in
> the standart distrib for a long time. But, I never show it to my
> student, hope nobody is listening ;-) It’s the same with the fifth
> argument of the scale object. And by the way, with the magic 1.06
> value, it works well for scaling "MIDI to signal".

Ah, got it! Thank you for the clarification!

Best wishes,

Ico


February 4, 2007 | 11:45 pm

Ivica Ico Bukvic wrote:
> 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?

You know that you can defeat the loadbang with cmd-shift while opening a
patch (might be ctrl-shift on win). Unfortunately this does not defeat
patcherargs from fireing…
(This is an old feature request, that all loadbanging, loadmessing —
initialisation on load should be somehow defeatable…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com



ico
February 5, 2007 | 12:55 am

> You know that you can defeat the loadbang with cmd-shift while opening a
> patch (might be ctrl-shift on win). Unfortunately this does not defeat
> patcherargs from fireing…
> (This is an old feature request, that all loadbanging, loadmessing —
> initialisation on load should be somehow defeatable…)
>
> Stefan

Interesting…

Thanks for the info!

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, and CHCI
Virginia Tech
Dept. of Music – 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@vt.edu

http://www.music.vt.edu/people/faculty/bukvic/


Viewing 7 posts - 1 through 7 (of 7 total)