MSP Possible to enable a permanent DC blocker?

Workaround: Make an abstraction "out-dc~.maxpat" with inlet -> svf~ -> dac~ (using highpass output). Then (unix commandline)

So that (in theory) all the patches should then open using my abstraction instead of the normal dac objects.

This seems a rather humorous way to go about it but at least I will be less frightened of opening the patches.

hjh

(Which, btw, doesn't work for ezdac~ -- it's OK for a "newobj" to change text from dac~ to out-dc~ but there's no maxclass out-dc~... but a broken dac still blocks bad output, so, OK.)

hjh

why shell command? you could remove dac~ and ezdac~ and rename your abstraction to dac~ and ezdac~.

or what about making a json droplet editor which changes dac~ and ezdac~ to mydac?

or use a AC coupled DAC...

> you could remove dac~ and ezdac~ and rename your abstraction to dac~ and ezdac~.

Hm, even if it were possible to remove them, the abstraction would have to be defined in terms of dac~. So, if the name dac~ could refer to an abstraction, and that abstraction references dac~, the likely possible outcomes would be either: Max refuses to load an infinitely recursive patch, or it tries and eats all the memory.

The point really is that it would be a nice feature to have. In SuperCollider, I can add a function to ServerTree to put a DC blocker at the tail of the node tree. Pd, AFAIK, doesn't have a good way (but there's an abstraction [pddp/ezoutput~] that covers it). In Max, note for future, train students not to use dac~ etc directly.

hjh

okay i admit removing it was a bad idea. :P rather you had to rename the real dac~ to something else and keep it installed, then you can include it in your new dac~ abstraction.

the issue is indeed caused by "too much flexibility". if the patch has audio on by default and your runtime also already has audio on, there is nothing you can do to stop audio in that new patch, except making sure to turn audio off before manually.

the question then is who do you trust more: yourself or your students. seriously, i would just replace dac~ with mydac~ using bbedit for incoming patches.

or ad dc blocking capacitors between audio out and amp, in case that dc can pass, which is quite doubtful.

you could create a basic 'snippet' and ask students to download it and use it(it could be as simple as a limi~ object right before the ezdac~ with @dcblock set to '1'... and whatever threshold plus other settings you think would be safest). this would be the patch they'd "(in theory)" (hopefully even somewhat religiously) use before sending anything else out to the dac. this would also be a good habit to get them into as it'd protect all their other setups outside of school the best(even from wayward patches posted by random strangers on places like slack, discord, reddit, etc...), while there's no magical solution that will protect that specific system at the school from every possible context, educating/training students into these good habits(as they exist all within max) could protect every system running max they may ever run into.

Good suggestion about sending a snippet to the students... although it's too late to implement for this term.

I don't think Max should block DC by default (for instance, if someone is sending control voltages out from a DC-coupled sound card to modular gear, then you don't want sub-sub-sub-audio frequencies to be cut). So this is really "precautions you didn't think about until it's too late." FWIW neither SuperCollider nor Pd recommend safety-first practices in the documentation either.

hjh