@LarsXI Yes, I thought adding a small dc offset could work. The problem is that the 0 (connection) needs to be multiplied by the offset.... as all audio inlets add the two signals it needs a [*~] but that will not detect if the connection is removed as it will continue to multiply by zero.
It can be done if the same offset is applied to both sides of the connection, but of course any signal present on either side will falsify the result......... insert.pd
I have not found a way to test for zero yet. A change from no signal (zero) to signal zero will not trigger any audio logic objects.
David.

@palaver Ok...... sorry I was a bit snappy.
You could use [env~] for signal, but connection might be possible.
I can't remember straight away, but audio objects send a stream of zeros that could be detected?..... except [throw~] does not when a sub-patch has its audio switched off..... will have to sleep on that.
David.

@EEight I haven't tried it, but I found this a while ago...... https://www.vb-audio.com/Cable/
LoopBe also do one.... https://www.nerds.de/en/loopbeaudio.html

If you want / need something serious, and don't mind paying, https://www.audinate.com/products/software/dante-virtual-soundcard
David.

@palaver As you are making the decision as to whether the insert should be live or bypassed I don't understand why you need signal detection.
I.E. on a real console..... you have plugged it in because you want it, or you haven't.
The bypass toggle can of course be sent a message from your master patch panel.
David.
insert.pd
Sorry, I have just modified that, as you need the toggle to have value 1 (bypassed) when the patch is started.

@cocobryce Because it is Apple they will only show it in green...... mac eh!....
Try a different pullover?
Seriously though. Have a look at the backend driver loaded (will /should be shown in the Pd terminal) for clues. You might be able to change it with a [driver something( message to [pix_video]
You should be able to print available drivers to the Pd terminal with just a [driver( message banged into the [pix_video] inlet.
pix_video-help.pd
Compare the list to the driver being used in windows, and if possible the one used in Skype on the mac.
David.

@esaruoho Sorry, long phone call.

That's what I thought (about [*~ 1]. You could try [line 1 1] which will start with a value of 1, and when you send it a message it will "jump" every ms...... but I think you will still get clicks as the level change will be a "staircase" with 5 steps.
[line~] and the loadbang will be better.
David.

@esaruoho I didn't think of that.....!......
Put the loadbang to a message [1( sent into the left inlet of the [line~]

Or maybe you can leave the 1 in your version of Pd. In Pd Vanilla the [*~ 1] will not let you connect an audio signal to the right inlet, only a control signal.
David.

@esaruoho Yes, if you go to 0 in 5 ((... [0 5(.... )) with a [pipe 4] then the offset message is sent after 4 msec..... and the [line~] needs another 1msec to get to zero........ because you sent it the message... go to 0 in 5msecs.
David.

@esaruoho The output from [r p$1-offset] is going to the [+~] after [phasor]........ before [line~] takes the volume down. You need to delay that data with [pipe 4] so that the volume is at zero as the change is made.
David.

@esaruoho Just change [line] to [line~] in your patch (post 18 of this thread I think), and set all the timings to 5ms, and remove the 1 from the [*~ 1] which is just a volume control at the end of the sampler that will duck the audio as the click occurs.
The [1 118( message is far too long, and that is why you hear the sound drop out.
If you upload plom.pd here I can correct it and post it again for you.
David.