Topic: Podium constantly crashing

This topic has 24 replies, 4 voices, and was last updated 11 years ago by ishkabbible.

Viewing 15 posts - 1 through 15 (of 25 total)

1 2 →

October 27, 2013 at 21:46 #24972

ishkabbible
Participant

I am running Podium 3.2.0 (32 bit) under Win7 x64 on a quad-core i7-3770 with 8G RAM, with a TASCAM US-600 audio/MIDI interface, with the US-600 ASIO driver. I use MIDI-OX and loopbe1 for MIDI preprocessing and routing. The only VST I use is ZynAddSubFx, and I run with VST multiprocessing disabled since ZASF is not multiprocessor-safe.
Podium is EXTREMELY unhappy. When I go to Setup –> Preferences, I can change things, but the OK button does not work. Often I can get the setting change to “take” by pressing “Apply”, but even after that, the OK and Cancel buttons simply will not press (they are not greyed out, just completely non-functional – they don’t even *appear* to press). The only way to close the Preferences dialog is by the “X”. And when I am trying to work, I can only go about 15 minutes (on a good day) before getting the “Windows is searching for a solution” application crash dialog. AND, I am never able to exit Podium without it crashing. I have tried the obvious things like uninstalling / reinstalling Podium and drivers, and the Preferences dialog problems happen even in a brand new project with no tracks. (The crashing while running usually doesn’t start happening until I get a couple dozen tracks down, but the fact that the dialog is already screwed up before I add a single track indicates to me that Podium is sick out-of-the-box and it isn’t my VST that is causing the problem).
My solution to this state of affairs was to switch to Reaper, where everything just works marvelously. However, I have a couple of nearly-complete compositions, and about an hour of cutting room sweepings that are “stuck” in Podium. I would at least like to finish up the nearly-complete pieces. So I need to be able to do one of two things:
1) figure out what I have done to piss Podium off and fix it, or
2) Figure out how to export from Podium to Reaper
I have been utterly unsuccessful at #2, because the Podium MIDI export / Reaper MIDI import process apparently quantizes the note timing. This completely screws up the composition because I use several techniques that require millisecond NOTE ON timing (like strummed synthesized guitar), and in general I use the beat clock as a loose guideline rather than a strict clock. So I am back to trying #1.

So – to the folks at Zynewave: Is there anything I can collect / send to you (like crash dumps) that would shed light on what I am doing that has Podium so confused? Do you have a debugger-enabled version that could help debug the problem? (I do have Visual Studio, and I get the option to “open in debugger” when it crashes.)
Alternatively, does anyone know of a way to defeat the quantization of MIDI export? Or to set the quantization clock to something like 100uS? Or is the Podium project file format published somewhere? (I am a fairly clever programmer, I’m sure I could whip something up to extract the MIDI with the timing intact.)

Thanks for any advice! I *really* don’t want to re-record everything, and I actually LIKE Podium better than Reaper from a user’s standpoint, so I would like to be able to keep it in my toolkit. But at present it is completely unusable.

October 27, 2013 at 21:47 #24973

ishkabbible
Participant

FYI – I just downloaded and installed Podium 3.2.1. All symptoms remain the same.

October 27, 2013 at 23:57 #24974

Zynewave
Keymaster

You say it’s the Preferences dialog that causes problems with OK/Cancel buttons. How about the Audio/MIDI dialog. Is that working without problems?

I recommend that you try to delete the Podium.ini file. Use the Setup/Explore Setup Folder menu command to find the folder where the Podium.ini file is located. While you’re there, please check if the setup folder is at: C:\Users\[name]\AppData\Roaming\Zynewave\Podium

After you have deleted Podium.ini you need to reconfigure your audio/Midi devices, but before you do that, check if the Preferences dialog works without problems.

October 28, 2013 at 00:57 #24975

ishkabbible
Participant

It 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.

October 28, 2013 at 01:58 #24976

