Andy

I'm trying to create a very simple and efficient way of playing back a sample using the groove~ object by using poly~. I have set it up to test the average signal coming through it and mute the patch if the average signal reaches 0.

Because the poly~ is muted it can no longer test the signal (as no signal exists within this poly~ any more). This is problematic when a loop may have periods of silence. I have been thinking of changing my patch to only mute a the end of a specific time period but this is inflexible and also means that processing is still going on during periods of silence.

Does anybody know of any way I can adjust my patch to ensure that that processing only occurs when there is signal to process?

Hi,
I'm trying to create a very simple and efficient way of playing back a sample using the groove~ object by using poly~. I have set it up to test the average signal coming through it and mute the patch if the average signal reaches 0. 

Because the poly~ is muted it can no longer test the signal (as no signal exists within this poly~ any more). This is problematic when a loop may have periods of silence. I have been thinking of changing my patch to only mute a the end of a specific time period but this is inflexible and also means that processing is still going on during periods of silence. 

dynamic-signal-testing-in-poly-for-muting-purposes

You can use the groove~ object's synch output (right output) to determine whether it's playing anything. That will account for silences in the soundfiles. This works great for one-shot playback. If you're looping the soundfile, you may need some extra objects to ignore the synch signal until looping is turned off--or whatever scenario you devise.

one of the great things about triggering an event within a dynamic wrapper such as poly~ is the ability to detect the event using an envelope at signal rate.

i would recommend doing your testing of an active/busy state using such an env + thispoly~.

one of the great things about triggering an event within a dynamic wrapper such as poly~ is the ability to detect the event using an envelope at signal rate.  

>>I have been thinking of changing my patch to only mute a the end >>of a specific time period but this is inflexible and also means >>that processing is still going on during periods of silence.

Could somebody tell me how to do this please. I have been trying to find out all morning.

The way I was going to do it with my system was to use a master timing path that would trigger samples at the beginning of a bar. I was going to combine this with the presence/absence of a sample from the player at that point.

For example Bar X may only be playing 3 out of 4 instruments. The instrument not playing could be muted to preserve CPU resources. Bar X+1 may have all 4 instruments playing so when the bang is received to trigger the samples it also unmutes the instrument.

Not saying this is 'the' way to do it but its a possible method I was thinking of. Depends on how you are timing your system really.

The way I was going to do it with my system was to use a master timing path that would trigger samples at the beginning of a bar. I was going to combine this with the presence/absence of a sample from the player at that point. 

Not saying this is 'the' way to do it but its a possible method I was thinking of. Depends on how you are timing your system really. 

> Does anybody know of any way I can adjust my patch to ensure that

> that processing only occurs when there is signal to process?

As you pointed out yourself already, the testing part must not be muted. 

Muting will only be worth it, if you have to mute a lot...

Your example does not fall into that category...

If you have real processing going on, you can use nested poly~s, a poly~ 

within a poly~. The inner part would be a single voice, the outer part 

would have as many voices as you need and takes care of the muting of 

Andy Brennan schrieb:
> Does anybody know of any way I can adjust my patch to ensure that
> that processing only occurs when there is signal to process?

As you pointed out yourself already, the testing part must not be muted. 
Muting will only be worth it, if you have to mute a lot...
Your example does not fall into that category...
If you have real processing going on, you can use nested poly~s, a poly~ 
within a poly~. The inner part would be a single voice, the outer part 
would have as many voices as you need and takes care of the muting of 
the inner (expensive) part...

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


Quote: Stefan Tiedje wrote on Tue, 08 January 2008 08:08

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

> Muting will only be worth it, if you have to mute a lot...

> Your example does not fall into that category...

> If you have real processing going on, you can use nested poly~s, a poly~

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

I see what you mean. I wasn't sure how much CPU would be saved in my poly~ example. The patch posted was actually an incomplete version. The complete version includes other CPU hungry aspects such as VST effects etc. But yeah now you mention it a nested poly~ containing the intensive stuff would clearly do the trick.

Quote: Stefan Tiedje wrote on Tue, 08 January 2008 08:08
---------------------------------------------------- 
> Muting will only be worth it, if you have to mute a lot...
> Your example does not fall into that category...
> If you have real processing going on, you can use nested poly~s, a poly~ 

I see what you mean. I wasn't sure how much CPU would be saved in my poly~ example. The patch posted was actually an incomplete version. The complete version includes other CPU hungry aspects such as VST effects etc. But yeah now you mention it a nested poly~ containing the intensive stuff would clearly do the trick. 

isn't there some way to tell the thispoly object to wait a certain period of time before muting. maybe its not the thispoly object but i'm pretty sure there is a specific message that says 'wait a certain amount of time before mutin' just can't remember in what context it was.

i'm building a synth and i'm getting clicks in certain situations (might be too lengthy to explain) because voices are muting too quickly.

isn't there some way to tell the thispoly object to wait a certain period of time before muting. maybe its not the thispoly object but i'm pretty sure there is a specific message that says 'wait a certain amount of time before mutin' just can't remember in what context it was. 

At 3:17 PM -0700 1/8/08, Donal O'Brien wrote:

>isn't there some way to tell the thispoly object to wait a certain period of time before muting. maybe its not the thispoly object but i'm pretty sure there is a specific message that says 'wait a certain amount of time before mutin' just can't remember in what context it was.

In some of my uses of poly~, I have a simple delay of a couple milliseconds before I hit busy/mute.

It certainly can reduce some sources of clicking.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

At 3:17 PM -0700 1/8/08, Donal O'Brien wrote:
>isn't there some way to tell the thispoly object to wait a certain period of time before muting. maybe its not the thispoly object but i'm pretty sure there is a specific message that says 'wait a certain amount of time before mutin' just can't remember in what context it was.

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


Thanks for the example, Chris. might have to re-jig things a little but i may be worth it. Ta.

Dynamic Signal Testing in Poly~ for muting purposes.