Page 1 of 1

outputJack odd behaviour

Posted: Mon May 03, 2021 11:02 pm
by PoohBear
Hi,
I'm new to VMD and Java however I do have a programing background from years back so if my code looks backwards then please excuse me.

Now I just came across this thread and the main part being "You should always write a new value to every output jack on every call to ProcessSample()."
viewtopic.php?f=9&t=592

So prior to seeing that thread I was testing to see if I had to write out the same value every time to the outputJack and this is where things got odd.

Code: Select all

public void ProcessSample()
{
    // add your own code here
    double tempout = outputJack1.GetValue();
    if (tempout!=2.5 || count<1)
    {
        outputJack1.SetValue(2.5);
        textLabel1.SetText(count+"");
        count=count+1;
    }
 }
Using the above code.
1st pass, the loop is executed (as expected) tempout=0
2nd pass, the loop is bypassed (as expected) tempout=2.5
3rd pass, the loop is executed (hmm) tempout=0
4th pass, the loop is bypassed (oh) tempout=2.5
and so on and on. I did not expect this.

If I change the "count" from count<1 to count<2
1st pass, the loop is executed (as expected) tempout=0
2nd pass, the loop is executed (as expected) tempout=2.5
3rd pass, the loop is bypassed (as expected) tempout=2.5
and from here on out it's always bypassed. Interesting..

Is there a technical reason to why when setting the out value twice in a row it's taken?

Re: outputJack odd behaviour

Posted: Tue May 04, 2021 12:32 am
by Cherry Dan
PoohBear,

As you mentioned, you need to write a value to a jack with one or more cables plugged in to it at every ProcessSample() call. If you don't, as you're seeing, the results are undefined. Worse, you're calling GetValue() on an output jack, which also has undefined behavior.

Just like with hardware, you always want to output a new value on ever ProcessSample() call, regardless of what the previous value was. Among other reasons, cables can be added, moved, or removed at any time, so you never want to assume that the last value written is 'good enough.'

- Dan @ Cherry Audio

Re: outputJack odd behaviour

Posted: Tue May 04, 2021 7:13 am
by honki-bobo
Hi PoohBear,

one more thing:

Don't update GUI elements in ProcessSample()!
Write the content you want to display in the text label to a variable and then use the GUI_Update_Timer to update the text label. This has WAY better performance since you don't update GUI elements at audio rate.

Best regards,
Martin

Re: outputJack odd behaviour

Posted: Tue May 04, 2021 9:11 am
by PoohBear
Cherry Dan wrote: Tue May 04, 2021 12:32 am As you mentioned, you need to write a value to a jack with one or more cables plugged in to it at every ProcessSample() call. If you don't, as you're seeing, the results are undefined. Worse, you're calling GetValue() on an output jack, which also has undefined behavior.
That's cool, just wanted to make sure my system was not playing up or I was not going mad (more mad LOL)..
Also, Good to know I can't use\trust the data from GetValue on the output jack.
FYI I only was doing it this was for this post, originally it was going off to another input jack and just wanted to simplify it.
honki-bobo wrote: Tue May 04, 2021 7:13 am
Don't update GUI elements in ProcessSample()!
Point noted however I was doing that purely for debugging only.... :D


BIG Thank you....

Re: outputJack odd behaviour

Posted: Sat Jun 08, 2024 3:59 pm
by seal58
Cherry Dan wrote: ↑Tue May 04, 2021 2:32 am
As you mentioned, you need to write a value to a jack with one or more cables plugged in to it at every ProcessSample() call. If you don't, as you're seeing, the results are undefined. Worse, you're calling GetValue() on an output jack, which also has undefined behavior.
I've just got fooled by this case and saw a defined behaviour:
GetValue() used at an output delivers the value which was set with SetValue() when a cable is connected to this output, otherwise GetValue() delivers 0. Same is with polyOutputs.

Reading from outputs is a method, I could see several times in PLC programs. It's not a clean method, but it's technically correct because finally each PLC output is a register / latch.

Now this theme is some years ago and unfortunately I forgot about it. :oops: