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

    • 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