snapshot inside poly~ don't mute?
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?
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
ah, thanks for letting me know.
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
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
can’t go under 20ms.
Thank you for the clarification.
ps I use a work around by stopping the snapshot manually by using the
good idea, never noticed that message.
Quote: firstname.lastname@example.org wrote on Mon, 13 March 2006 12:52
> Thank you for the clarification.
> 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
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
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].
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
   
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09