MSP Possible to enable a permanent DC blocker?
Sometimes students do dumb things like patch a cycle~ with zero frequency into dac~, without an envelope, so that merely opening the patch passes high-amplitude DC offset to the speakers.
This means that opening a series of student files is risky. (However, I'm not smelling smoke, so perhaps the amplifier is filtering out DC, but I don't have firm documentation of that.)
Is there a way to configure MSP with a permanent DC blocker?
I tried inter-app routing audio MSP --> SuperCollider to get LeakDC into the chain, but the problem there is that Max resets the audio driver when opening a patch, and this destroys any routing that I had set up. (However, I could use this setup temporarily to confirm that MSP is not killing DC by default.)
The only solution I see at present is to remember rigorously to disable audio between patches, and make very sure that I zero the volume before enabling DSP. As this is a manual process, the likelihood of error is very high.
Any suggestions?
hjh
Workaround: Make an abstraction "out-dc~.maxpat" with inlet -> svf~ -> dac~ (using highpass output). Then (unix commandline)
sed -i.bak -e s/ezdac/out-dc/ -e s/dac/out-dc/ *.maxpat
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