DSP Robotics Support

Hi folks, I'm currently having some trouble with the stock ADSR module (the graphic one). I had basically wired it up to my poly streams using multiplexers and a switch to act as a bypass. I found out that my project was not sounding right, and I traced it back to this ADSR module.

So here's the weird stuff. Even when bypassed, the module effects the audio. I put poly readouts on the inputs and the outputs and they all read zero, with the exception of the "envelope" output, which was putting out data (so the module was at least still reacting to poly streams, although this output was not connected to anything). Even once I start disconnecting the module's input the issues persists, up until I pull off the last connection on the output, then things would go back to normal.

So in short, the module is inappropriately effecting poly streams even with nothing connected to the inputs as long as the output is connected somewhere (even though the output is reading zero).

Testing now it also happens with the other ADSR module (the knobs only one, which uses a DSP code block instead of the ADSR4 primitive).

Does anyone know what the heck this is all about? My project requires ADSR.

I can conclude from my limited understanding that anything connected in Poly, even if the inputs are empty, will instantiate with each poly voice. But that doesn't explain to my why it's ruining my audio output when the module is outputting a steady 0.

Default your module/primitive is compiled as long as at least one of it's outputs is connected to some sort of output primitive (be it poly to mono prim, soundcard output or mono to float prim), the inputs doesn't really matter at all (when you disconnect it, it is simply considered zero). That explains why the bug persists when you have at least one of the outputs connected (even if it should do nothing)


Only thing that comes to my mind is the envelope control primitive. It is used for custom envelopes - outputs envelope stage and receives kill voice boolean and it is up to you to create the code for the envelope itself. It is the only thing that the modules have in common.

I've circumvented the issue by using selectors on the outputs instead of multiplexers on the inputs. That way the ADSR outputs aren't being summed with the "dry" poly stream. Bizarre thing though.

Perfect Human Interface wrote:I've circumvented the issue by using selectors on the outputs instead of multiplexers on the inputs. That way the ADSR outputs aren't being summed with the "dry" poly stream. Bizarre thing though.

If you want to shut anything off you should always use selectors, as a bonus they save CPU.

The outputs on multiplexers hold there value so don't default to zero, which is desirable for most cases. They are not designed for the way you was attempting to use them.

That's really good advice, thanks.

Exo wrote:

Perfect Human Interface wrote:I've circumvented the issue by using selectors on the outputs instead of multiplexers on the inputs. That way the ADSR outputs aren't being summed with the "dry" poly stream. Bizarre thing though.

If you want to shut anything off you should always use selectors, as a bonus they save CPU.

The outputs on multiplexers hold there value so don't default to zero, which is desirable for most cases. They are not designed for the way you was attempting to use them.

Very nice advice, thanks I have been struggling with the very same situation. I was sure that i did something wrong, but with your explanation above it makes good sense.