If you are experiencing problems (strange crashes or distorted sound) with some VSTs in Renoise 1.9 with the multi processor support enabled, let us know about them in this forum thread please.
We will then contact the developers of these plugs to get this as soon as possible fixed. Those are in most cases bugs in the VSTs; not in Renoise, but if the VSTs are no longer maintained/developed, or the developers can not fix this for other unlikely reasons, we will add a workaround for this into Renoise, so that you still can use them in Renoise 1.9.
To test if the multi processor support is the reason for the crash in the VST, you could simply try to set “Number of Audio CPUs” option in Renoise Audio preferences to “1 CPU”. This will disable the multi processor support.
Most VSTs will only crash when running several VST instances of the same plug in different tracks at once. So please make sure that you test exactly this case:
Assuming we want to test if “Absynth” runs fine on multiple processors
Start a new,clean song in Renoise
Make sure that the “Number of Audio CPUs” is set to 2CPUs or more in Renoises preferences
Instantiate one Absynth VSTi in Instrument 0. Then enter some notes into Track 0 to run it.
Instantiate another Absynth VSTi (no alias!) in Instrument 1. Then enter some notes into Track 1 to run this one as well.
Now start playing back the song and try to often change the playback position or start stop the song at random positions. Run the Pattern for a long while. In most cases the cash will randomly happen or not, so be a little patient.
When testing VST FX, you could simply add 2 instances of the VST FX into two different tracks at once.
I will begin to testdrive all the VSTs that I have installed here and do the above described test to find out which ones crash. Even if these are bugs in the VSTs: This is a time bomb. Its quite unlikely that one uses two instances of the same plug in one song, so it might seem as everything is OK until you use a second instance…
Or we simply disable the multiprocessor support for all synthedit plugins, until they have fixed this and released an update. Does anyone know if there is an easy way to find out if a VST was made with SynthEdit?
One more idea: Maybe there exists a list of known buggy multi processor VSTs somewhere? Either a user contributed list or maintained by the other hosts itself? Does anyone know something like that? We could use this one as a base.
Multiprocessors are available for a while now so the other hosts with multiprocessor support must have taken care of this - somehow?
the easiest way would be via plugzilla.com (but its down for awhile).
since plugins builded with a registered version of SE arent tagged anymore [SE badge]
I read somewhere that buggy multicore plugins most likely crash if two instances is running, dunno if this is true, but if so, maybe theres a way to analyze this?
Just add another instance in a new instrument and test each instrument in a different track. (not subtrack!)
You will find out quickly which plug does support multicpu and which does not.
(Allright DOH, I should read all posts before posting…)
Anyway I was wondering if it’s possible to validate plugins through how they allocate in memory, guess that’s why they crash right? So if they have a pattern and it can be measured on VST folder scan, this would ofcourse be ideal… but i’m in over my head here hehe
easily crash or crackle when running with multiprocessor support enabled.
I have set Renoises multicore compatibility flag for Chip32 now (NOT for Beta7).
For all the the SynthEdit plugs I am still not sure what we should do. The crashes are extremely evil (SynthEdit simply kills Renoise, so we even can not save a crashbackup in such situations). The good news seems to be that non SynthEdit plugs do not have (obvious) problems with the multicore support.
According to the changelogs of SynthEdit, they have not yet take care of this. Or has someone else heard of a fix from them?
My collection of SynthEdit plugs is quite small, so there must be a LOT of others out there which will crash.
I will for now try to find a way that we at least save crashbackups on such crashes and not disable the multiprocessor support for them.
I think it’s admirable that you take the time to wade through tons of synthedit synths to help bugfix these for multicore support. Tho like you said ‘Its quite unlikely that one uses two instances of the same plug in one song’.
So why then not just add a disclaimer or notice about the possibility of synthedit synths crashing renoise on multicore machines?..so people can only blame themselves when they lose work because of a related crash.
I feel your precious time is better spend on cool renoise stuff & let the synthedit developers fix their own shit
btw, I’ve collected almost all the synthedit synths through the years so if you need any for testing let me know. Also, kvr lets you filter out synthedit synths in their database: http://www.kvraudio.com/get.php?mode=resul…t=3&rpp=100
As long as we’re talking about a VST which you already have installed on your system…
If it’s not immediately obvious from the GUI (most SE creations are ugly as hell because people use the default graphics), the easiest method of spotting a SynthEdit plugin is by examining the its installation directory after you’ve loaded it. SynthEdit plugs will create a matching directory which contains some *.SEP or *.SEM files.
Triforce, for example, creates a “triforce” directory in the same location as the triforce.dll file. Inside the directory you will find CK_CLOCKED_ARP.SEP and CLOCK2.SEP, which indicate modules that the author used in this particular plugin.
And yeah, like Jonas said, KVR is usually on the ball when it comes to labelling SE stuff, although a few ones do slip through the net occasionally.
I think what taktik is looking for is a way to understand if a plugin is made with SE using C++ code; for example a special variable, some value, or something like that…
I wanted to get an overview of how important this issue is, thus I’ve tested all my installed VSTis.
As Bantai said: These might not be “our” bugs, but these are our problems.
From a non computer expert point of view: You load up some sounds (VSTs) into Renoise and it then in the middle of composing just quits (which SynthEdit forces). All you have seen is "Assertion - bla " and your song is gone. Thats definitely our problem, as our/your (Renoises) song is gone.
Even from a computer expert point of view: You dont see that plugs are made with SynthEdit, so which plugs can you trust then?
I will write a friendly mail to the SynthEdit crew (should have done this before) and ask them when we can expect a upgrade. Then we still have all the plugs that will never get updated, thus still crash, but thats better than nothing.
This sounds more like a demo limitation nag hiss sound.
You maybe have to buy an extra licence for those plugs if you want to use them outside of fruity loops?
Jeff from SynthEdit told me a way to find out if a plug is a SynthEdit plug, and its version number. This way we can now recognize old buggy SynthEdit plugs.
The question is now: Should we simply disable the multiprocessor support for all “old” SynthEdit plugs or try to find out which ones actually cause troubles?
Disabling multiprocessor support for those plugs is definitely the more safe way, but would cause performance drops when a lot of SynthEdit plugs are used in a multi processor environment.
Trying to find out which ones are buggy would be a hell of work though. I will need your help to find them all.
Well, let me answer/decide this one by myself. Stability first: As long as we dont manage to at least save crash backups in such situations, the multiprocessor support will be disabled for all old SynthEdit plugs.
Even if you end up in nearly the same CPU usage on multi processors because of this, this is not worth the trouble/crash…
