Thijs Koerselman

I have a poly~ with audio objects, including a snapshot~ sampling the audio

to a float output. If the instance is muted, all audio is stopped, but

snapshot~ keeps on outputting values. The build in snapshot function of

snapshot~ is more efficient then number~ for sampling an audio stream, but

this behavior makes me wonder. Is this a bug or can someone explain to me

I have a poly~ with audio objects, including a snapshot~ sampling the audio
to a float output. If the instance is muted, all audio is stopped, but
snapshot~ keeps on outputting values. The build in snapshot function of
number~ doesn't do this.

snapshot~ is more efficient then number~ for sampling an audio stream, but
this behavior makes me wonder. Is this a bug or can someone explain to me
why it works like that?

snapshot-inside-poly-dont-mute

If it is not a bug, I sent a bug report about a year ago, but since 

it is not of a vital importance, it might not be high on the bug fix 

https://cycling74.com/forums/index.php?t=msg&goto=447

If it is not a bug, I sent a bug report about a year ago, but since  
it is not of a vital importance, it might not be high on the bug fix  
to-do list.

 https://cycling74.com/forums/index.php?t=msg&goto=447 71&srch=snapshot#msg_44771

When you mute an instance in a poly~ it turns off the signal

processing, but it does not turn off the message-passing activities of

the main and scheduler threads. The only thing snapshot~

signal-processing code does is store the most recent value in a

variable so that when the object is asked to output a value, either by

a bang or the internal clock, it accessess the variable. Turning off

the signal processing simply freezes the most recent value.

The code for number~ is very similar except that there's a filter in

the number output method that prevents the same number from being

output twice in a row. In other words if the internal stored value is

unchanged since the last output, nothing is output until a change

There's one other very important difference between these similar

capabilities of snapshot~ and number~: when internally clocked,

snapshot~ outputs the data in the scheduler thread. number~ defers

When you mute an instance in a poly~ it turns off the signal
processing, but it does not turn off the message-passing activities of
the main and scheduler threads.  The only thing snapshot~
signal-processing code does is store the most recent value in a
variable so that when the object is asked to output a value, either by
a bang or the internal clock, it accessess the variable.  Turning off
the signal processing simply freezes the most recent value.

The code for number~ is very similar except that there's a filter in
the number output method that prevents the same number from being
output twice in a row.  In other words if the internal stored value is
unchanged since the last output, nothing is output until a change
occurs.

There's one other very important difference between these similar
capabilities of snapshot~ and number~: when internally clocked,
snapshot~ outputs the data in the scheduler thread.  number~ defers
the output to the main thread.

Hi Ben, thanks for the detailed explanation. It makes sense like that. I'll

just put a change after snapshot. number~ is no option anyway because it

Hi Ben, thanks for the detailed explanation. It makes sense like that. I'll
just put a change after snapshot. number~ is no option anyway because it
can't go under 20ms.

ps I use a work around by stopping the snapshot manually by using the 

ps I use a work around by stopping the snapshot manually by using the  
'stop' message


Quote: tremblap@gmail.com wrote on Mon, 13 March 2006 12:52

----------------------------------------------------

> ps I use a work around by stopping the snapshot manually by using the 

which still would not run off the signal connection

and therefore the processing of the snapshot object. ;)

what about multiplying that signal with 0.~ when the

Quote: tremblap@gmail.com wrote on Mon, 13 March 2006 12:52
----------------------------------------------------
> Thank you for the clarification.
>
> pa
>
> ps I use a work around by stopping the snapshot manually by using the  
> 'stop' message
>

which still would not run off the signal connection
and therefore the processing of the snapshot object. ;)

what about multiplying that signal with 0.~ when the
poly~ is turned off ?


mute turns off the dsp, stop turns off the snapshot~ scheduler, what else is

left to fix then? I don't see what *~ 0. is good for on an already muted

mute turns off the dsp, stop turns off the snapshot~ scheduler, what else is
left to fix then? I don't see what *~ 0. is good for on an already muted
signal path. maybe I misunderstand you.

hmmm ... may i ask why you turn the poly~ off?

you normally do that to save CPU, which will not

to disable the outlets you could use other 

things which are more simple than sending (mute 1) 

to [thispatcher] from outside the poly patcher.

i recommended the 0.~ bc that would at least stop outputting

(well, if you have a change behind it ;) )

you normally do that to save CPU, which will not
happen by sending (stop) to [snapshot~].

to disable the outlets you could use other 
things which are more simple than sending (mute 1) 
to [thispatcher] from outside the poly patcher.

i recommended the 0.~ bc that would at least stop outputting
numbers from snapshot. 
(well, if you have a change behind it ;) )

I use adsr~ inside poly~ using it's automatic mute function to thispoly.

That way the poly gets muted when a voice dies. To save my cpu, ofcourse.

Then the snapshot inside this poly, which is sampling the audio, is

continuing, so I use the mute flag to start/stop the snapshot with each

voice. This not only stops the scheduler inside snapshot, but also

eliminates the need for [change] after [snaphot].

I use adsr~ inside poly~ using it's automatic mute function to thispoly.
That way the poly gets muted when a voice dies. To save my cpu, ofcourse.
Then the snapshot inside this poly, which is sampling the audio, is
continuing, so I use the mute flag to start/stop the snapshot with each
voice. This not only stops the scheduler inside snapshot, but also
eliminates the need for [change] after [snaphot].

> what about multiplying that signal with 0.~ when the

I think you would need the pass~ object. Its sole purpose is silencing 

Roman Thilenius wrote:
> what about multiplying that signal with 0.~ when the
> poly~ is turned off ?

I think you would need the pass~ object. Its sole purpose is silencing 
muted patchers.

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


snapshot inside poly~ don't mute?