Patch Audio In if unconnected

My Daisy Patch will use the Audio In from lower inputs if the actual input is not connect.

Lets say I want to read in audio 4 but nothing is connected to audio 4 - I’d want the result to be 0. Unfortunately I hear the output of whatever is connected to any of the inputs 1-3 (if they are connected).

Is this supposed to be like that? Is there at least a way to query if - in my example - audio 4 is connected or not so I could nullify the input?

My code is basically just this in to out:

static void AudioCallback(float **in, float **out, size_t size)
    for (size_t i = 0; i < size; i++)
		for (size_t chn = 0; chn < 4; chn++)
			out[chn][i] = in[chn][i];

There’s input normalization on Patch, see this explanation

Why? Is there a simple way to undo this (not having to add patch cables in unused slots)?

I wonder why it was decided these should be normaled?

I’m struggling to find a reason why this would help anyone too. It might make sense for an analog unit to save patch cables or mults. But as the Daisy is a digital unit I can virtually ‘connect’ any input to another one with just one line of code.
Not sure if I really want to replace the audio jacks or add solder connections to ‘fix’ this.

I don’t think that this can be defeated by adding anything.

In the thread mentioned above @Savox points out “If you didn’t want that behavior, you can either buy non switching jacks, or simply ground the switch connections.”

Yes, that’s what was written. But it’s not correct. If, for instance, you ground the switch connection on the Audio Input 2 jack , it will ground Audio Input 1, which is NOT what you’d want.

The easy workaround, if the normaling isn’t want you want, is to plug a TIP-SLEEVE cable into each unused input. Better still would be to create a few TS shorting plugs, wired TIP to SLEEVE, and use one of these in each unused input.

I still wonder what the designer had in mind, or if this was just a mistake.

It’s a bit of a sad solution but works:

Just cut one regular patch cable and using only the ends to disconnect the inputs.

1 Like

That’s a perfectly good, crude solution.

I’d love to have a Daisy Patch.

I am curious - what are you trying to do that requires unused inputs read 0?

I guess as soon as you run different functions on different inputs it becomes an issue.

Simple example would be to have the second input trigger a gate every time a threshold is reached (e.g. for sidechain compression) and use the first input for something else (a delay, distortion, etc).
If I disconnect the second input, I don’t want to have the gate triggered by the first channels delay source.

Not sure in which use case it would be helpful to have the signal ‘copied’ onto empty inputs.

100% agreement. The sidechain example is excellent.

Basically anything you want to use the inputs independently and have no output (audio or gate) if nothing is connect.

Could also be a distortion on Input 2 going out of Output 2 (while input 1 still does it’s delay into output 1).

I completely agree. Another example, the Patch could be programmed as 4 completely independent 1-in/1-out processors, reverbs, delays, shapers, etc. Or any combination of independent devices using any combinations of the 4 ins and 4 outs.

I’m convinced this normalizing is a mistake. Somebody should check if the traces for this are accessible - they should be cut. Even better would be revising the board to short unused inputs to ground.

That was the basic concept behind Olearia originally, though it’s now 2x2 instead of 4x1. I ran into some issues with normalization and didn’t even realize that was the issue. I’ll go back and look at some of my older code to see if that was the problem.

I’d imagine you can write something on the software side to detect if one input is a duplicate of another?

Yes, you could test for excessively close correlation on two inputs, but then you still won’t know which one has a cable plugged in.

I don’t have Patch, it’s more than I want to spend. But somebody should see if these traces can be cut. This ‘feature’ wasn’t well considered.

@andrewikenberry - any comment on this?

The original intention was for things like multi-effects and filters where you’d plug one audio source in and get 4 new signals. You could then patch additional inputs in to override the signal at input 1. A simple example would be a multi-mode filter (lpf, hpf, bpf, npf), where you can use it as a 1 input to 4 output or just as 4 independent filters.

At the time of design we had more examples of things where this would be desirable, and the only thing you needed to do to break the normal is plug a dummy cable into the first input you didn’t want used. When compared to requiring an external multiple and 4 extra patch cables to achieve the equivalent normaling, we decided to leave it normalled on the hardware.

It’s worth mentioning that you don’t need to cut a cable or anything, you can simply insert one end of a patch cable that doesn’t connect to anything else into the first jack that you don’t want to pass down, and it will stop the normalling from moving any further down.

1 Like

Thanks @shensley for clarifying.
The reason why I didnt want to just have an open cable connected was that I was worried about noise or humming if the open end touches anything.
“When compared to requiring an external multiple and 4 extra patch cables to achieve the equivalent normaling, we decided to leave it normalled on the hardware.” — I guess that could have been achieved with four lines of code too - right?