pdelges

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, 

Centre de Recherches et de Formation Musicales de Wallonie asbl

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.

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max


poly-discards-mute-message-sent-to-the-2nd-inlet

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 

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 

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, 

> 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, 

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).

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.
>


On 28-mai-08, at 00:15, Ben Bracken wrote:

> 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 

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 

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 

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 

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

> 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 

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...

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...

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


On 29 mai 08, at 14:30, Stefan Tiedje wrote:

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

But if you respect the doc, then your patch shouldn't be broken if new 

> But I agree this should at least be mentioned in the docs...

Wouldn't this topic be a good excuse to visit you at la tourette, you 

> 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.

Yep.
Wouldn't this topic be a good excuse to visit you at la tourette, you  
lucky Stefan?

> Wouldn't this topic be a good excuse to visit you at la tourette, you 

Any topic would be a good excuse in case you need one... ;-)

Patrick Delges schrieb:
> Yep.
> Wouldn't this topic be a good excuse to visit you at la tourette, you 
> lucky Stefan?

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