I am a big fan of the wonderfull vst synth called tranzistow .
In the latest update there is a bug that is beyond the scope of the developer
WHenever a new patch is loaded a save dialogue pops up for confirmation , but when ignoring this dialogue and closing renoise ,the dialogue closes with renoise but is still active , and thus windows desktop becomes unresponsive …here’s a quote from the developer about the issue
quote
Yes, weird, I agree. I noticed this with Renoise only - “Save Yes/No” dialog was hanging after closing the DAW for the reasons which are out of my scope (because I cannot debug the DAW). I reworked them to use standard Windows MessageBox function in the latest version and now Renoise just closes/ignores them on exit. Still weird but at least they are not hanging anymore.
Are you saying that you have the same problem with the latest version (2024-04-03) too?
The point is , when you ignore the window ( don’t click it ) and then close renoise , windows desktop becomes unresponsive because that " trranzisoow save window ’ is still active somewhere , but where ???
There is nothing in taskmanager that suggest there is still a runnng process happening .
When i closed renoise i have a windows wich ask me if i want to save and i say yes and it works but i ll save it before a name for the preset to name it
LIke I said before "
-Do NOT click on the window " ,
-Do NOT click on yes ,
-Do NOT click on NO
Just ignore it , DO not interact with it ,
then close renoise .
The window is now still active ( somewhere )
Renoise is hanging in the tranzistow message box’s message dispatcher.
From what I can see here, the modal dialog’s owner window is the wrong one: It should be the plugin window that Renoise creates to host the plugin UI or the Renoise main window, but it seems that the owner instead is the plugin content window from tranzistow.
If you have a contact to the developers, please tell them to contact me directly here or via taktik@ nameOfThisSoftware.com
This is the response of the developer after I provided him with the info you’ve given above
quote
If this is the case then those modal dialogs would hang in all cases, not just on close. So, this is not the cause.
Yes, it hangs in message loop but the sequence of events which lead to this is quite strange:
(1) For some reason Renoise reports an older version of ComCtl32 library being used:
Hrastow, Reaper: $6000A
Renoise: $50052
Due to this, custom FPC/Lazarus dialogs are used, not the Windows TaskDialogIndirect which is available in $60000 and up.
(2) Tranzistow receives WM_Quit message from somewhere. I haven’t figured out if this is from the host or from somewhere in FPC/Lazarus framework. IMHO, this shouldn’t happen because (according to Win32 API) WM_Quit “indicates a request to terminate an application” and DLL is not an application.
(3) And finally, for another unknown reason, this WM_Quit message ended up being posted back into the same queue by dialog message processing loop, again and again, causing an endless loop.
I solved it in the latest versions by simply doing a dummy WM_Quit processing to get it out of the queue on close. This is only for Renoise because I found a way to detect if Tranzistow runs under Renoise by querying the class name of a plugin window.
Bump , still hoping for a fix because this isreally annoying and only happens in renoise .
Summary , tranzistow menu window is hidden behind renoise MAIN window and thus Unreachable
Gentleclock, i noticed this too. What i do to prevent this from happening is that i save the Renoise project file, and then clear everything with “create new song” before exiting Renoise.
Ah ok , didn’t know that because this is the first time you mention backwards compatibility as a (valid) reason , so I kept bumping the thread because…tumbleweed
So is this specific issue because of something renoise handles differently compared to other hosts ?
As a matter of fact , I think it’s a poor excuse
It’s obvious that renoise is the issue here and can’t handle pop-up windows ( even if there are any )
Here’s another example , when I choose synthesize wave in the contour editor , I get presented with the standard windows explorer window too choose a waveform .
If I cancel-abort the window , renoise is stuck .
Perhaps afloating window but alt-tab shows nothing
Forrcing the drivers to shut down manually in taskmanager is the only way out
Why doesn’t this happen in studio one , loomer architect , reaper etc…?
Point being , I can’t use a synth to it’s fullest potential because of some host issues …
Just download the demo version of tranzistow , click on contour editor and right click n the contour editor to bring up synthesize window and press cancel ,
Edit: when I do the exat same thig in studio one , right before the actual windows menu pops up there is a verry brief pop up of another windows window that vanishes verry quickly ,I think it’s this window that renoise has issues with .
Ace, I now sometineshave to shutwond-restart win explorer of this same issue ,all icons on the desktop are unresponsive ,
I’ll keep bumping this untill there is a workaround
All it takes is to download the demo and experience the issue , then debugging might get easier
Now this , some quick googling shows this is delphi related
It’s a compromise. The fix on our side would be upgrading our Windows dependencies, according to:
I’m not doing this to make a single plugin work. Because once we do that, a bunch of other old plugins will fail to load because of the updated dependencies. What’s better now? Some old plugins that used to work no longer work, or a single plugin that now works in Renoise.
This should be fixed in the plugin.
Also, showing these dialogs in a plugin is a very strange thing to do. Plugins should store their entire runtime state with the host, not globally in the file system.
