ZynewaveHi,
Things like audio event fade-in/out, disk-streaming optimization, and various other usability features are higher on the list. Too early to set a deadline on this feature.
ZynewaveDo you think about something that could be done in the plugins to limit or avoid this ?
I don’t have any experience with design in SynthEdit, so I don’t have any tips for that.
ZynewaveAudioMulch, Bidule, EnergyXT, Nuendo, Tracktion.
I don’t know how AudioMulch, Bidule and Nuendo handles multiprocessing. Tracktion does not support multiprocessing of plugins. The audio thread runs on a single CPU, so plugins will never be processed in parallel. The other CPU will be used for the GUI and possibly disk access etc. Based on the last description I read about EnergyXT, you have to select which CPU core a particular plugin should use. So you need to set up two instances of the plugin and configure them for different CPU cores.
The crash problem occurs when multiple CPUs simultaneously calls the processing for multiple instances of a plugin. Some plugins stores data in global memory that are shared between instances of a plugin. In single CPU execution this is not a problem because one plugin instance completes its processing before the next start. With multiple CPUs calling the same code, there can be conflicts when accessing the global data.
Furthermore for two instances to be processed simultaneously they have to be routed in a way where they both can process input simultaneously. The processing of other plugins can also influence the timing of the simultaneous processing, so that is why the crashes may appear random.
ZynewaveI don’t know of any such utilities, sorry.
ZynewaveZynewaveThere is certainly something between Synthedit and Podium, since absolutely no other host has this problem, but I have not discovered any constant cause
Which other hosts have you tried that support multiprocessing? The problem I mentioned with Lallapallooza will only occur if the host runs multiple instances of the plugin on different CPUs.
ZynewaveI would like to see the option of seeing all Vsti parameters, presets etc. spread out along the bottom where the mixer is.
Do you mean a popup list menu when clicking on the preset or param rows?
ZynewaveI’ve now also tried multiple instances of Hydratone, in case it was related to multiprocessing. Still no crash.
but some of my plugins (SpatPod for example) give exactly the same problem since a few months on my P4HT.
They worked perfectly before (I can’t tell a date, perhaps with the 1.40 version ?) and have no problem on my laptop (Centrino) with the same versions of Podium.
If I limit Podium to one “processor” on the P4HT I can generally use the plugs.
I know that e.g. the Lallapallooza plugin (Synthedit creation) used in the Freebees project will crash easily if more than one instance is used with multiprocessing. That’s one of the reasons why I have it as high priority to create alternative demo projects with Zynewave plugins. It may be a problem with Synthedit (Lallapallooza is using a very old Synthedit version), or it may be something in the plugin schematic that causes the crash.
The message is often : “Cannot store preset data from plugin. The reported size of 0 Mb is beyond the limit allowed in Podium” (sometimes other values like 6 Mb or 8 Mb).
This message typically occurs after the plugin has crashed, which is why Podium cannot retrieve the presets.
ZynewaveZynewaveZynewaveI downloaded both the Pluggo runtime and Hydratone. Installed Pluggo in my Vstplugins folder and installed Hydratone inside the ‘VstpluginsPluggo runtime’ folder, as instructed. Hydratone works fine. I cannot get it to crash.
ZynewaveZynewaveI have not forgotten about this. I was hoping I could update my development tools before looking into this, as this would be a big help in the debugging and optimization. I may have to postpone the purchase though. Microsoft wants 550US$ for an upgrade to their latest compiler version 🙁 .
I am currently occupied with another feature, but I’ll look into this soon.
ZynewaveZynewaveOk then, bug is fixed. Here’s some technical background info:
VST version 2 introduced an alternative and CPU optimized method of processing which replaces samples instead of summing to an existing buffer. When I implemented this a few years ago I found that some plugins, even though they reported that they supported replacing, they did not implement processReplacing properly and instead produced a loud noise. Examples of such plugins were earlier versions of Yellow Tools Culture and FXPansion DR-008. I remember reading that Cubase had an option in the preferences that would force Cubase to ignore the processReplacing method, to be able to work with those few buggy plugins. I dislike those kinds of user options, so I instead came up with a method which would test the plugin when it was being loaded to see if it really supported replacing. However, it seems that this test is what causes Cygnus to become unstable. I have now changed the code in Podium so that the test is only performed on plugins using VST version 2.1 or older. Hopefully all newer plugins supports the replacing method properly. Otherwise I expect to see bug reports after 1.57 has been released 🙂