Michele Verità

please give a try to this simple lfos bank..and tell me if you are experiencing weirdness when muting subpatchers

please give a try to this simple lfos bank..and tell me if you are experiencing weirdness when muting subpatchers
cheers
michele

strange-mute-behaviour

Hi.
Have a look at pass~ help file ;)
Cheers.

That does not explain the behaviour, though it seems to help somehow...

The same happens with pcontrol. Maybe that bug explains much more why 

It is clearly a bug, though I don't know if it's a bug of snapshot~ or 

gusano schrieb:
> Hi.
> Have a look at pass~ help file ;)

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

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

Coincidentally, I came to the forums with the intent of posting questions about mute~ too! 

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


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 

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 

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

I just realised, that in the whole thread the behaviour has not been 
described at all. It might react differently on different computers...

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

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 

> 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 

> 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 

> 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 

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.

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

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

same behaviour on MacBookPro 2Ghz, Max 4.6.3.

Hi,
same behaviour on MacBookPro 2Ghz, Max 4.6.3.

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


strange mute~ behaviour