Kasper

when using mute~ (and pass~) can teh mute~ be connected to an unused 

inlet of the sub-patch ?? I mean an inlet connected to nothing - my 

sub-patchers have no input. Or does it need to be connected to 

when using mute~ (and pass~) can teh mute~ be connected to an unused 
inlet of the sub-patch ?? I mean an inlet connected to nothing - my 
sub-patchers have no input. Or does it need to be connected to 
somethnig "real" ???

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

mute

i'm sure you've figure this out by now (it's been four years...), but for anyone who's wondering (like i was just now): yes, it seems mute~ will function properly even though connected to an inlet that is in turn not connected to anything in the subpatch it serves.

i'm sure you've figure this out by now (it's been four years...), but for anyone who's wondering (like i was just now):  yes, it seems mute~ will function properly even though connected to an inlet that is in turn not connected to anything in the subpatch it serves.


Please note that pass~, mute~ and begin~ are DEPRECATED. For controlling audio processing in a patcher, please use the poly~ object.

These objects will no longer receive any engineering love in the event of problems.

Does the same apply to the enable/pcontrol type of DSP muting in terms of deprecation.

i was running into a similar problem but now that i'm actually getting acquainted with poly~ i can really see its strength and benefits.

If nothing else, you can set polyphony on the run, depending on your CPU strength. :)

pcontrol is slower than mute~.
i was running into a similar problem but now that i'm actually getting acquainted with poly~ i can really see its strength and benefits.
If nothing else, you can set polyphony on the run, depending on your CPU strength. :)


I mainly use it for muting DSP heavy sections of my patch (that aren't polyphonic anyways). I only recently discovered mute~, so it would suck to have to go back to making a poly for each module of my (already massive) patch.

Yeah, probably. The only problem mute~ has its with 3rd party externals and sub patchers if I recall correctly.

I've been having a problem where my DSP is blowing up, and it seems to be coming from two modules that are using mute~. I've not fully figured out when/why it happens, but I'm gonna wrap them in poly's to be safe.

The concern is with deprecation, as it's a very useful feature for muting DSP without having to go through a ton of work to poly-fy something.

Its not actually ton of work, and its easy to bypass it, if you enclose a single patcher... But i forgot how. Can be used almost as mute if i recall

It's not too bad, just have to rename everything from 'inlet' to in~ 1' etc.. and then save it as a separate file, but it then makes updating/tweaking the overall patch more difficult as everything becomes segmented and has to be edited separately.

Also means my main patch is now 28 files (most of which are DSP muting polys).

It's not too bad, just have to rename everything from 'inlet' to in~ 1' etc.. and then save it as a separate file, but it then makes updating/tweaking the overall patch more difficult as everything becomes segmented and has to be edited separately. 

Also means my main patch is now 28 files (most of which are DSP muting polys).


https://cycling74.com/forums/poly-trouble-2

last post here is what i couldn't remember 1 month ago, thanks @roman

Could you upload an example of using poly~ for DSP? I'd like to see if this would solve a problem I have with CPU usage in a patch.

It's a matter of changing the naming of inlet/outlets to using [in 1] or [in~ 1].

A good way to use this is to use prepend/route so you only have a minimal amount of inlet/outlets in your poly, and then route the messages to where they need to go after that.

It's a matter of changing the naming of inlet/outlets to using [in 1] or [in~ 1]. 

A good way to use this is to use prepend/route so you only have a minimal amount of inlet/outlets in your poly, and then route the messages to where they need to go after that.


but that only works if you're using a poly~?

I've not used poly~ for DSP so I need to think through it a bit more.

but that only works if you're using a poly~? 

I've not used poly~ for DSP so I need to think through it a bit more.


Poly is the only way to do it really (other than specialized externals (ie Harker's dynamicdsp objects)).

The hardest part for me of getting used to it was managing what I wanted to mute, and how I wanted to communicate to it. Hence the use of prepend/route.

Poly is the only way to do it really (other than specialized externals (ie Harker's dynamicdsp objects)). 

The hardest part for me of getting used to it was managing what I wanted to mute, and how I wanted to communicate to it. Hence the use of prepend/route.
