Detect if inlet is connected

#1

Is it possible (in the object code) to detect wether an inlet is connected or not?

#2

no.
the only thing you know/can rely on, is that it is zero if its unconnected... but you cannot differentiate between this, and an inlet with a zero input. (if you know what i mean :wink:)

(I agree though it would be useful, but I suspect might be hard to change without affect existing patches/objects, which now assume unconnected = 0)

#3

Ok, that's too bad. I'll either make two objects or a switch to /use/disregard the input...

#4

If it could be made to work, this would be quite useful, I think. It's essentially like normalising a physical jack socket to a fixed voltage. Done a lot in Eurorack-land, and pretty useful.

a|x

#5

I consider adding this in the future, the main puzzle is how to make this visible to the user? The inlet should have some sort of visual marking when the unconnected situation is a different value than zero. Would it always be maximum value? If it has a different value, it also should be systematically clear to the user.

#6

If you're talking about the user of the object (as opposed to the developer of the object) I don't think it should be visible to him. The whole idea would be to code the object in such a way that it "just works", no matter how you patch it up. Sure it would behave different when something is plugged into the inlet (or possibly outlet), but in an elegant way handle what ever way the user chooses to patch it up.

Eurorack modules have already been mentioned, and I come from this myself. Here it's quite common to "normal" an input to some internal signal, and when something is plugged in, the input takes preference. For instance a sample and hold module. It's input could be normaled to an internal noise generator, but when the user plugs in her own signal (either a noise, lfo or other cv generator) this signal is used instead. This way the module is self contained (no noise required), but open for deeper use when the user would like to explore other possibilities.

In hardware it makes a 200 euro module more versatile, in axoloti it would make the same object more elegantly adapt to more use cases. The obvious alternative in axoloti is to provide a wide array of object, one for each scenario. Of course code is cheap, but it will clutter the library with all the variations of what is essentially the same object. And make development, maintenance, bug fixing much harder.

#7

So just to make is clear: I'm looking for a way in the object code to make the object behave in one way when the inlet is connected and another when it's un-connected. Somethings like:

if(inlet_note_connected){
   //do something
} else {
   // do something else
}
#8

I think the intention is clear...
actually, Ive realised its probably not that hard to implement, as this can all be done at code generation time (since you cannot attach a wire whilst is running) , this is useful since it will also means the optimiser can eliminate the path that is not used. (we just need to be careful that the default unconnected state is as it is today (=0) so we dont break existing patches.

#9

I understand what you mean, but I'm not immediately convinced: in your example of S&H with noise source, you may also want to expose the noise signal as an outlet (to connect to another S&H for stereo), or I think there should be a clear way to reach exactly the same outcome with a separate noise generator to feed into two S&H objects for stereo. The former becomes the equivalent of two objects in one, the latter duplicates the noise generator code. It could also clutter the library with object variations: S&H+noise, S&H+lfo... so I think it is best only used for constants.
Another question is how to present this visually so users get a cue that it is a normalling inlet without reading documentation, this gets more complex if it is more flexible than a constant value.
It certainly makes sense in Eurorack, where swapping a module needs a screwdriver, and is limited to what you physically own, and the cost/space equation drives towards maximizing the features per square inch of eurorack frontpanel.

#10

I think that would be a shame personally, I think its quite interesting to have internal operations.

if its was just for constants, id argue that you dont need it... instead use 'reaktors' model, which has an easy 'one click' method (a bit like a comment) to add a constant to an inlet. (this has the advantage of better documenting a patch)

Is that necessary?
the current behaviour, which is the inlet is 'normalled to zero' is also arguably arbitrary, similar when you connect something that is also a parameter, its only by convention 'summed' - personally, I think it should just be part of the documented behaviour.
as you suggest in the second part, I don't think you can in many circumstances visually show a normalled behaviour.

I understand the desire for it to be visual... but Im not sure it gains much.
at the end of the day, I think its down to the 'object designer' to make sure normalled inlets make sense.
(arguably thats kind of the true of objects generally e.g. param/inlet name)

EDIT: actually the last point, I think is the crux
there are different ways modules can be created, different design philosophies , e.g. normalising to an internal clock, or providing a clock input
BUT the crux is... I dont think axoloti should 'force one approach or another' (for user objects, factory objects being consistent is a different discussion :)) ... I think we should allow the designer flexibility, and users and determine what they like :slight_smile:

#11

It's becoming more a framework development discussion than an object coding discussion...
Let's collect use-cases:

1) midi/out/note defaults to velocity 0 which results in a note off, while maximum velocity value would be more convenient
2) An inlet scaling parameter becomes an offset parameter when the default inlet value would be maximum. This is nice because the inlet scaling parameter is useless when the inlet is 0. But it would generate a useless multiply in the code if the inlet value is only substituted with a constant, it would be cool if this could be eliminated. A test for presence of connection on an inlet - as suggested above - can do that. Might also be interesting to do that more systematically, when developing parameter/inlet duality.
3) S&H with noise generator, normalling the inlet to the noise generator
4) insert point in a mixer (?) Such topology implies a one-buffer delay because of the feedback path, not sure if this is really a desirable design pattern, it would need latency compensation on channels that do not use the insert point.

There are also (still more hypothetical) cases where an unconnected inlet may imply a connection to a default source object:

5) LFO with a sync input, that syncs to a global master clock or MIDI clock slave when unconnected
6) A custom tuning inlet, that, when unconnected defaults to 12-tet/440Hz tuning, or a different tuning object for just intonation.
7) When MIDI data routing becomes cabling, it would also save a lot of connections if those inlet types default to a global source

More use cases?

#12

Yes:

I'm working on the quantizer. I'd like an inlet that forces the quantizer to only update when a pulse here is received. If not connected, the quantizer should update when ever the note input changes...

#13

global transport / tempo

but yeah, I think you've got general cases there

normalise to:
- constant (non zero) - 1,
- internal source/logic (noise/lfos/clocks) - 2,3,
- external (global) source (midi/master clock/master transport) -4,5,6,7

what I really like about this, is the optimiser will be able to yank out code paths not in use. (as they will be unreachable)
( ok, this is probably the case with inlet=0, if you are careful)

#14

what you could do is to add a function that checks whether the input has changed. If the patch is started and the input remains unchanged, then it uses the internal parameter. If the input changes once, it switches over to external use.

But then again, why not just add a (toggle-)switch, allowing the user to choose which kind to use?
-only internal knob
-internal knob+inlet
-inlet attenuated by knob