Has anyone seen a code fail like this?

[UrbanCyborg]

Got an oddball one. I have a poly input jack on a module that supplies some values generated on another module. This code has never caused a problem in any module before, so I suspected something was corrupted. I uninstalled and reinstalled VMD, but it made no difference. The problem I'm seeing is that when I read from this jack, all its lines are zero, even though I can verify with an external meter that they're not. Reducing the problem to the minimum, the following code fails, when it should not:

Code: Select all

if(bLinkInputJack.IsConnected() == true)
    truth = bLinkInputJack.GetPolyValue(3);

where truth is a double variable. The test executes correctly, transferring control to the next line, but that line doesn't update the value, just returning zero. Has anyone seen anything like this, or maybe has a reasonable suggestion? It may be related that a week or two ago the debugger got kittenish, putting execution points on the wrong lines by one or two.

Reid

[utdgrant]

Have you checked the polyphony count? Do you have it set to at least 4?

(Yes, I know this is just one step up from "Is it switched on?" )


Also, although it doesn't affect anything, testing if a Boolean is equal to "true" just looks ugly to me.
I prefer:

Code: Select all

if(bLinkInputJack.IsConnected())
{
	// Conditional code in here
}

And always put braces around the conditional code, even if it's just one line. Then, if you modify it, you won't accidentally add another line with the same indentation, presuming that it will be subject to the same condition.

But, as I say, it has nothing to do with your current bug! Best of luck!

[UrbanCyborg]

Thanks, Grant. Nope, polyphony is at eight. I usually do full braces; even have my code editor set to auto-generate them. Like I said, this was a reductio not-quite-absurdam.

[seal58]

Hi Reid,

because I've got some trouble with deactivated GUI items, there is my question: Is that poly jack probably deactivated or invisible?

Roland

[ColinP]

Hi Reid,

Presumably you've inspected the incoming Poly signal using Poly to Mono in VM and it checks out fine.

I've seen some flakey behaviour in the VMD debugger so don't trust it 100%.

Therefore I'd recommend writing test code to say light up an LED or not and then publish it so that you can check what's happening in VM proper rather than the VMD test client/debugger.

[UrbanCyborg]

I was wondering if it might be a debugger artifact, as well, and had considered publishing a test version as you suggest, Colin. After a lot of banging around internally, though, I think it may be an issue related to the earlier one we discussed, where it's next to impossible to really know when initialization is completed. Clearly, it may not have completed as of the first call to ProcessSample(), as a test on the presence of the jack at that location says that the jack is present, but the return value is always zero. Putting the same test in every call to ProcessSample(), on the other hand, will eventually start returning a correct value. I've also spotted some instances where some mono CV jacks don't behave correctly until well after the first call to ProcessSample().

Roland, the jack is never invalidated in any way in my code. It's kind of the same thing as Colin's S-jack, although not done nearly as elegantly; there's no reason for it to ever be off, invisible, or anything like that. It either has something plugged into it, or it doesn't. The debugger mostly agrees that there's something plugged in; it just doesn't deal with it correctly.

I really don't like having to put a call to my jack-handling routine in every ProcessSample() call, but I guess I have no choice if it's really working as it appears to be working. I think I'll spend some time today trying to verify whether it happens in VM, as well. Thanks for the feedback, everyone.

Reid

[ColinP]

It would be useful if CA wrote up the VM initialization properly, likewise the threading but I can't see this happening. Maybe they could provide skeletal source to developers who sign a NDA but I can't see this happening either.

So we are left with guesswork and strange bugs. The only way to approach this is to always assume the worst and try to write code that is as tolerant of mishaps as is humanly possible.

One of many examples of this safety first philosophy is related to both initialization and threading - you should always leave starting up timers until the very end of your initialization because there's apparently no locking mechanism. So a timer thread started too early can operate on your object model before it has been fully constructed. You don't see any problems in trivial cases but a large module can take a while to finish initializing and will fall over when your timer thread code attempts to interact with a half-built unstable object model.

[UrbanCyborg]

Roger that, Colin. It would be really nice if CA would supply a notification for when initialization is complete. I'm not sure the Load Preset Begin and Finish notifications quite fit that bill. Just an InitializationComplete() notification would do it.

One thing I've learned, though is that no matter what, notification code shouldn't do anything to generate other notifications; that way madness lies. In regard to that, though, the ability to send a user-defined argument that has a well-defined default value would allow you to know when certain kinds of notification chains were complete; you could test on the value in the notification code and get information about who sent it. The default value would indicate it was system-generated, and anything else would have significance to the user, including indicating which routine originated the notification. For instance, a call to any SetValue() function would take an additional argument of some sort, maybe an integer, with -1 being the automatic default (system-originated), and any other value having a user-defined meaning.

Reid