Hi,

I'd like to build a mixer with stereo inputs, with mono compatibility, as an GOP abstraction.
The ideal behavior would be: if only the Left input is plugged, then copy the signal to the right channel.

Is there a way to detect if an input is plugged or not?

I was thinking of using env~, but it doesn't sound like a good practice for that use case.

Thanks

@ludnny There will be a little bit of noise on the unplugged channel..... but as it is by definition unpredictable I don't think that will help.
You could use [env~] and latch to mono when an input is below a certain level..... but what if a stereo signal starts or goes to a hard pan left or right and then returns to stereo.
The best way to achieve it would be in hardware...... using 2 mono jack sockets with open / closed contacts. Most sockets have them.......
Connect the contacts that lever up when a plug is inserted to the switched contact of the other....... and then both inputs will be fed by whichever jack is plugged in........ and they will be independent when both are plugged.

Use stereo sockets if the mono inputs are balanced line.
David.

@ludnny consider M-S encoding? (probably too outside the box.....)

@whale-av said:

@ludnny There will be a little bit of noise on the unplugged channel.....

I believe the question is simply about an inlet~ where "unplugged" means the user hasn't connected anything.

I think I had asked about this once upon a time and the answer was that there's no way to distinguish between a silent inlet~ and a disconnected one.

hjh

@ddw_music Yes. An [inlet~] just sends a stream of zeros when disconnected or receiving no signal. So no way of determining whether it is disconnected or not.
An [adc~] will send some noise when disconnected..... background noise, maybe some tone from the processor clock. I was toying with the idea of identifying that but it will be random and different for every users soundcard so I abandoned the idea.
@jameslo Good thinking....... but unfortunately (!/?) the reconstructed signal would be faithful to the original.
David.

since pd 0.51 it is possible to set a default value for [inlet~]. So instead of zero [inlet~] can send some unreasonable value against which you can check if there is a connection:

Thank you all for the super creative ideas

The patch by @solipp is working perfectly, many thanks!

@whale-av said:

Yes. An [inlet~] just sends a stream of zeros when disconnected or receiving no signal.

i find that a weird behaviour.

@Obineg Not really very surprising.
Digital audio samples at 44.1kHz sample rate are values (numbers) arriving at a precise time.
When the audio is active (DSP on) an audio object like [inlet~] will send a value at each of those times...... and if there is no signal that number has to be zero.
David.

i am saying that as a max user. the part which is weird is that an inlet is a signal object anyway.

@Obineg I don't know Max.
There is [inlet]....... a control rate port..... and [inlet~]..... an audio rate port,, in Pd.
They are used to create inlets for sub-patches or abstractions so that a patch can be used within another patch and connected by "cords".
Of course [outlet] and [outlet~] too.
And of course [send] [send~]....... etc. for connection without cords but they then need names (arguments) to define the routing.
avid.

the difference gave me a lot of headache already converting some of my patches.

i would have found it more logically that inlet~ would only get activated when you connect something to it, since patching requires a recompile anyway.

the way it is you are creating a lot of signal connections for nothing for some abstraction designs.

and dont worry, i can assure you that from a pd perspective the way inlets work in max are even more weird.
setting a default value for a signal as shown above is for sure easier in pd.

@Obineg said:

i would have found it more logically that inlet~ would only get activated when you connect something to it, since patching requires a recompile anyway.

the way it is you are creating a lot of signal connections for nothing for some abstraction designs.

A counterexample:

Let's say you're making a mid-side encoder abstraction: two signal inlet~'s (left and right), and a [+~] and [-~]. The left inlet~ goes into the left inlets of the two math operators; the right inlet~ goes into the operators' right inlets. So the adder produces the mid signal, and the difference operator produces the side.

Now you put the abstraction into another patch, and connect a signal to the abstraction instance's right inlet.

By your logic, the operators' left inlets should be deactivated. But the operators still need to calculate. (Passthrough isn't an option because, in this contrived example, the [-~] side signal should be phase inverted relative to the mid signal -- the [-~] must be doing 0 - R.) To calculate, the operators need two inputs.

At this point, software designers would have to weigh the CPU cost of passing zeros (arguably this is likely to be minimal) against the added complexity of maintaining active vs inactive connection states. Considering that it's easy to underestimate the maintenance impact of code complexity, it actually is a legit decision to accept a small CPU cost in exchange for more straightforward logic.

I don't find it strange at all.

hjh

of course i was more thinking about abstractions with 64 inputs of which you would often only connect only a few of them.

