Any ideas?
It seems to occur randomly when changing the instrument. I tried the various 'processing settings' but none seem to alleviate it.
Classic ZynAddSubFX VST download
-
- KVRist
- 96 posts since 11 Jun, 2019
The plugin (latest version) keeps giving errors and getting disabled in FL Studio. I have only just began to try it, loading different instruments, it happened 4 times already.
Any ideas?
It seems to occur randomly when changing the instrument. I tried the various 'processing settings' but none seem to alleviate it.
Any ideas?
It seems to occur randomly when changing the instrument. I tried the various 'processing settings' but none seem to alleviate it.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Are you bridging it? Is it a x64 FL studio? Maybe that could interfere...
Are there any options that configure the way the plugin is bridged?
Note release velocity is not expected, but shouldn't cause trouble.
I have no idea what "invalidate editor" does.
Is there also a processing tab that you can make a screenshot for?
What's your asio buffer size?
Try to deactivate autosave.
Are certain presets more likely to crash or is it totally random?
How frequent is the crash? Happens on every instrument change?
Does it still do that if you try to wrap it inside another VST? (you could try Wusik_VM as suggested above)
Are there any options that configure the way the plugin is bridged?
Note release velocity is not expected, but shouldn't cause trouble.
I have no idea what "invalidate editor" does.
Is there also a processing tab that you can make a screenshot for?
What's your asio buffer size?
Try to deactivate autosave.
Are certain presets more likely to crash or is it totally random?
How frequent is the crash? Happens on every instrument change?
Does it still do that if you try to wrap it inside another VST? (you could try Wusik_VM as suggested above)
-
- KVRist
- 96 posts since 11 Jun, 2019
It seems to happen more often (or exclusively) when receiving MIDI input. So when changing the instrument while the plugin is already processing input notes, this error can occur. But it doesn't seem to happen if i just play a few notes manually in between switching instruments.
The presets on which it crashes is somewhat random, but it seems more likely to happen on presets with long release / polyphony counts / CPU usage. For testing, I've been playing back a simple melody+bass+chords midi file on all presets, so at most 4 notes are playing at once (not considering release times).
As a matter of fact, the worst offender is Alex_J/wahsynthpiano.xiz. It goes to 99-140% cpu usage. In 15 years I've used this program, I've never seen a plugin go past 80%. Changing the instrument at this point causes the error to occur every time I tried.
I'm using the 32-bit exe, so it's not bridged. I use lots of older 32-bit plugins without issue. Processing tab:
This is FL Studio 12 btw. None of these options seem to prevent the issue.
"Invalidate editor" just means "tell the plugin to repaint itself when needed". I also tried turning off autosave. My ASIO buffer is 384 samples (9ms)
Cheers
I also just tried Wusik VM, and the exact issue can be reproduced with it, it causes the same error.
The presets on which it crashes is somewhat random, but it seems more likely to happen on presets with long release / polyphony counts / CPU usage. For testing, I've been playing back a simple melody+bass+chords midi file on all presets, so at most 4 notes are playing at once (not considering release times).
As a matter of fact, the worst offender is Alex_J/wahsynthpiano.xiz. It goes to 99-140% cpu usage. In 15 years I've used this program, I've never seen a plugin go past 80%. Changing the instrument at this point causes the error to occur every time I tried.
I'm using the 32-bit exe, so it's not bridged. I use lots of older 32-bit plugins without issue. Processing tab:
This is FL Studio 12 btw. None of these options seem to prevent the issue.
"Invalidate editor" just means "tell the plugin to repaint itself when needed". I also tried turning off autosave. My ASIO buffer is 384 samples (9ms)
Cheers
I also just tried Wusik VM, and the exact issue can be reproduced with it, it causes the same error.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Thanks for taking the time to write such a detailed reply!
At first glance what is screaming to me is the 384 samples buffer.
Zyn also has an "internal" buffer size. I remember in the past that this was supposed to be a power of 2, but I can't recall why... (15 yrs ago...might have been for caching reasons, not sure anymore)
The internal buffer size is in the 'zynaddsubfx.cfg' file, wherever the dll is stored.
In the line below, the internal buffer is set to 256 samples (as example):
<par name="sound_buffer_size" value="256"/>
OK, could you please try the following:
First of all check what is the size of the internal buffer. If it is 512 try to set it to 256.
If it still crashes:
- disable "threaded processing"
- enable fixed size buffers (I'm curious what is behind the "more" button). Zyn expects all buffers to be the same size.
- could you try to set the internal buffer the same as your asio buffer size (384) - by editing the cfg file?
If this doesn't work either (maybe not as a permanent solution, but for my information to see if it still happens):
- keep enable fixed size buffers on
- can you please try setting your asio buffer size as a power of 2 (256 or 512) and to be the same as the internal buffer?
Also loop position is not used so better disable it;
========
EDIT:
I've just read about FL's way of sending random size buffers to the plugin (in order to improve automation timings?).
Zyn was not originally built as a VST. The whole VST thing is wrapping some Linux code. Anyway, since the beginning it was expecting these fixed buffers.
I know from experience, that if I set my asio buffer below 256 (128 for example) zyn crashes (never bothered to investigate why - i was always happy with 256 ~= 5 ms latency). So maybe, if FL is requesting very small buffers, it may be an issue.
If FL is sending small buffer requests and expects these to finish very fast, it could be an issue when changing presets: when changing a preset, zyn tries to process the full internal buffer (creating a fade out) and then loads the new preset. During this time, it keeps the audio thread busy (which might explain the high realtime CPU usage you see). And this is set by the internal buffer value.
After reading the manual, I would also activate "Process maximum size buffers" in options for fixed buffers, because the default of 2ms is not enough I think (it's less than 256 buffers at 44.1 kHz).
I don't know what this "maximum size buffer" mean. Is should be the actual ASIO buffer size (256 would be nice).
I've never actually had FL Studio, so I could never have tested Zyn in that host...
I would turn off also "Ensure processor state in plugin callback";
PS: leave autosave on, as it is not about the presets inside the plugin
At first glance what is screaming to me is the 384 samples buffer.
Zyn also has an "internal" buffer size. I remember in the past that this was supposed to be a power of 2, but I can't recall why... (15 yrs ago...might have been for caching reasons, not sure anymore)
The internal buffer size is in the 'zynaddsubfx.cfg' file, wherever the dll is stored.
In the line below, the internal buffer is set to 256 samples (as example):
<par name="sound_buffer_size" value="256"/>
OK, could you please try the following:
First of all check what is the size of the internal buffer. If it is 512 try to set it to 256.
If it still crashes:
- disable "threaded processing"
- enable fixed size buffers (I'm curious what is behind the "more" button). Zyn expects all buffers to be the same size.
- could you try to set the internal buffer the same as your asio buffer size (384) - by editing the cfg file?
If this doesn't work either (maybe not as a permanent solution, but for my information to see if it still happens):
- keep enable fixed size buffers on
- can you please try setting your asio buffer size as a power of 2 (256 or 512) and to be the same as the internal buffer?
Also loop position is not used so better disable it;
========
EDIT:
I've just read about FL's way of sending random size buffers to the plugin (in order to improve automation timings?).
Zyn was not originally built as a VST. The whole VST thing is wrapping some Linux code. Anyway, since the beginning it was expecting these fixed buffers.
I know from experience, that if I set my asio buffer below 256 (128 for example) zyn crashes (never bothered to investigate why - i was always happy with 256 ~= 5 ms latency). So maybe, if FL is requesting very small buffers, it may be an issue.
If FL is sending small buffer requests and expects these to finish very fast, it could be an issue when changing presets: when changing a preset, zyn tries to process the full internal buffer (creating a fade out) and then loads the new preset. During this time, it keeps the audio thread busy (which might explain the high realtime CPU usage you see). And this is set by the internal buffer value.
After reading the manual, I would also activate "Process maximum size buffers" in options for fixed buffers, because the default of 2ms is not enough I think (it's less than 256 buffers at 44.1 kHz).
I don't know what this "maximum size buffer" mean. Is should be the actual ASIO buffer size (256 would be nice).
I've never actually had FL Studio, so I could never have tested Zyn in that host...
I would turn off also "Ensure processor state in plugin callback";
PS: leave autosave on, as it is not about the presets inside the plugin
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info
-
- KVRist
- 96 posts since 11 Jun, 2019
Hmm, I tried all of what you suggested in FL, various different buffer sizes in ASIO and cfg, and fiddling with the processing settings, no change unfortunately. I also tried 'Process maximum size buffers' and the 'Ensure processor state in callbacks' option, which had no effect.
I did the same test in Renoise, and on that specific preset, it had to stall the audio engine due to the CPU usage. So it's not FL only that seems unable to handle that preset.
I disabled overload protection in Renoise and kept testing, switching between presets. It seemed to fare better than FL, but this also popped up unexpectedly:
The audio engine kept playing with the current instrument, but upon changing the instrument again after this error, I got this, and it fully crashed:
What DAWs have this been tested well on?
I tried ZynFusion demo and it has the same crippling CPU usage on that specific preset, but it has no issue switching between instruments. Although ZynFusion has its own separate issues.
I did the same test in Renoise, and on that specific preset, it had to stall the audio engine due to the CPU usage. So it's not FL only that seems unable to handle that preset.
I disabled overload protection in Renoise and kept testing, switching between presets. It seemed to fare better than FL, but this also popped up unexpectedly:
The audio engine kept playing with the current instrument, but upon changing the instrument again after this error, I got this, and it fully crashed:
What DAWs have this been tested well on?
I tried ZynFusion demo and it has the same crippling CPU usage on that specific preset, but it has no issue switching between instruments. Although ZynFusion has its own separate issues.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
ouch!
ok... Maybe I try something in the weekend, if I have time...
I use this with EnergyXT v1.4 (for my own musical satisfaction). This is actually the DAW I create in, so changing presets happens here. With eXT and 256 asio buffer, I didn't get a crash for years.
I also tested it on an ancient version of Cubase 5. As far as I know I also tested in Renoise (a demo version), but maybe something changed either in Renoise or in Zyn. It was a long time ago.
Also I tested it in Reaper (bridged with from x64 Reaper with its built-in bridge), but not that thoroughly. I can check if that preset crashes Reaper.
Thanks you for taking the time to post this!
Maybe I can have a look again into the code after all this time...
Of course, I have to be able to replicate it... Will try with Reaper first.
I cannot make any promises, but I will try!
Cheers!!
ok... Maybe I try something in the weekend, if I have time...
I use this with EnergyXT v1.4 (for my own musical satisfaction
). This is actually the DAW I create in, so changing presets happens here. With eXT and 256 asio buffer, I didn't get a crash for years.I also tested it on an ancient version of Cubase 5. As far as I know I also tested in Renoise (a demo version), but maybe something changed either in Renoise or in Zyn. It was a long time ago.
Also I tested it in Reaper (bridged with from x64 Reaper with its built-in bridge), but not that thoroughly. I can check if that preset crashes Reaper.
Thanks you for taking the time to post this!
Maybe I can have a look again into the code after all this time...
Of course, I have to be able to replicate it... Will try with Reaper first.
I cannot make any promises, but I will try!
Cheers!!
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Ok.. It crashes eXT too - I mean that preset...
I'm taking some days off work anyhow.
Time to debug
EDIT:
Ok, replicated within visual C++
Time now to remember all this stuff
- I mean that preset... I'm taking some days off work anyhow.
Time to debug
EDIT:
Ok, replicated within visual C++
Time now to remember all this stuff
-
- KVRist
- 96 posts since 11 Jun, 2019
wow, eXT I have never heard of. Looks ok but not much info on it.
Good luck debugging! That preset is just badly made I think, but I experience crashes on other CPU-heavy presets such as Alex_J/mixedvoice001.xiz. Basically I play a MIDI song into one plugin, and it crashes during almost any preset change (Just crashed first try while playing 1-2.xiz which isn't that CPU-heavy.. (changing to Cosmic Overdrive.xiz) but didn't crash second try
).
Also, first time this ever happened in FL by using Zyn (complete crash)... when switching from mixedvoice001.xiz back to 1-2.xiz.
Good luck debugging! That preset is just badly made I think, but I experience crashes on other CPU-heavy presets such as Alex_J/mixedvoice001.xiz. Basically I play a MIDI song into one plugin, and it crashes during almost any preset change (Just crashed first try while playing 1-2.xiz which isn't that CPU-heavy.. (changing to Cosmic Overdrive.xiz) but didn't crash second try
).Also, first time this ever happened in FL by using Zyn (complete crash)... when switching from mixedvoice001.xiz back to 1-2.xiz.
Last edited by cyrb on Fri May 29, 2020 3:29 pm, edited 1 time in total.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
oh yes... eXT:
Look what it can do:
I'm looking into the crash now
Look what it can do:
I'm looking into the crash now
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Hi, can you check if this is solving it?
I'm hoping to have fixed a threading issue with this new build:
https://www.dropbox.com/s/o3vtwpf2ach1w ... 8.zip?dl=1
The large CPU usage for 'wahsynthpiano' comes from SUBsynth. Modify the release time of the SUBsynth Amplitude Envelope to about 2 o'clock and it should be much better.
Now the reason this happens has to do with the envelopes. Initially zyn was programmed to kill notes when their volumed dropped below - 40dB. And this was audible. And it pissed me off. So I changed it it to - 100dB. And of course I overdid that. Side effect is that zyn now waits for every voice to decay to - 100dB before it kills it, and that means really a lot of time for a longer release patch. So voices pile up, and CPU usage increases like hell because the polyphony was also increased to 128.
But I think you can change that in the cfg file. It's called 'min_envelope_db'. But then all other patches will have a slightly different apparent release time... because of some internal scaling.
Maybe - 60dB would be a more reasonable choice for this parameter.
I'm hoping to have fixed a threading issue with this new build:
https://www.dropbox.com/s/o3vtwpf2ach1w ... 8.zip?dl=1
The large CPU usage for 'wahsynthpiano' comes from SUBsynth. Modify the release time of the SUBsynth Amplitude Envelope to about 2 o'clock and it should be much better.
Now the reason this happens has to do with the envelopes. Initially zyn was programmed to kill notes when their volumed dropped below - 40dB. And this was audible. And it pissed me off. So I changed it it to - 100dB. And of course I overdid that. Side effect is that zyn now waits for every voice to decay to - 100dB before it kills it, and that means really a lot of time for a longer release patch. So voices pile up, and CPU usage increases like hell because the polyphony was also increased to 128.
But I think you can change that in the cfg file. It's called 'min_envelope_db'. But then all other patches will have a slightly different apparent release time... because of some internal scaling.
Maybe - 60dB would be a more reasonable choice for this parameter.
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info
-
- KVRist
- 96 posts since 11 Jun, 2019
Hmm, doesn't seem to solve it. If it helps, here's a video showing the nature of the crash I didn't even get to wahsynthpiano before it crashed.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Ok, ok.. Now we're getting somewhere.
Thanks a lot for the video! That really helps me a lot. Now I'm actually surprised it lasted that long before it crashed
I never would have thought that anyone would be changing presets like that (I don't mean any disrespect!). There's a threading issue that I think I actually fixed yesterday, but that only applies if you're using the preset browser, and not by operating instrument files manually.
You see, when you change presets from the Instrument Browser, it actually presses the panic button for you, before changing to the new preset. This means the GUI threads tells the audio thread "please stop now" so I can kill the old notes, and load a new file. Otherwise the audio thread keeps processing the old patch and in the middle of processing it finds that its guts has been deleted by the GUI thread... And dies.
But what you're doing should also work, of course.
I'll look it up and get back to you today.
BTW: I'm also thinking to add a max_voices parameter in the cfg. This might tame the CPU usage if I implement it correctly (I somehow have to find the inaudible voices and kill just those).
Thanks a lot for the video! That really helps me a lot. Now I'm actually surprised it lasted that long before it crashed
I never would have thought that anyone would be changing presets like that (I don't mean any disrespect!). There's a threading issue that I think I actually fixed yesterday, but that only applies if you're using the preset browser, and not by operating instrument files manually.
You see, when you change presets from the Instrument Browser, it actually presses the panic button for you, before changing to the new preset. This means the GUI threads tells the audio thread "please stop now" so I can kill the old notes, and load a new file. Otherwise the audio thread keeps processing the old patch and in the middle of processing it finds that its guts has been deleted by the GUI thread... And dies.
But what you're doing should also work, of course.
I'll look it up and get back to you today.
BTW: I'm also thinking to add a max_voices parameter in the cfg. This might tame the CPU usage if I implement it correctly (I somehow have to find the inaudible voices and kill just those).
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
-
- KVRist
- 96 posts since 11 Jun, 2019
That fixed it! There's a bit of a pause between loading, but that's fine (lots of modern synths pause too).
Doesn't want to crash anymore (4x speed):
What was it that fixed it? Not just hitting panic before right? I recall before it still crashed even when I hit panic before loading another.
Doesn't want to crash anymore
(4x speed):What was it that fixed it? Not just hitting panic before right? I recall before it still crashed even when I hit panic before loading another.
-
- KVRian
- Topic Starter
- 1055 posts since 3 Jul, 2006
Yeah.. It was a pesky threading issue.
Basically I copied the code I fixed yesterday to invoke also when you open presets using the menu. The pause is necessary to safely communicate between the threads.
I'm adding now the option to reduce the maximum number if voices.
This should greatly reduce the CPU hit with patches that have long trailing.
Might also trow in some patches I did for some Vangelisy sounds. Maybe I'll release it a little bit later.
I'm happy anyway that it's not crashing anymore! Your detailed feedback and the video helped a lot to identify the issues. Thanks!
Cheers!
PS: you do know that there is a dedicated window for changing presets, right? Instrument > Show Instrument Bank
Basically I copied the code I fixed yesterday to invoke also when you open presets using the menu. The pause is necessary to safely communicate between the threads.
I'm adding now the option to reduce the maximum number if voices.
This should greatly reduce the CPU hit with patches that have long trailing.
Might also trow in some patches I did for some Vangelisy sounds. Maybe I'll release it a little bit later.
I'm happy anyway that it's not crashing anymore! Your detailed feedback and the video helped a lot to identify the issues. Thanks!
Cheers!
PS: you do know that there is a dedicated window for changing presets, right? Instrument > Show Instrument Bank
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info