[poly~] discards "mute" message sent to the 2nd inlet


    May 27 2008 | 2:32 pm
    Hello,
    I tried to send the "mute" message to the 2nd inlet of [poly~] (I
    implemented my own mute routine in the voices). I hoped to get the
    message into the voices thru the [in 2] box. But this doesn't seem to
    work with special messages like "mute". The workaround is simple:
    using other messages like "etum", or whatever. But I lost a couple of
    hours because ot this, so I wonder wether it is a desired behavior,
    or a bug.
    This happens with 4 and 5.
    The following patch shows what I mean:
    save as "_voice~"
    max v2;
    save as "Foo"
    max v2;
    _____________________________
    Patrick Delges
    Centre de Recherches et de Formation Musicales de Wallonie asbl

    • May 27 2008 | 10:15 pm
      Patrick,
      Mute, along with other poly~-specific messages are reserved for specific
      uses, so poly~ will gobble it up when you just send it as the beginning
      of any message.
      Sending the 'mute 1 1' message to any inlet should work just fine for
      muting. You can see this by sending poly~ the 'mutemap' message.
      First add an [out 1] to your _voice~ patch, a [print] connected to the
      newly created poly~ outlet, and then send a 'mutemap 1' message to the
      poly~.
      If you actually want to use the string 'mute' you will need to prepend
      it with something and then strip it off on the other side (with a route,
      for example).
      -Ben
      save as "-voice~"
      poly~ example:
      Patrick Delges wrote:
      > Hello,
      >
      > I tried to send the "mute" message to the 2nd inlet of [poly~] (I
      > implemented my own mute routine in the voices). I hoped to get the
      > message into the voices thru the [in 2] box. But this doesn't seem to
      > work with special messages like "mute". The workaround is simple:
      > using other messages like "etum", or whatever. But I lost a couple of
      > hours because ot this, so I wonder wether it is a desired behavior,
      > or a bug.
      >
    • May 28 2008 | 7:58 pm
      On 28-mai-08, at 00:15, Ben Bracken wrote:
      Thanks for your answer Ben,
      > Mute, along with other poly~-specific messages are reserved for
      > specific uses, so poly~ will gobble it up when you just send it as the
      > beginning of any message.
      This is expected for the first inlet, which is the only one specific to
      the [poly~] object. But the other inlets are indirectly connected to
      the encapsulated patch, not to the [poly~]
      > Sending the 'mute 1 1' message to any inlet should work just fine for
      > muting.
      Is this a desired behavior? Is there any reason to do so?
      The documentation states for all the [poly~] messages (like busymap,
      midinote, down, mute, etc.) that they are supposed to be sent to the
      left inlet. Nothing is said about sending reserved messages to other
      inlets.
      Sorry for being so picky, I just think this is not very consistent.
      As a workaround to what I still considere as a (small) bug, let say I
      use the message "shutup", sent to the 2nd inlet of the [poly~] and
      understood by the encapsulated voices. What will happen if Cycling74
      decides to use "shutup" as a reserved, poly~-specific, message in Max
      5.6 ? It will simply break my patch... Please don't tell me I should
      use #0_shutup :-)
      p
    • May 29 2008 | 12:30 pm
      Patrick Delges schrieb:
      > Is this a desired behavior? Is there any reason to do so?
      >
      > Sorry for being so picky, I just think this is not very consistent.
      I think it needs extra code to find out which inlet a message took, and
      it can also make sense, f.e. to send a target message to the same input
      you send the message into a poly~....
      If this would be changed, it would break old patches...
      It could be a likely assumption, that messages meant to control the
      behaviour of an object are understood and interpreted if you send them
      to any input (also less overhead for message passing)...
      The input will call the function with the same name, if there is no code
      to test for a certain input, it will execute it...
      But I agree this should at least be mentioned in the docs...
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • May 30 2008 | 7:16 am
      On 29 mai 08, at 14:30, Stefan Tiedje wrote:
      > Patrick Delges schrieb:
      >> Is this a desired behavior? Is there any reason to do so?
      >> Sorry for being so picky, I just think this is not very consistent.
      >
      > I think it needs extra code to find out which inlet a message took,
      Everything needs extra code. When my "customers" ask me for features
      in their patches, I won't tell them i won't implement it because it
      needs extra code (unless the feature is useless ;-).
      > and it can also make sense, f.e. to send a target message to the
      > same input you send the message into a poly~....
      > If this would be changed, it would break old patches...
      Indeed but was this a documented technique? I don't think so (I
      couldn't find this in Max4MSP2's doc, and there was no [poly~] in MSP
      before). If you use an undocumented feature, don't be surprised if
      your patch is broken in the future.
      But if you respect the doc, then your patch shouldn't be broken if new
      features/messages are introduced.
      > But I agree this should at least be mentioned in the docs...
      Yep.
      Wouldn't this topic be a good excuse to visit you at la tourette, you
      lucky Stefan?
      _____________________________
      Patrick Delges
      Centre de Recherches et de Formation Musicales de Wallonie asbl
    • May 30 2008 | 8:15 pm
      Patrick Delges schrieb:
      > Yep.
      > Wouldn't this topic be a good excuse to visit you at la tourette, you
      > lucky Stefan?
      Any topic would be a good excuse in case you need one... ;-)
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com