ishkabbible
Participant

And 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.

October 28, 2013 at 03:17 #24980

ishkabbible
Participant

I 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.

October 28, 2013 at 05:33 #24985
The Telenator
Participant
Interesting trouble report here. I don’t know if I can solve it, but I can offer a couple of bits. First, if you are using the free version of Podium, you are restricted to using one core on your PC. That’s the main and just about only limitation of the free version. Second, accordingly, if you are attempting to do a substantial project, that limitation can get you into trouble quickly. Third, more important — you need to know that ZASF is a buggy plugin in several DAWs. It’s been a while since I dealt with it, but I think it’s one of the few that is simply a ‘no-go’ in Podium. I think maybe the same in Reaper, but you owe it to yourself to search engine this instrument and read up on it.

I use Reaper and the licensed version of Podium roughly equally, as both have their many virtues. I would set aside the projects and wipe all trace of Podium files and then start over with a fresh download, just to be double certain the trouble didn’t begin with that. I’ve only had one corrupt dl of anything in my entire life, but it can happen. Podium is more bug and trouble-free than even most releases of Reaper, so it’s very unlikely a DAW issue. There are only a half dozen or so plugins that don’t work in Podium of the more than 200 I’ve tested, but I do think ZASF is one of them.

Save a copy of your project files and maybe Frits can take a look at them. If it is some other buggy plugin, there is little you can do, whether in Podium or Reaper, besides testing each VST one at a time. But ultimately it is worth knowing. Good Luck with it! Cheers!
- This reply was modified 11 years ago by The Telenator.
October 28, 2013 at 07:56 #24987

ishkabbible
Participant

I 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?

October 28, 2013 at 19:15 #24988

The Telenator
Participant

I’ve never bothered to search the registry for anything about Podium, but it would be easy, using Zynewave and then Podium in the FIND entry. I suspect there isn’t much in any case. The overall footprint elsewhere is pretty minimal — a folder in Roaming besides the regular file.

I don’t know about at the moment, but ZASF used to be a very popular instrument, used to get mention quite a lot. Of course, lately, there’s just so much happening and loads of new things all the time. I just remember people having issues with it here and there.

October 29, 2013 at 12:57 #24996

Zynewave
Keymaster

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.

Can 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.

October 29, 2013 at 13:20 #24997

Zynewave
Keymaster

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 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.

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?

The installer engine stores some settings in the registry, required for clean uninstallation, but the Podium app does not store anything in the registry. Rereading my first post, I see I forgot some important info: Before you delete the Podium.ini file, you should quit Podium. Otherwise, when you quit Podium, it will just rewrite the Podium.ini file with the old settings still loaded in memory.

October 29, 2013 at 18:36 #25005

ishkabbible
Participant

Can 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.

October 31, 2013 at 11:45 #25015
Levendis
Participant
Hello Ishkabbible (developer of ZASF?)

Working with Podium 3.2.1, 32bit OS, with dual-core processor. I wasn’t able to replicate your bug/crash.
I switched instruments, edited the patch, and changed MIDI channel routing, without a hitch.
I also toggled the state of Setup > Preferences > Plugins > Enable plugin multiprocessing.
The dialog maintained utility.

Which setting are you changing in the dialog?
Some may be too drastic to change on the fly. Power down your arrangement prior to a settings change and see if that helps.

Sorry I was unable to replicate your woes, ishkabbible. ZASF is a great instrument. Highly adaptable, deep, good on CPU resources and sounds smooth. Hope you’re able to use your favoured DAW/VST combination 🙂
- This reply was modified 11 years ago by Levendis.
October 31, 2013 at 15:48 #25020

ishkabbible
Participant

Hi 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.

November 3, 2013 at 17:35 #25038

ishkabbible
Participant

WEll, 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?

Viewing 15 posts - 1 through 15 (of 25 total)

1 2 →

You must be logged in to reply to this topic.