Actually, personally I use the "mute" button all the time. Perhaps some people don't need it, but me, I often have 3 or 4 different output~ objects in a patch and want to turn them on and off selectively. (I also see sound engineers doing this all the time).
cheers Miller
On Fri, Jan 20, 2023 at 01:41:12PM -0300, Alexandre Torres Porres wrote:
So, I talked to MAX in private, he mentioned he'd expect a mute message as in "mute 0" / "mute 1". That makes sense. I was keeping the bang button to alter the state for backwards compatibility since the last one had a bang instead, but maybe I shouldn't bother with it as I doubt people were using any external controls at all with this, as I also think people will not use it much in the future. So I changed the mute message and removed the bang for the sake of simplicity and to make it less "feature-creep" :)
Find new version attached with a help file (see screenshot below as well). If no other objection is made I can upload this to my documentation branch soon.
[image: Screen Shot 2023-01-20 at 13.40.19.png]
Em sex., 20 de jan. de 2023 Ã s 07:26, Max abonnements@revolwear.com escreveu:
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a mono input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function instead of db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the case it was off.
I kept the same control messages as the current [output~] object, a bang message is still there to mute/unmute. A 'level' message is also still there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button that visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value, set it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute toggle is still on :)
I then added two more messages for external control 'mute' and 'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really useful for day to day usage. See screenshot below and find the patch attached. Please give me feedback to see if I'm going in the right direction. If it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...