Possible bugs


    Feb 02 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/

    • Feb 02 2007 | 1:13 pm
    • Feb 02 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
    • Feb 02 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
    • Feb 04 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
    • Feb 05 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/