Forums > MaxMSP

bugreport: mute~ doesn't mute sfplay~

September 2, 2006 | 7:37 am

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


September 2, 2006 | 2:50 pm

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.

KMc

— Stefan Tiedje wrote:

> 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


September 2, 2006 | 10:04 pm

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.

Just a couple of thoughts…

Alex


September 3, 2006 | 7:08 am

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’d like to hear a comment from cycling about that.

Stefan


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


September 4, 2006 | 5:46 am

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…

Stefan


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


Viewing 5 posts - 1 through 5 (of 5 total)