Stefan Tiedje

mute~ doesn't mute sfplay~, which makes me wonder if the principle of 

muting with mute~ or pcontrol is missing something, and there are other 

Steps to reproduce: see attached patcher, choose a file to open it will 

load into a buffer~/groove~ combination and into sfplay~. you can loop 

both playback methods. play it and test with mute~ and pcontrol. only 

the groove~ stops playing, the sfplay~ will continue....

expected results: sfplay~ should be muted as well.

workaround: a pass~ object before the outlet seems to activate the mute 

function also for sfplay~. I would like to have the pass~ functionality 

integrated into any muting activity especially into poly~s. the pass~ 

object is a bit odd as way of thinking, its like a repair you are forced 

to do always. Hard to explain to newbies. I am pretty sure it wouldn't 

mute~ doesn't mute sfplay~, which makes me wonder if the principle of 
muting with mute~ or pcontrol is missing something, and there are other 
objects which might not be muted...

Steps to reproduce: see attached patcher, choose a file to open it will 
load into a buffer~/groove~ combination and into sfplay~. you can loop 
both playback methods. play it and test with mute~ and pcontrol. only 
the groove~ stops playing, the sfplay~ will continue....

workaround: a pass~ object before the outlet seems to activate the mute 
function also for sfplay~. I would like to have the pass~ functionality 
integrated into any muting activity especially into poly~s. the pass~ 
object is a bit odd as way of thinking, its like a repair you are forced 
to do always. Hard to explain to newbies. I am pretty sure it wouldn't 
break anything...

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


bugreport-mute-doesnt-mute-sfplay

I use mute and pass~ extensively (24 instances) in a large audio patch and see great CPU %

reductions from disabled patchers. Doing this for years - works like a champ.

> mute~ doesn't mute sfplay~, which makes me wonder if the principle of 

> muting with mute~ or pcontrol is missing something, and there are other 

> Steps to reproduce: see attached patcher, choose a file to open it will 

> load into a buffer~/groove~ combination and into sfplay~. you can loop 

> both playback methods. play it and test with mute~ and pcontrol. only 

> the groove~ stops playing, the sfplay~ will continue....

> expected results: sfplay~ should be muted as well.

> workaround: a pass~ object before the outlet seems to activate the mute 

> function also for sfplay~. I would like to have the pass~ functionality 

> integrated into any muting activity especially into poly~s. the pass~ 

> object is a bit odd as way of thinking, its like a repair you are forced 

> to do always. Hard to explain to newbies. I am pretty sure it wouldn't 

> #P user meter~ 175 142 188 225 50 0 168 0 103 103 103 255 153 0 255 0 0 

> #P user meter~ 85 144 98 227 50 0 168 0 103 103 103 255 153 0 255 0 0 

> #P newex 227 122 50 196617 prepend replace;

> #P newex 163 123 50 196617 prepend open;

> #P newex 67 62 251 196617 route int float open;

> #P newex 227 171 80 196617 buffer~ yoo;

I use mute and pass~ extensively (24 instances) in a large audio patch and see great CPU %
reductions from disabled patchers. Doing this for years - works like a champ.

> mute~ doesn't mute sfplay~, which makes me wonder if the principle of 
> muting with mute~ or pcontrol is missing something, and there are other 
> objects which might not be muted...
>
> Steps to reproduce: see attached patcher, choose a file to open it will 
> load into a buffer~/groove~ combination and into sfplay~. you can loop 
> both playback methods. play it and test with mute~ and pcontrol. only 
> the groove~ stops playing, the sfplay~ will continue....
>
> expected results: sfplay~ should be muted as well.
>
> workaround: a pass~ object before the outlet seems to activate the mute 
> function also for sfplay~. I would like to have the pass~ functionality 
> integrated into any muting activity especially into poly~s. the pass~ 
> object is a bit odd as way of thinking, its like a repair you are forced 
> to do always. Hard to explain to newbies. I am pretty sure it wouldn't 
> break anything...
>
> #P user meter~ 175 142 188 225 50 0 168 0 103 103 103 255 153 0 255 0 0 
> 217 217 0 153 186 0 12 3 3 3 3;
> #P user meter~ 85 144 98 227 50 0 168 0 103 103 103 255 153 0 255 0 0 
> 217 217 0 153 186 0 12 3 3 3 3;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 157 240 50 196617 *~ 0.2;
> #N vpatcher 40 104 441 381;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 2;
> #P newex 227 122 50 196617 prepend replace;
> #P window linecount 0;
> #P newex 163 123 50 196617 prepend open;
> #P newex 227 88 57 196617 opendialog;
> #P outlet 147 214 15 0;
> #N sfplay~  1 120960 0 ;
> #P newobj 147 171 50 196617 sfplay~;
> #P newex 67 62 251 196617 route int float open;
> #P newex 67 89 50 196617 t i 0.;
> #P newex 67 128 31 196617 sig~;
> #P newex 227 171 80 196617 buffer~ yoo;
> #P window linecount 1;
> #P newex 67 171 72 196617 groove~ yoo;
> #P inlet 67 38 15 0;
> #P outlet 67 216 15 0;
> #P connect 1 0 6 0;
> #P fasten 6 1 5 0 152 84 72 84;
> #P connect 6 0 5 0;
> #P connect 5 0 4 0;
> #P fasten 6 3 2 0 312 166 72 166;
> #P fasten 5 1 2 0 112 159 72 159;
> #P connect 4 0 2 0;
> #P connect 2 0 0 0;
> #P fasten 6 3 7 0 312 166 152 166;
> #P connect 10 0 7 0;
> #P connect 6 1 7 0;
> #P fasten 6 0 7 0 72 84 152 84;
> #P connect 7 0 8 0;
> #P fasten 9 0 10 0 232 111 168 111;
> #P connect 6 2 9 0;
> #P connect 9 0 11 0;
> #P connect 11 0 3 0;
> #P pop;
> #P newobj 104 120 63 196617 p;
> #P message 154 61 50 196617 $1 1;
> #P toggle 154 36 15 0;
> #P message 39 61 40 196617 loop 1;
> #P newex 104 240 50 196617 *~ 0.2;
> #P user ezdac~ 104 267 148 300 0;
> #P toggle 211 40 15 0;
> #P newex 211 86 51 196617 pcontrol;
> #P message 211 66 51 196617 enable $1;
> #P newex 154 87 38 196617 mute~;
> #P toggle 113 61 15 0;
> #P message 81 61 29 196617 open;
> #P connect 11 1 12 0;
> #P connect 11 1 14 0;
> #P connect 11 0 13 0;
> #P connect 11 0 7 0;
> #P fasten 12 0 6 0 162 263 109 263;
> #P connect 0 0 11 0;
> #P connect 1 0 11 0;
> #P connect 4 0 11 0;
> #P connect 8 0 11 0;
> #P connect 2 0 11 0;
> #P connect 10 0 2 0;
> #P connect 9 0 10 0;
> #P connect 7 0 6 0;
> #P connect 5 0 3 0;
> #P connect 3 0 4 0;
> #P window clipboard copycount 15;
>
>
>
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>

