ishkabbiblePlease don’t apologize, Levendis. I’m always interested in learning new tips & tricks. Keep ’em coming! 😀
And I just upgraded the ZASF plugin to my latest greatest hacked version by deleting the old one and sticking the new one into my Podium-specific plugins folder, and Podium found the new copy and handled it flawlessly.
ishkabbible.
ishkabbible…Podium allows a project to be salvaged…
Very good points – I can see how that would be useful. Now that I understand what it is attempting to do I can hopefully NOT confuse it again 😀 and it just might grow on me.
Thank you all for all the great pointers.
And my apologies to @Zynewave – my project once again appears to be stable and not crashing (although the OK/Cancel button issue remains, the workaround is simple). PBKAC.
ishkabbibleTHanks Telenator. Sounds like I should only use my alpha versions in Reaper and then use Podium as the acid test once it reaches a beta stage, and keep a sparse plugins folder with copies of just the stuff I really need. Still hasn’t crashed so far with my one-plugin plugins folder 🙂
VDXi has done an amazing job with the VST ZASF – I have found it to be quite stable in Podium since about version 2.4.1.490 (I think he is at 496 now). If you have been shying away due to reliability worries, you might want to give it another try. It really is an amazing instrument.
An interesting aside – ZASF was originally written for DOS, by a kid who did it because he couldn’t afford a synthesizer.
ishkabbibleThanks Telenator.
I assure you that I have no intentions of hacking Podium, beyond putting one of the VST_monitor VSTs in line to watch the conversation between Podium and ZASF. ZASF is an open source project, so hacking it is what I am expected to do. And I am regular contact with VDXi, the “official” dev of the current Windows VST version.
Removing the C++ run time library was no big deal – I think Seib placed it in the VSThost folder to guard against incompatibilities arising from M$oft updates.
Like all DAWs, Podium ‘prefers’ some things set and/or done a certain way.
I assumed as much, but it would appear that knowing what that certain way is costs a little extra…
Perhaps you moved the plugin to a far different folder that you had not included in the important listing in your Preferences section?
I removed the one I didn’t know was there altogether, because I didn’t know it was there and had no idea that I was using it. The recycle bin is DEFINITELY not in my plugins path… 😀
But something you said makes me a bit worried…
the few times I have moved a plugin from one sub-folder within my VSTPlugins to another, Podium has caught the chain every time, and it changes the file address automatically
I always have multiple versions of ZASF floating around in my plugins folder: VDXi’s current release, my current “best” version, and any previous versions that I have used in any projects (the latter because a known “issue” with ZASF is that different versions tend not to play nicely with each other in a single project, so when I open an old project and want to add a new track, I need to use the version I started with). But all of the ZASF versions have the same “unique identifier” (passed to setUniqueID), and prior to my latest release, they all also passed the same strings to getEffectName and getProductString. So Podium *MAY* not understand that there are multiple, incompatible versions lying around. If it is going behind my back and finding another copy of the DLL when the one it was expecting disappears, then I probably DO have mixed versions, and if so, then it is surprising that ANYTHING works at all.
And I think we may have simultaneously hit on the solution. Last night I started with a new, clean folder for plugins, and put only one copy of ZASF in it (the same version I used in the project that is giving me fits), manually deleted ALL of the plugins in the “Devices” pane, set the plugin path to ONLY see my new folder, then did the rebuild and load plugin database. I think now my project is working. At least I have been playing with it for the better part of the day with no crashes, where 15 minutes without a crash was about all I could get before.
So “Don’t fuck with the plugins” may very well be one of those “Podium ‘prefers’” rules, and if so I will just have to keep a nice, clean plugin folder just for podium, or maybe even a plugin folder per-project, and only let Reaper see the wild, wild west of my development area.
But this does beg the question ( @Zynewave ) – what does Podium DO with the strings returned by setUniqueID, getEffectName, and getProductString? Are there any rules I should know to make Podium happier?
ishkabbibleWEll, I’ve done a little more experimenting.
Removed the offending DLLs, rebuilt the plugin database, exited and restarted Podium: No change. Does Podium have any issues with multiple copies of a plugin within the path? Or different plugins that have the same internal name?
Switched from the TASCAM ASIO driver to the windows MME interface: Didn’t seem to improve any of the bad behaviors, but introduced another bad behavior – the synchronization between my tracks was messed up, with some tracks lagging farther behind than others.
I did make one other discovery – even though clicking the button with the mouse does not work, the ancient keyboard navigation shortcuts seem to be working just fine – I can tab to the button and <enter> presses it. This makes me think that there may be some bug in running the 32-bit GUI library under x64.
I think I have discovered part of the problem: missing plugins. It appears that I had an extra copy (of unknown pedigree) of the ZASF version I was using in this project buried in the build folder structure, and some tracks used the “official” dll while others somehow referenced the buried one. When I upgraded to a newer version, I deleted the entire folder structure, then just put the official dll back in its proper place, did the “rebuild and load plugin database” thing, and the tracks that referenced the rogue copy were still referencing the now-missing location (as determined by right click –> properties on the plugin in the “Devices” pane). After changing the “plugin file” to point to the correct location things seem to have become MUCH more reliable.
Which brings up an interesting question – what is the point of “rebuild plugin database” if it keeps pointers to deleted folders / plugins? And how do I tell it to actually start clean?
ishkabbibleHi Levendis – not sure I qualify as a ZASF “developer” (yet), maybe “tinkerer” would be a better moniker 😀
Thanks for giving this a try – since you are not seeing the same behavior, then I may well be dealing with something unique to my setup (ASIO driver, plugin library, some rogue file…)
@Zynewave –
I did identify the DLL that is causing Podium to throw the R6034 runtime error – I have a copy of the visual C++ runtime library msvcr90d.dll in each folder where I tinker with ZASF. I get the error when Podium attempts to load that file to see if it is a plugin.
I don’t actually need the library to live there, just made it a little easier to compile the VSTHost app. I will remove the files and see if that improves Podium’s behavior.
ishkabbibleCan you check what plugin file name is written in the scanning dialog when the error dialog pops up?
This error dialog is probably popped up by the plugin, and so does not necessarily report as an error to Podium. If at the end of the scan, Podium does not report that plugins have been quarantined, then the plugin is accepted, but it may still have corrupted Podiums memory.
I will do that this evening – and then remove all of the offending dll files (or redo the plugins folders settings to not scan where they are – there are some dlls in the paths that it searches that are not plugins at all, but libraries used by other software).
I would guess Reaper uses a method where a plugin instance is designated to a specific thread. That can cure some of the weaknesses of plugins that are not multithread safe.
ZASF is itself multi-threaded (poorly, IMHO, but we are working on that), so Reaper has to be going one step further by somehow corralling all of the threads from a single track into a sort of 32-bit virtual machine that is bound to a single processor.
Before you delete the Podium.ini file, you should quit Podium.
I did. 😀
If, as Telenator suggests, there really is some fundamental incompatibility between ZASF_VST and Podium, I really would like to identify the source and just fix it. The Steinberg VST API documentation leaves much to the imagination, and doesn’t seem to dictate a clean “a plugin must call these functions in this order, and the host will respond by calling these other functions in this order” process, instead (at least in the only documentation I’ve been able to find) it says, “here is this big pile of functions – use whatever you think you need.” So it wouldn’t surprise me in the least to find that Podium is expecting ZASF to call something that it isn’t, or ZASF is calling things in an order that Podium isn’t expecting. I know Vlad put the interface code together pretty much by trial and error, using Hermann Seib’s VSTHost as his development environment, then testing in EnergyXT.
For now, I will try the things you have suggested and report back in a day or two.
ishkabbibleI am running the licensed version of Podium – just updated 3.2.0 to 3.2.1. ZASF is absolutely NOT multi-processor safe (hence my surprise at discovering that Reaper had found a way to do it), so I have to run Podium with the VST multiprocessing option OFF. I have been playing around with the ZASF code in Reaper, and I have my own alpha where I did fix a couple bugs in the VST interface – although I would be surprised if any of them could cause this behavior. I haven’t had the time to try my latest version in Podium yet, but this may be my impetus to test it. It would be nice to figure out where the incompatibility with Podium lies, then we can just fix it in the next release.
But you will notice that I switched DAWs rather than switching synths – ZASF is a truly amazing instrument that only lacks a PR department. Check out my soundcloud – everything there was done entirely with ZASF (except the Micor Coupland piece) – starting with an old windows stand alone version, then moving to the VST version in Podium and then Reaper.
I have considered the scorched-earth “wipe it clean and reinstall from scratch” approach, on the thought that some file that didn’t get replaced by the 3.2.1 install may have become corrupted. Does Podium leave any droppings in the registry that I will need to go clean up after an uninstall?
ishkabbibleI should also note that the first couple of pieces I did in Podium worked just fine. But as I developed more and more complex patches in ZASF, the CPU usage in Podium went up and up, eventually reaching the point where I had to start bouncing tracks to keep the audio from stuttering. Podium’s reliability seems to be inversely proportional to the CPU loading, almost as if there is some thread that is falling behind, then once it laps itself it crashes.
This is the other reason that I switched to Reaper – Podium seems to only utilize one of my four cores, while Reaper farms ZASF instances out to all 4 cores by wrapping them in “containers” that handle the 64 –> 32 bit conversion and somehow allow them to run on multiple cores without stepping on each other.
ishkabbibleAnd it still crashes after reconfiguring. MSVS reports “Unhandled exception at 0x0f56d96b in Podium.exe: 0xC0000005: Access violation reading location 0x0f56d96b.” Not terribly useful without the symbol table, but perhaps meaningful to you?
One thing I should perhaps mention is that there appear to be some defective VSTs in my collection – When rebuilding the VST database, I get several instances of a dialog saying something about attempting to load the C++ run time library without a manifest. This has been happening for as long as I can remember, and I just hit “Ignore” and it finishes scanning and everything *seems* normal (except the aforementioned OK and cancel button issues). I get the same notice in Reaper, but neither program seems inclined to tell me which files are causing the problem. It is NOT ZASF, I verified this by moving my whole ZASF development folder OUT of the plugins folder, and I still got the same number of “no manifest” errors. I have been assuming, hopefully correctly, that Podium just ignores the plugin’s existence after noting that error.
ishkabbibleIt appears that if I hit OK several times, it eventually activates. It is NOT a delayed reaction, since if I press it once and wait, nothing happens. The audio/MIDI setup dialog behaves the same. Note that the rest of the dialog controls work just fine – it is only the OK and Cancel that are buggered.
Deleting the Podium.ini file (which IS in the location you mentioned) did not change the behavior of the OK and cancel buttons.
ishkabbibleFYI – I just downloaded and installed Podium 3.2.1. All symptoms remain the same.
ishkabbibleOnce again I forgot to post my latest ZynAddSubFx/Podium piece here (although I did remember to post it to the Poppets group) – this one is titled “Elephino”.
Sadly, this will likely be my last piece using Podium – I fear I have outgrown it, at least until it can effectively utilize multiple processors regardless of the multiprocessor-awareness of the plugins (or I get around to making ZynAddSubFx multiprocessor safe).
ishkabbible@Zynewave wrote:
Have you checked if it happens with different projects, including some of your older projects that didn’t show problems previously?
It’s possible that you have dialed in a specific preset in ZynAddSubFx that has a license to kill.
I just finished up a project last night that I had last worked on before the problems started. It did seem to be more stable. I will continue watching the crash frequency vs. project to see if I find any correlation (fortunately I have 3 other projects in various stages of incompleteness, so I should be able to gather some statistics)
ishkabbible@druid wrote:
I’ll be avoiding Tascam in the future as hard as I possibly can
Yeah, I can’t say I have been overly impressed with this unit. 🙁 I bought it because it was on sale at 50% off, making it a REALLY good deal for price vs. functions, and I had high hopes because of the brand name. I used Teac tape decks for editing back in the days of yore and they were extremely good, but I fear they have lost their recipe in the intervening mumble mumble years.
I will try removing the TASCAM driver and installing ASIO4All to see what happens.