Cherry Audio Forums

Sometimes it happens, that debugger windows stays empty, after debugging was started with F5 or Ctrl+F5. After next try debugger windows only contains only CA test module as well as the module to debug. Whole previous built test preset has disappeared.

I found, that the user made test preset is stored within vmod project file. I urgently recommend to add a function, that allows user to store and restore a test preset.

Yeah, I see this problem sometimes too. It seems to be a bug that causes the test client to crash on approximately 1% of loads for no apparent reason (although I have a hunch that it might have something to do with server syncing).

It's probably some race condition that doesn't usually surface. The kind of thing that would be a nightmare to fix so probably hasn't been fixed because it only affects devs rather than end users and even then only once in a blue moon.

Also on test presets, over the years I've tracked a few fantom bugs down to what I think was preset data that had been corrupted by my rouge code on a previous run. I'm not 100% sure but after spending a day or two on diagnostics to convince myself that my code was OK I've deleted a test preset and recreated it exactly and the mysterious problem has gone away never to resurface.

The preset data is in the same address space as my code so although there's less risk from things like dangling pointers in Java, the data will still be vulnerable and once something goes wrong it'll be saved to file with the problem embedded - so in future sessions, although the root cause may have been fixed, the legacy is still there. And multiple tiny problems may accumulate over time this way, so a clean start now and then makes sense.

Even in VM proper some complicated heavily-edited patches fail once in a while for similar reasons. Given that we are running dozens of modules from different devs in a single space there's bound to be some fragility.

Well, that "empty debugger window" issue is known since long ago. Fortunately it did not happen for me very often during last months. It seems to happen the more frequently the longer java code is growing.

Nevertheless for debugging complex modules one often needs complex setups. Beacause VM library update takes a long time, publishing a module for testing purposes is not a satisfying way.
While saving and restoring cabinets is possible in VM, in VMD it's not. That is the reason for my feature request.

Sorry if it seemed I was suggesting that your feature request wasn't a good idea, Roland. It would be a very useful mod and as you say would help streamline the development process. Publishing new builds and then having to wait for VM to finish its clunky update process before one can fully test something is a pain.

However, we've not had any updates since 2022 so I'm not holding my breath and even if we could restore test patches we'd still need to publish and test in VM proper fairly often because of the significant differences in how VMD and VM behave.

I'm of the write-a-bit and test school so compile a lot but do so in a tiered manner. On a typical day, I'll do an F7 Build maybe 50 times, a CTRL + F5 Run without debugger about 25 times, an F5 Run with debugger maybe 5 times and a Publish once or twice. But it depends on what I'm working on. As I often deal with behind-the-scenes communication between two or more modules I might sometimes end up publishing several times a day as there's no way to avoid it.

But if your feature request were implemented it would indeed help save time (providing one only saved the test preset to file when one had high confidence that everything was stable).

My main motivation for the earlier post was to alert people to the possibility that their test patches are vulnerable to being corrupted as I've wasted quite a lot of time chasing fantom bugs.

No problem, Colin. Your message of a risc of unexpected VMD behaviour looked to me to be both: a warning and a report on much pain.

There is another reason for my feature request:
Sometimes it is neccesary to work with different modules or module versions alternatively, in order to compare their functions or to backtrace a bug. And in that case it would be helpful too, if one only needs to load a present preset to the VMD client.

You're right, real testing is only possible within VM. It shows final module GUI and is much faster than VMD.

So let us continue our work and awaiting a Voltage update soon.

Roland

Roland, is the VMD client process already running and you have to kill it in task manager to be able to start the run/debug process again?

I'm asking, because one curious thing I encounter sometimes is, when I run with or without debugger I see the output console stays empty and the build process doesn't start, but in the task manager I see the VMD client process has started. Now comes the curious part: when I move a GUI element of the module I'm developing (by clicking on it and moving it one pixel back and forth with the arrow keys and de-selecting it), then the VMD client process continues, the build process starts and the client opens up as if nothing happened. I've actually discovered this by accident.

It rarely happens to me that my client patch is gone as you've described, like once in a blue moon. But I would also fancy a "save preset" function for the VMD client to be able to quickly put the module into different contexts and test it thoroughly.

