Zynewave's Forum Page
Forum Replies Created
-
April 22, 2006 at 10:15 in reply to: Restricted to Podium license owners
ZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterDo you have already a planning for midi remote control , because i am planning to build a magic box to pilot podium in the recording functions…
It’s on the plan, but I have no time estimate. There are at least 2-3 major features that are higher on the list.
ZynewaveKeymasterCould you please describe in greater detail how you want to this work? Should the index be added to the object name?
ZynewaveKeymasterSo it was the Posihfopit EQ that overloaded the CPU, due to heavy automation?
ZynewaveKeymaster@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.
ZynewaveKeymasterdoes 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.
ZynewaveKeymasterI’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?
April 18, 2006 at 19:27 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterYes. 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.
ZynewaveKeymasterI 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.
ZynewaveKeymasterHi 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.
ZynewaveKeymasterI 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.
ZynewaveKeymasterPerhaps resaving your ext files in the latest standalone beta, will enable them to load in the VSTi version.
ZynewaveKeymasterTested 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.
ZynewaveKeymasterI 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?