Ploki

How can I mute poly~ instance if there is no signal present?

peakamp~ keeps processing inside even if there is no signal, so I'd like to mute it. something like [sig~] > [thispoly~] but this only works for busy state.

mute-poly-if-no-signal-present

You should put the peakamp~ outside of poly.

Peakamp is actually the main thing in the poly. I'm doing some multichannel meters and doing it with poly is cleaner than separate instances.

Or more specifically, here is the code around my reverb unit that allows for 'trails', and then mutes once the trails are done.

It will complain about poly/abstractions, but you can get the idea:

If you put peakamp inside and mute the poly, then you won't know when there is signal again, as peakamp won't be doing anything.

How many peakamps are you using? Doesn't seem like much to worry about in terms of muting dsp.

(in my patch the output of poly goes to the [p trails] patch)

I'd use a separate peakamp~ or snapshot at slower sampling interval (100ms) for detecting whether there is a signal or not. I guess I can put a separate "voice muting" subpatcher outside for that kind of detection that communicates directly with separate poly~ voices.

Problem is I use 12 very fast (1ms) peak-amps for peak detection and they keep spitting out values even when there is no signal present, resulting in few thousand messages per second unnecessarily since I don't have signal present at all times.

I have to look more deep into your patch, I always lose track when I work with poly~

Are you doing peak detection, as in onset/attack detection? Or just for visual metering? What do you need the messages for?

dont mix up "no signal" and a signal of value(s) 0.

the latter could be used to turn a poly off, but "no signal" is problematic, because in this case the target object which is connected to a "dead" signal connection will remember the last value it got when DSP was on.

and of course, turning a poly ON from a signal inside it cannot work at all.

As far as I deduced the "signal present" detection should be done outside poly~ to control poly~. Which is fine i guess.

Also, peakamp~ doesn't stop spitting out values even after the poly instance is muted. Snapshot~ does, but it has a weird readout.

Supposedly snapshot~ fed by abs~ and slide~ 0 1200 works as "peakamp~" and apparently has a similar cpu usage.

Hello Ploki, some time ago I was using an envelope follower and an edge~ object.

Have a look into the "p SILENCE_TEST" within the bpatcher.

I don't know how to download it? It saves it as XML and doesn't seem to be valid if renamed to .maxpat.

I figured what I really need is slower peakamp~ lookup interval while signal is below 0.000003. It  hinders meters response a little (meter will need a slower lookup interval of difference to jump to signal) but it should reduce CPU while meters are on "standby" but I have to do signal threshold at message rate (after peakamp) and not at audiorate...

That way peakamps only work @100ms while signal is below thresh-hold and increase lookup when signal is highlevel.

As far as I deduced the “signal present” detection should be done outside poly~ to control poly~

i dont think you can detect a dead signal. at least you can not distinguish between a dead signal and a signal of 0.

a dead signal can only exist in one of the following situations:

- between begin~ and mute~ (or gate~ and switch~? i have never tried that)

i am not sure what happens between 2 objects set to inactive state.

and maybe i am overlooking some new v6 feature, because i dont know about those.

but however, all the situations above should not require "detection", as they are usually user-controlled, i.e. it should be known when a signal connection does not do anything.

last but not least: a signal can only be turned off at the end of a vector. so vector accuracy is all you get when using a signal to control something else. you could get the same accuracy with a signal of state 0. and state 1. transitions – and also when controlling your poly~using messages in the high priority thread: [int 1]-[delay 0]-> poly patcher - [prepend mute]-[thispoly~]

i dont think you can detect a dead signal. at least you can not distinguish between a dead signal and a signal of 0. 

a dead signal can only exist in one of the following situations:
 - inside a turned off poly~
 - between 2 turned off poly~s
 - between begin~ and mute~ (or gate~ and switch~? i have never tried that)
 - in a turned off window
 - when DSP is globally off.

last but not least: a signal can only be turned off at  the end of a vector. so vector accuracy is all you get when using a signal to control something else. you could get the same accuracy with a signal of state 0. and state 1. transitions – and also when controlling your poly~using messages in the high priority thread: [int 1]-[delay 0]-> poly patcher - [prepend mute]-[thispoly~]


Ploki, could you explain your goal a bit better and post your patch? You can use silence detection on a signal to mute a poly~ from within, but you would have to unmute by sending the "mute 0" message.

Here's a naïve peakamp follower in gen~: (it should be similar in operation to peakamp~, except outputting signal rate--it does not do a sliding window!)

I'm doing fancy GUI design and the metering, if peakamp fires at 10ms, takes up a lot of CPU. And some other functions as well... I just figured I need to clean up my patch a little.

Mute poly~ if no signal present