strange mute~ behaviour


    Sep 21 2007 | 3:10 pm
    please give a try to this simple lfos bank..and tell me if you are experiencing weirdness when muting subpatchers
    cheers
    michele
    max v2;

    • Sep 22 2007 | 2:20 pm
      Hi.
      Have a look at pass~ help file ;)
      Cheers.
    • Sep 25 2007 | 8:48 am
      gusano schrieb:
      > Hi.
      > Have a look at pass~ help file ;)
      That does not explain the behaviour, though it seems to help somehow...
      The same happens with pcontrol. Maybe that bug explains much more why
      mute~ often fails...
      It is clearly a bug, though I don't know if it's a bug of snapshot~ or
      the Max application...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Sep 25 2007 | 12:59 pm
    • Sep 25 2007 | 3:46 pm
      Coincidentally, I came to the forums with the intent of posting questions about mute~ too!
      1/ I am also experiencing the situation where mute~ does not appear to make any difference to CPU load, even tho' it seems to cause audio processing to stop. pcontrol with its enable message does make a major difference - with the latter, a test patch running at 60% CPU dropped to about 9% (however, I'm puzzled by why it's even as high as 9%, given I disabled pretty much everything in the patch...).
      2/ Mute~ only appears to work as stated on the tin in very small, very simple patches. So I'm wondering whether there are situations/particular objects/preference settings that affect its behaviour.
      3/ It *seems* as if mute~ messages do not work if they are sent remotely (e.g. via a send/receive pair), or from inside one subpatch to another subpatch. Is this true? The MSP Reference says that mute~ doesn't work inside bpatchers - perhaps it doesn't work inside any patcher except the top level one?
      4/ Something that I'd suggest ought to be altered is the fact that mute~ causes an almighty thump when it's turned on/off. This can, of course, be hidden using judicious volume controls and delay messages, but since the object only has one function, you'd think it would do it without assistance! :-)
      5/ One final point, the original mute~ help file, and the revised one here, both confusingly state that the pcontrol disable message "disables all objects (i.e. MIDI)". I believe that it disables MIDI objects, but not *all* objects (to test this, I wrote a little patch to do basic arithmetic - it worked, even while 'disabled').
    • Sep 25 2007 | 6:41 pm
      I just realised, that in the whole thread the behaviour has not been
      described at all. It might react differently on different computers...
      So I will add some bug reporting guide lines:
      If all subpatchers are on, every subpatcher pulls out a different wave
      form. If all subpatchers are muted, all outputs stay on their last
      level. So far its expected behaviour.
      But if only one subpatcher is unmuted, all other muted subpatchers would
      send out exactly the same signal as the unmuted one! (The saw and
      triangle and noise pulls out a sine)
      Expected behaviour: The muted subpatchers send out their last value
      (vector) or zero, the unmuted sends out its own waveform.
      In addition if I place a pass~ in one of them, the weirdness accelerates:
      If I unmute the one with pass~ (in my example it was the sine
      subpatcher) the muted ones will put out a sine, if I unmute only the
      saw, or the triangle, I get expected behaviour. If I unmute the noise,
      the saw puts out noise as well, the other two are muted (to 0)...
      I don't know if MacIntels or Windows versions have the same behaviour,
      as I ran it on a PPC Powerbook 12" Mac OS X 10.4.10 and Max 4.6.3...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Sep 25 2007 | 9:22 pm
      On 25 sept. 07, at 20:41, Stefan Tiedje wrote:
      > I just realised, that in the whole thread the behaviour has not
      > been described at all. It might react differently on different
      > computers...
      >
      > So I will add some bug reporting guide lines:
      >
      > If all subpatchers are on, every subpatcher pulls out a different
      > wave form. If all subpatchers are muted, all outputs stay on their
      > last level. So far its expected behaviour.
      >
      > But if only one subpatcher is unmuted, all other muted subpatchers
      > would send out exactly the same signal as the unmuted one! (The saw
      > and triangle and noise pulls out a sine)
      > Expected behaviour: The muted subpatchers send out their last value
      > (vector) or zero, the unmuted sends out its own waveform.
      >
      > In addition if I place a pass~ in one of them, the weirdness
      > accelerates:
      > If I unmute the one with pass~ (in my example it was the sine
      > subpatcher) the muted ones will put out a sine, if I unmute only
      > the saw, or the triangle, I get expected behaviour. If I unmute the
      > noise, the saw puts out noise as well, the other two are muted (to
      > 0)...
      >
      > I don't know if MacIntels or Windows versions have the same
      > behaviour, as I ran it on a PPC Powerbook 12" Mac OS X 10.4.10 and
      > Max 4.6.3...
      Thanks for the report. We'll look into it for the next update. Use
      pass~ everywhere in the meantime and we'll straighten it out.
      ej
    • Sep 26 2007 | 1:10 pm
      Quick additional comment -
      I checked out one of the things that was puzzling me. Mute~ does indeed not work unless it's *directly* attached to the patch it's supposed to be affecting - so no send/receive or send~/receive~ pairs, no messages from inside one patcher to another etc.
      When placed correctly, it works fine! In fact, in a test patch it worked *better* than enable/pcontrol: the latter reduced a load of 60% CPU to about 15%, the former reduced it to 9%.
    • Sep 28 2007 | 1:42 pm
      Hi,
      same behaviour on MacBookPro 2Ghz, Max 4.6.3.
      Ciao,
      Ric
      > I just realised, that in the whole thread the behaviour has not
      > been described at all. It might react differently on different
      > computers...
      >
      > So I will add some bug reporting guide lines:
      >
      > If all subpatchers are on, every subpatcher pulls out a different
      > wave form. If all subpatchers are muted, all outputs stay on their
      > last level. So far its expected behaviour.
      >
      > But if only one subpatcher is unmuted, all other muted subpatchers
      > would send out exactly the same signal as the unmuted one! (The saw
      > and triangle and noise pulls out a sine)
      > Expected behaviour: The muted subpatchers send out their last value
      > (vector) or zero, the unmuted sends out its own waveform.
      >
      > In addition if I place a pass~ in one of them, the weirdness
      > accelerates:
      > If I unmute the one with pass~ (in my example it was the sine
      > subpatcher) the muted ones will put out a sine, if I unmute only
      > the saw, or the triangle, I get expected behaviour. If I unmute the
      > noise, the saw puts out noise as well, the other two are muted (to
      > 0)...
      >
      > I don't know if MacIntels or Windows versions have the same
      > behaviour, as I ran it on a PPC Powerbook 12" Mac OS X 10.4.10 and
      > Max 4.6.3...
      >
      > Stefan
      >
      > --
      > Stefan Tiedje------------x-------
      > --_____-----------|--------------
      > --(_|_ ----|-----|-----()-------
      > -- _|_)----|-----()--------------
      > ----------()--------www.ccmix.com
      >
      >