I would also like the VMD client to be more in line with VM, starting with keyboard and mouse behavior. Why does a doubleclick on a control reset it in VMD, while it lets me enter a value in VM? Why can I remove a module in VM by hitting the "DEL" key, but in VMD I can't and have to right-click -> "Remove"? I would very much like the VMD client to be a VM cabinet with the "Test Module" loaded by default and have it behave exactly the same as it does in VM, with the same keyboard and mouse behavior, storing cabinet presets and everything

Regarding the module test procedure I totally agree with Colin that it is tedious to publish, wait for the download in VM, then test, then go back to VMD and so on. This would be superfluous it the VMD client behaved just like VM.

Best regards,
Martin

honki-bobo wrote: ↑Fri Jun 21, 2024 6:10 am I'm asking, because one curious thing I encounter sometimes is, when I run with or without debugger I see the output console stays empty and the build process doesn't start, but in the task manager I see the VMD client process has started.

I've noticed the same thing Martin.

I suspect this problem is related to the other and may be down to race conditions with various processes or threads on rare occasions getting stuck because execution hasn't happened in some expected order. This is why I think server sync might have an impact, as VMD appears to check for catalog updates as part of its cycle and this is one element that could vary wildly in its response time. It's just a guess mind, I could be completely wrong.

Now comes the curious part: when I move a GUI element of the module I'm developing (by clicking on it and moving it one pixel back and forth with the arrow keys and de-selecting it), then the VMD client process continues, the build process starts and the client opens up as if nothing happened. I've actually discovered this by accident.

Do you mean moving a GUI element in the VMD Designer pane?

I would also like the VMD client to be more in line with VM, starting with keyboard and mouse behavior. Why does a doubleclick on a control reset it in VMD, while it lets me enter a value in VM? Why can I remove a module in VM by hitting the "DEL" key, but in VMD I can't and have to right-click -> "Remove"? I would very much like the VMD client to be a VM cabinet with the "Test Module" loaded by default and have it behave exactly the same as it does in VM, with the same keyboard and mouse behavior, storing cabinet presets and everything

Yeah, there are all kinds of technical differences between VMD and VM behaviour. I've lost track of them as I stupidly haven't logged them as I've encountered them but there are a large number and although they don't impact simple modules they do impact more complex ones so testing in VM proper is essential.

CA did a fantastic job with VM and VMD and I feel they deserve a lot of credit for what is an extremely powerful and easy-to-use system. So I'm reluctant to criticize - but everything can be improved. Part of the problem for me is that CA seems to think that discussing roadmaps is a terrible idea, so we don't have a clue about what might happen in the future. OK, I probably veer too much in the other direction but I use the Adroit Synthesis section of the forum as a blog as much as a place for other people to ask questions or make suggestions. I figure anyone who isn't interested will just not bother to read my rambling posts.

If there is a VM update before I pass away then one thing that might be addressed is VM's catalog update mechanism as it's come in for almost universal criticism.

I think CA was perhaps too ambitious to try and do catalog updates in the background. It probably worked brilliantly in early testing but for me at least it's pretty common for VM to crash (or perhaps even worse do something weird that's not immediately obvious) if I make any significant changes while it's updating. So I have to either run VM offline or wait for several minutes for it to become stable. And even then I'm never really sure when the updating has finished.

Along with adding some kind of CPU load metering and publishing the bug fixes they've already trailed then I'm hopeful that they might drop the background update idea and make VM go to sleep and focus entirely on updating in one blast (allowing users to control if and when this happens). I'd prefer VM to pop up a message and go silent for however long it takes while updating than have to wait an indeterminate number of minutes not knowing what on earth is going on. Plus the UI often freezes and the sound crackles during updates anyway so we might as well have silence.

If an update does deliver a more solid catalog update mechanism then not only would this make end users happier, it would also make testing so much easier for devs that the existing problems in VMD could be completely ignored.

honki-bobo wrote: I'm asking, because one curious thing I encounter sometimes is, when I run with or without debugger I see the output console stays empty and the build process doesn't start, but in the task manager I see the VMD client process has started.

Hi Martin,

because it runs faster, mostly I use Ctrl+F5 to start the client without debugger. And sometimes client window is empty, sometimes it looks normal but nothing happens. Both these cases can also appear, if there is a compiler fault or a runtime index out of range fault. With a F5 start compiler messages get visible in VMD output pane, with Ctrl+F5 they don't. So I use to compile with F7 first, before starting the client with Ctrl+F5.

