outputJack value is not transmitted to reconnected cable

[seal58]

Hi,
my new module is very simple. It contains some push and toggle buttons and output jacks in order to provide some trigger signals. If a button is pushed or a toggle button is on, it's output jack provides a constant value of 5.0 (volts).

Basically all works fine. If I connect such an output to an oscillator cv input, tone frequency can be switched between two values.
But if I disconnect this cable from an active output jack and reconnect it, not any output voltage is delivered to the cv input. I checked that output voltage with the Voltage Analog VU-Meter. It's the same as with the oscillator.

Instead of my own module then I used Voltage DC-Source module. Then it works also when reconnecting the cable.

So I checked my Java code once more. I added some code where I used Notify() methods Jack_Connected and Jack_Disconnected. Even that didn't fix the problem.

Until now I assume, that all cable management is done by the Voltage system in the background and I only have to set output value with SetValue(). May be, I'm wrong, and I have to program some more code myself.
I would be happy for any hint to fix that problem.

[Captain]

EDIT: The the ”idiot proof” way is the correct one

True, seems like the value of an output jack is reset to zero when you connect & reconnect the cable. I suspect this might be on purpose, but anyway, I tried the following inside the Notify() method, and it seems to work just fine:

Code: Select all

case Jack_Connected:   // longValue is the new cable ID
{
	outputJack1.SetValue(5);
}

Another (idiot proof) way is to just write the current value to the output jack(s) inside ProcessSample(), although it's of course slightly less efficient.

[Cherry Dan]

You should always write a new value to every output jack on every call to ProcessSample(). It is not OK to write a single value and expect that value to remain "on the jack", as that's not how jacks work. Multiple cables can be plugged and unplugged from jacks at any time, and you should never assume that a value will remain on a cable.

In short, on every call to ProcessSample(), be sure to write your value, even if it's a constant, non-fluctuation value.

Thanks,
Dan

[Captain]

You should always write a new value to every output jack on every call to ProcessSample(). It is not OK to write a single value and expect that value to remain "on the jack", as that's not how jacks work. Multiple cables can be plugged and unplugged from jacks at any time, and you should never assume that a value will remain on a cable.

In short, on every call to ProcessSample(), be sure to write your value, even if it's a constant, non-fluctuation value.

Yep, that was my impression too. In fact it was a surprise to me that you could even set the value only once, and it stayed there longer than just one sample cycle. But good to get a confirmation that setting the jack values on each ProcessSample() call is indeed the proper way.

[nekomatic]

True, seems like the value of an output jack is reset to zero when you connect & reconnect the cable. I suspect this might be on purpose, but anyway, I tried the following inside the Notify() method, and it seems to work just fine:

Code: Select all

case Jack_Connected:   // longValue is the new cable ID
{
	outputJack1.SetValue(5);
}

Another (idiot proof) way is to just write the current value to the output jack(s) inside ProcessSample(), although it's of course slightly less efficient.

Not sure if this is a good idea. there is a good chance the Notify() and ProcessSample() run on separate threads... The idiot proof way is actually better, it gives you full control on the actual time you putting the value in and is more predictable performance-wise. There are many ways to optimise performance of the Java code, the most elegant ways are usually not the best ones
I would even argue that a well optimised code does not need obfucsation

[seal58]

Hi,
thank you very much for fast and helpful response.
Now I programmed an update of outputJack values in every ProcessSample() call and function is as it should be.

I anticipated that an outputJack value stays until it is changed with SetValue. If it is not, that's a bug, from my view. For every access outside of my code it should have "read only" attribute!

Now, as I know it, I will proceed "idiot proof method" in my modules instead of saving unnecessary operations.

[nekomatic]

I think the best way to think of it is that the ProcessSample() acts as a pump which passes a values between the cables... you have to pump something otherwise the cables will run empty

[seal58]

Good idea!