ZynewaveSo it was the Posihfopit EQ that overloaded the CPU, due to heavy automation?
Zynewave@acousmod wrote:
If you disable the ‘multiprocessing’ option on the audio page in the preferences dialog, does the crashes still occur?
No, happily.
I’ll recommend that you disable the Podium multiprocessing option then. I just tried debugging the Lallapallooza (synthedit) multiprocessing crash I mentioned earlier in this topic, and as I expected it occurs in the plugin audio process function. I tried disabling parameter automation and even preset recall, but the crash would still occur at random but still frequently. There are many pitfalls in proper multiprocessing support. The instability is very much dependent on the timing of the calls into the multiple instances of the plugins. This is why you can experience that Nuendo does not crash your plugin, because it may do things in a different order than Podium does. Likewise you may encounter plugins that will crash in Nuendo and not in Podium.
Zynewavedoes hyperthreading offer that much of an advantage or would I be best off disabling it for the time being? if i disable multiprocessing in podium without disabling hyperthreading of the actual processor, would that be only utilising half of my cpu?
Try just disabling the ‘multiprocessing’ option in Podium preferences. This will restrict the audio/plugin processing to one processor. You’ll still be able to benefit from HT though, since e.g. GUI and disk access can run on the other processor.
ZynewaveI’ve ended this project in october, so do you think that something has changed in Podium’s code since this date ?
I don’t recall changing anything related to multiprocessing.
Several instances can run without problem except in Podium WHEN THE ENGINE STARTS.
If I add instances of the plugins WHILE the Podium’s engine is running, there is no problem, I can work with all of them.
But if I shut down the engine and restart it : crash…
Does this help ?
When the engine starts there is a lot of initialization calls being made to the plugins (presets recalled etc.). Plugins often delay some of the initialization to the next audio process call, and thus it is more likely that a crash occur on startup because multiple instances try to do initialization simultaneously. When you add a plugin once the engine is running, only that plugin is initialized and thus is less likely to conflict with already running instances.
If you disable the ‘multiprocessing’ option on the audio page in the preferences dialog, does the crashes still occur?
ZynewaveZynewaveYes. I had imagined a ‘zScope’ plugin which could show both real-time frequency response in a plot similar to zPEQ, and also historic spectrum analysis displayed as a horizontally scrolling color-coded plot. No deadline yet though. I plan to experiment with zMaster and zReverb before this.
ZynewaveI found out why the eXT VSTi crashes. If you bypass or mute the eXT track, you can load the .ext projects saved with the standalone version. Once you unmute or disable bypass of the eXT track though, it will crash in the audio processing code. You’ll notice that your eXT projects has a master in module with both MIDI and audio connectors. If you create new projects with the VSTi version the master in only has a MIDI connector. This is because the VSTi version does not have audio inputs. Since the plugin declares it does not process input, Podium does not provide input buffers to it (for speed and memory optimization reasons), and this is why eXT crashes. If I send dummy input buffers to eXT it does not crash. You should be able to use your projects if you can substitute the master in MIDI/audio module with a master in MIDI only module, but I could not figure out how to do this.
I’ll send an email to Jørgen about this.
ZynewaveHi Alphonse, good to hear from you again.
Your request is noted. There are indeed a couple of features that are higher on my list, but I’ll look into Rewire at some point.
ZynewaveI doubt that there is anything I can do in Podium to fix this. You can email me one of your older .ext files so I at least can verify if the crash occurs on my system.
ZynewavePerhaps resaving your ext files in the latest standalone beta, will enable them to load in the VSTi version.
ZynewaveTested with Podium 1.56 and latest eXT beta. I loaded the eXT VSTi version on a Podium track. Added a VSTi inside eXT and saved to an .ext file. Added a reverb plugin and saved to another .ext file. Loading these .ext files causes no crash. Creating presets on the Podium track also recalls the two different plugin setups fine. What am I doing wrong? 😛
Maybe the crash occurs because the .ext files you are loading have been saved with a previous eXT version? Try saving .ext files with the latest eXT beta version and see if these will load.
ZynewaveI doubt that the problem is related to the focus track in the saved project. If you load the project saved with focus on the automation track, and then click focus to the EWQLSO track before play, does playback still freeze?
ZynewaveI’ll check it out. I have a license for eXT.
Are you using eXT: Beta 27-feb-06 ?
Zynewave@kingtubby wrote:
Just discovered that I can drop a wave file on top of a midi sequence playing a vsti (on the same track) and they both play back. Should this be possible? It doesn’t seem like it should be..
Mart.
This behaviour is a consequence of how the hierarchic engine works. If the plugin mapping accepts audio input, then the audio will be routed into the plugin, otherwise it is routed upwards in the hierarchy. Some VSTi’s support audio input, which is why you may see that some synths will ‘consume’ the audio. Of course it is recommended to put the audio on a separate subtrack, to avoid getting a mess of overlapping sound and sequence events on the same track.
ZynewaveWill Podium ever have right-click Midi Learn for quick on-the-fly parameter control (e.g. of VSTi parameters) ?
That’s how I imagine that it would be implemented. The plugin parameter object would then both be configured with a VST parameter number and a MIDI controller.