Keith McMillen 
BEAM Foundation 
http://www.beamfoundation.org/ 
510.502.5310


BTW - pass~ is not really doing the same as a mute~/pass~ combo in this case (i haven't tried it but asume you're right that sfplay~ doesn't respond to mute~ properly). mute~ tells the objects to stop processing (which often means the ouputs echo input as they commonly share memory so no processing results the output staying the same as the input). pass~ ouputs zeros all vector when a patcher is muted, otherwise passes input straight through.

So here you are still getting CPU usage (and disk access presumably) from sfplay~, it's just that pass~ is stopping the ouput going out of the patcher.

I'm guessing the rationale behind the separation of the objects is that if every object zeroed it's ouput when muted, then in a large pather that could take a substantial amount of CPU to do not a lot. This way is more efficient and hence gets you more CPU for your money.

> I use mute and pass~ extensively (24 instances) in a large audio

> patch and see great CPU % reductions from disabled patchers. Doing

yes with pass~ it does, without, sfplay~ plays on, audible (does not 

mute and uses CPU as well, even worse, accesses the harddrive which 

might lead to another performance problem)...

Now I am even not sure if the insertion of pass~ would stop the reading 

from the harddrive, I can just confirm that it stops putting out audio, 

but if it would stop the reading with pass~ the two playback versions 

would not desyncronize, but they do as they do when pass~ is missing!!!

I'd like to hear a comment from cycling about that.

Keith McMillen wrote:
> I use mute and pass~ extensively (24 instances) in a large audio
> patch and see great CPU % reductions from disabled patchers. Doing
> this for years - works like a champ.

yes with pass~ it does, without, sfplay~ plays on, audible (does not 
mute and uses CPU as well, even worse, accesses the harddrive which 
might lead to another performance problem)...
whereas groove~ stops as advertised...

Now I am even not sure if the insertion of pass~ would stop the reading 
from the harddrive, I can just confirm that it stops putting out audio, 
but if it would stop the reading with pass~ the two playback versions 
would not desyncronize, but they do as they do when pass~ is missing!!!

> I'm guessing the rationale behind the separation of the objects is

> that if every object zeroed it's ouput when muted, then in a large

> pather that could take a substantial amount of CPU to do not a lot.

> This way is more efficient and hence gets you more CPU for your

Yes that makes sense, and could as well explain why sfplay~ doesn't 

mute. The disk I/O to fill the vector with samples is not considered an 

audio process and not considered an scheduler task. Even pcontrol 

doesn't stop the I/O. The sfplay~ has to be stopped by hand to prevent 

it from reading the disc. If this is not going to be changed, it needs 

Within a poly~ though, sfplay~ is muted properly...

Alex Harker wrote:
> I'm guessing the rationale behind the separation of the objects is
> that if every object zeroed it's ouput when muted, then in a large
> pather that could take a substantial amount of CPU to do not a lot.
> This way is more efficient and hence gets you more CPU for your
> money.

Yes that makes sense, and could as well explain why sfplay~ doesn't 
mute. The disk I/O to fill the vector with samples is not considered an 
audio process and not considered an scheduler task. Even pcontrol 
doesn't stop the I/O. The sfplay~ has to be stopped by hand to prevent 
it from reading the disc. If this is not going to be changed, it needs 
to be mentioned in the help file.
Within a poly~ though, sfplay~ is muted properly...

bugreport: mute~ doesn't mute sfplay~