about your example... no idea how that same implementation would perform in pd? but in max, if you´d cut off a signal objects from DSP, for example by shutting down a subcircuit, the last value of the now stopped signal would remain in the input buffer of all connected objects.

it would not jump to 0 because there is no signal and it would also not snap back to the a possible default value of [~*]

so how about this?

one reason why i find it "strange" is that it causes an inconsistency between the externals paradigm and the patch paradigm, since you cant have inlets in your abstractions which takes both signals and messages.

.

@Obineg said:

one reason why i find it "strange" is that it causes an inconsistency between the externals paradigm and the patch paradigm, since you cant have inlets in your abstractions which takes both signals and messages.

In fact, you can connect a control to a signal-rate inlet~.

This abstraction is kind of dumb, but it makes the point:

Then, here, the left-hand side patches random numbers (generated in the control domain) into the slot defined by the signal-rate [inlet~]. And, the right-hand side patches a signal-rate LFO. They both work.

What would not work is to patch a control and a signal in simultaneously: the signal will overwrite the control.

about your example... no idea how that same implementation would perform in pd? but in max, if you´d cut off a signal objects from DSP, for example by shutting down a subcircuit, the last value of the now stopped signal would remain in the input buffer of all connected objects.

It appears that, when you connect nothing to [inlet~], it already holds its last value and doesn't reset. You can test that, in the sample patch above, by deleting the signal connection into the right-hand side instance of the 0529 abstraction. If it went to 0, then the right channel would be silent. Instead, it holds frequency.

So it seems it already works as you specify. (That's different from what whale-av said -- which is understandable -- as others point out, Pd help patches lost some key details so it's easy to get confused about this kind of fine print.)

This also means that there really is no reliable way to tell if something is connected or not. You can specify an initial value for the [inlet~], but if you connect something and then delete the connection, this initial value will be lost and not reset.

hjh

aha, so they take messages when you name them?

[quote]What would not work is to patch a control and a signal in simultaneously: the signal will overwrite the control.[/quote]

haha, in max it is like that:

most externals take signals and messages at the signal inlets.

if you connect a signal and a number to math objects like +~, the number would multiply the signal value.

if you want to connect signals and messages to an abstraction, you have to use something like [route start stop int float] inside the abstraction - the signal will come out of the "does not match" output of [route].

to complete the magic, you can pack signals into named connections using [prepend stereoL] [prepend stereoR] [prepend modulation1] [prepend modulation2] and then you can send all 4 signals through one connection into the subpatch.

you can also mix different types of connections that way.

...

regarding the problem of the OP:

in max i made myself abstractions to enhance the function of inlets and outlets, where you can send a [metro 3000] into using s/r in order to find out which inlets are connected and which not.

in theory one could do that with audio, too, and add a pulsetrain of + 1000. to a stream, later decode the stuff by modulo 1000.

@Obineg said:

aha, so they take messages when you name them?

no, they take messages in general. "naming" inlet/outlet is considered bad patching style.

if you want to connect signals and messages to an abstraction, you have to use something like [route start stop int float] inside the abstraction - the signal will come out of the "does not match" output of [route].

I prefer the pd method; [inlet~ fwd]. It is documented in the helpfile.

@ddw_music said:

It appears that, when you connect nothing to [inlet~], it already holds its last value and doesn't reset. You can test that, in the sample patch above, by deleting the signal connection into the right-hand side instance of the 0529 abstraction. If it went to 0, then the right channel would be silent. Instead, it holds frequency.

? if I could reproduce this, i would file a bug report on github. because this would be undesirable in many situations. However, i can't reproduce it. I wonder why it works for you?

@Obineg said:

aha, so they take messages when you name them?

Anything put after the name of an object is an argument, as of now [inlet], [outlet] and their audio rate counterparts have no arguments to pass too so you can safely name them, the name just ends up as an unused argument. The problem with this is that someday Miller may decide to give these objects arguments and now your named inlets and outlets all fail because that name will be passed as an argument. So best practice is not to name the objects directly with arguments but indirectly with comments.

Edit; Forgot, [inlet~] and [outlet~] do have arguments so names here could have unexpected results. [inlet] and [outlet] are still argumentless.

@solipp said:

no, they take messages in general.

seems i was a bit confused yesterday, nevermind that.

@oid said:

So best practice is not to name the objects directly with arguments but indirectly with comments.

Well, the best would be to give properties to inlets and outlets, including a name, and then in the parent patch, show tooltips when hovering over the corresponding hockey puck.

hjh