When runtime errors occure, VMD client needs a lot of time to add error messages to VMD log file. If then the client windows has to be cancelled by chosing Windows option "Cancel" instead of "Wait till program ends", usually client or debugger or both have to be finished by the user with Build/Stop running or Debug/End debug session.

Roland

ColinP wrote: ↑Fri Jun 21, 2024 11:48 am Do you mean moving a GUI element in the VMD Designer pane?

Yes. I simply click on any control in the editor, then move it back and forth one pixel with the arrow keys and de-select it by clicking somewhere else and then the client window opens and I can test the module.

ColinP wrote: ↑Fri Jun 21, 2024 11:48 am So I'm reluctant to criticize - but everything can be improved.

Exactly my perspective. I don't mean any offense, but a bug is a bug is bug. And if the users feel things could run smoother, and I'm obviously not the only one, then these things should be discussed and - hopefully - resolved.

ColinP wrote: ↑Fri Jun 21, 2024 11:48 am If an update does deliver a more solid catalog update mechanism then not only would this make end users happier, it would also make testing so much easier for devs that the existing problems in VMD could be completely ignored.

+1 all the way! And also for the CPU load metering, preferably on module level and a global one! And while we're at it, I wouldn't mind if VM was a bit less stressful on the CPU.

seal58 wrote: ↑Fri Jun 21, 2024 12:19 pm These both cases can also appear, if there is a compiler fault or a runtime index out of range fault. With a F5 start compiler messages get visible in VMD output pane, with Ctrl+F5 they don't. So I use to compile with F7 first, before starting the client with Ctrl+F5.

Yes. That's why I started using "tail -f" on VMDs log files in a bash shell so I can directly see if something like this happens when I'm not using the debugger. Takes some getting used to, but works like a charm for me.

seal58 wrote: ↑Fri Jun 21, 2024 12:19 pm
because it runs faster, mostly I use Ctrl+F5 to start the client without debugger. And sometimes client window is empty, sometimes it looks normal but nothing happens. Both these cases can also appear, if there is a compiler fault or a runtime index out of range fault. With a F5 start compiler messages get visible in VMD output pane, with Ctrl+F5 they don't. So I use to compile with F7 first, before starting the client with Ctrl+F5.

When runtime errors occure, VMD client needs a lot of time to add error messages to VMD log file. If then the client windows has to be cancelled by chosing Windows option "Cancel" instead of "Wait till program ends", usually client or debugger or both have to be finished by the user with Build/Stop running or Debug/End debug session.

I think many of us get impatient with the delay caused by running the debugger. I tend to only run it now and then to check for exceptions. BTW I discovered that on rare occasions some exceptions (unfortunately, I can't remember which or under what circumstances) aren't reported in the log files or the output pane even when running VMD in debugging mode, so I added try-catch statements in the upper layer of my main handlers to catch these.

The VMD debugger is useful but it's a bit buggy so I tend to handle it with caution. I've found the most reliable debugging technique to be simply sending values to the outside world via one or more VoltageAudioJacks. I call these sockets "stoma". I then use Martin's excellent Volt Meter and/or my CV Watcher to figure out what's going on.

honki-bobo wrote: ↑Fri Jun 21, 2024 12:51 pm Yes. I simply click on any control in the editor, then move it back and forth one pixel with the arrow keys and de-select it by clicking somewhere else and then the client window opens and I can test the module.

Wow, that's unexpected.

And while we're at it, I wouldn't mind if VM was a bit less stressful on the CPU.

My main problem is the VoltageCanvas class which is full of shall we say "unusual features" yet it's the only means to access the underlying graphics system. I'm used to low-level access so it's really frustrating. It might be a JUCE issue rather than anything in CA's code but in general the graphics performance of VM leaves a lot of room for improvement. Scrolling is painful.

That's why I started using "tail -f" on VMDs log files in a bash shell so I can directly see if something like this happens when I'm not using the debugger.

That brings back fond memories of my UNIX days. I presume you then have a live feed of the log file right? I don't go that far but do add a ######### before my log entries so I can quickly scan through and find my messages.