thispoly mute state
Hello,
within an instance of a poly~ patcher the second outlet of thispoly~ does
not report the mute state when the corresponding poly~ receives a mute-all
message,
like [mute 0 1] .
With single instance mute messages, like [mute xxx 1], it does.
Is this intended?
OS 10.4.8, MaxMSP 4.6.2, MaxBook Pro
thanks
Andre
--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@bartetzki.de
Tel +49-(0)30-92375877
VoIP +49-(0)30-38108677
Fax +49-(0)30-38108678
UMS +49-(0)941-599214065 (Voice, Fax, SMS)
Skype bartetzki
--------------------------------------------------
you have to give thispoly~ a bang to report the mute-state, not a mute message.
jl
I have exactly the same problem with a MacbookPro... and a bang to the [thispoly~] does nothing...
With the message [mute 1 1] to a [poly~], the second outlet of [thispoly~] sends a "1" (whithout after a bang to the [thispoly~]), but nothing with [mute 0 1].
Hemhem... why ?...
An example :
A poly named "kleinepoly" :
and the patch :
Good point, same here.
I'd say this is a bug.
Mac OS 10.4.9, Max 4.6.3
Mattijs
Quote: TotoEtLiTiti wrote on Thu, 31 May 2007 09:28
----------------------------------------------------
> An example :
>
> A poly named "kleinepoly" :
>
> #P toggle 130 149 15 0;
> #P button 88 89 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 88 120 52 196617 thispoly~;
> #P connect 1 0 0 0;
> #P connect 0 1 2 0;
> #P window clipboard copycount 3;
>
> and the patch :
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 185 151 204 196617
> #P comment 175 106 137 196617 First , open the poly~ , then :;
> #P message 132 127 50 196617 mute 1 1;
> #P message 132 152 50 196617 mute 0 1;
> #P message 80 127 50 196617 mute 1 0;
> #P message 80 152 50 196617 mute 0 0;
> #P newex 80 188 92 196617 poly~ kleinepoly 1;
> #P comment 185 127 204 196617
> #P connect 4 0 1 0;
> #P connect 5 0 1 0;
> #P connect 2 0 1 0;
> #P connect 3 0 1 0;
> #P window clipboard copycount 8;
>
>
>
----------------------------------------------------
*bump*
After 2 years (and new versions: Max5.1.3, OSX.5.8), should we considere this as a desired feature.
If not, then I wanted to add that the mutemap doesn't reflect the mute state neither (but this is coherent with the problem exposed here).
p
It's not exactly an undesired feature as it is an undocumented one.
Sending the [mute 0 1] message mutes all of the voices but allows it to be restored to the previous state. For example, in a 4-voice poly~ object I might have the mutemap 0011. If I [mute 0 1] this and then [mute 0 0] it, I will get the same mutemap.
This is useful for when you might want to temporarily mute the poly~ object but come back to the same setting. It would be pretty irritating if, when you unmuted it, every single one of your voices suddenly started playing.
If you REALLY want to mute/unmute every voice and get the correct 11111111 mutemap, then just use [uzi] connected to a [mute $1 1]. Or include some kind of function within your poly~ patcher that mutes it for you.
The way the mute messages work is fine, the main problem is that thispoly~ (and the mutemap message) is not always correctly reflecting a voice's state.
p
If you [mute 0 1] all, you should monitor this separately, all the information you need is in your patch. But you might still want to know if there are voices to be switched on with the next un[mute 0 0]...
The way it is, is the best in my humble opinion...
Stefan