Classic ZynAddSubFX VST download

[cyrb]

Does this happen on every project load, or does it start after the plugin has been unloaded exactly once?
Could it be that before the Zyn didn't actually unload, so reloading the project was a little faster?

But Zyn should load almost instantly on `modern` computers. How much is the lag? seconds?
I wish I had FL Studio to test it... Are you using a 64bit FLStudio? Is there any bridging going on?

Do you think I could grab a demo of FL Studio 12 somewhere?

Do you think you could try 519 and see if the problem is also there? Just swap the dll...
It might help me narrow down the issue.

EDIT: and just to be clear... the lag is when loading (starting the DAW) or when unloading Zyn?
Does the lag appear also in almost empty projects which use only Zyn?

Basically, when opening a project file after launching the FL 12, the lag occurs each time when a Zyn plugin instance is loading. It causes the DAW to stop responding for 1-3 seconds, for each plugin instance used in the project. It might be happening specifically when trying to load preset data?. Actual loading of a new empty Zyn plugin instance doesn't seem to lag the same way.

I am using the 32-bit version of FL 12, which is not bridged. The same issue occurs when bridged using the 64-bit version of FL 12. You can download FL12 demo here, though a free account is needed. Though FL 21 demo is probably also affected.

I tested 519 - same issue occurs as 521. Here is a ZIP (3MB) containing some videos showing the project load time from a fresh boot of FL 12 in each version (517.mp4, 519.mp4, 521.mp4).

[jackoo]

Thank you for your detailed and helpful report.

Sometimes I make some really stupid mistakes...

Releasing a new version here:

2.4.1.523beta VST VDX version
http://zynaddsubfx.pastnotecut.org/ZynA ... 23beta.zip

Hopefully, the issue is fixed now. I'd appreciate if you could try it out and feedback to me.

Code: Select all

===========================================================
Change log (2.4.1.523beta) 

 - fix long loading time bug, when loading presets from host
 	(introduced since 519beta, due to an error)
===================================================================
Change log (2.4.1.522beta) 

 - Allow cc_latency = 0 (in cfg file); do not use midiQ anymore;
 - Allow midi events "max_events" (in cfg file) up to 10000
===========================================================

To avoid the https discussion again, here's the scan from VirusTotal.com:
https://www.virustotal.com/gui/url/f86a ... 266834ebfb

[Iu Gob]

It is true. Before Zyn was slow to load and also lazy changing presets. Now the charge is normal. Reaper x64. Windows 10. Thanks once again jackoo. A nice present from Santa Claus!

[cyrb]

Hopefully, the issue is fixed now. I'd appreciate if you could try it out and feedback to me.

Yep! That new version fixes the issue on my end. Thanks a bunch!

[rickdom]

Thank You for the fix. It works very well and now it is loaded almost instantly in my daw. A very special gift for the new year. And Thank You for your continuous efforts to improve this version.

[jackoo]

Thanks a lot for confirming! Really glad it works! Cheers!

[G_Major]

Hi, I'm using last build (523) and all plugins windows are cut on button right corner. If a windows is moved, this cut changes, sometimes bigger sometimes smaller.
This behaviour found just on Bitwig, on Reaper works fine.

[jackoo]

Hi. I don't have Bitwig easily available. Do you think you could provide some screenshots?
Does it happen also with previous Zyn versions?
Also what version of Bitwig and Windows?

[per99]

Code: Select all

===========================================================
Change log (2.4.1.522beta) 

 - Allow cc_latency = 0 (in cfg file); do not use midiQ anymore;
 - Allow midi events "max_events" (in cfg file) up to 10000
===========================================================

What does "allow cc_latency = 0 (in cfg file)" mean? (And what is midiQ?)

[per99]

Also, I never saw .522 was available for download, and it isn't now. Do you mean .522?

[jackoo]

Code: Select all

===========================================================
Change log (2.4.1.522beta) 

 - Allow cc_latency = 0 (in cfg file); do not use midiQ anymore;
 - Allow midi events "max_events" (in cfg file) up to 10000
===========================================================

What does "allow cc_latency = 0 (in cfg file)" mean? (And what is midiQ?)

Hi!
Starting (.522) you can set the parameter "cc_latency" to zero (meaning this is now allowed). Before you could use minimum 1 = 1 ms.

Background:

I wanted to implement Midi CC smoothing. I noticed that if you modulate some parameter, e.g. filter cutoff with a midi CC, and then you move your hardware slider very quickly the filter cutoff change is not smooth: it jumps from one value to another and this is audible.

CCs are meant to have a continuous change, however if you change some knobs or sliders very quickly, then some hardware MIDI controllers don't send all the CC values (not to flood the MIDI connection with CC messages). This means that the controller could send e.g. 10-12-24-100 if you move up the slider. The values from 24 to 100 might not be sent, and then the parameter would jump from 24 to 100 and that is not nice.

So what I tried to do is that if Zyn receives a CC parameter jumping, it delays a little the parameter change for "cc_latency" milliseconds (say e.g. 52ms), and adds in-between the received values some intermediate values. Say if it receives 10-12-24-100 it would fill and replace that to 10-12-24-34-44-54-64-74-84-94-100 so that the change doesn't seem too sudden. Of course, in order have time to insert these, it would need some time, so all the received CCs are a little bit delayed internally. This delay, in milliseconds is the "cc_latency" parameter in the .cfg file.
The larger the "cc_latency", the more intermediate values are added in the sequence, to make the transition smoother, but also the less responsive the control is (this adds delay and perceived lag).

Now in order to make this delay, Zyn needs to remember all the received CC values. Then the question is how many of these CCs to remember during the cc_latency period. It creates an internal queue of some size. The size is "max_events" parameter in the .cfg file. This was maximum 300 values / events (changed in version 522 to be up to max. 10000 events). I called this "midiQ" internally.

But then remembering all these events adds some processing time, and if the number of Midi events exceeds the size of this "max_events" queue, then MIDI events might get lost. This is also not desirable. midiQ is this queue of events.

So now, if you want CC smoothing, you can choose the internal delay of the CC values in milliseconds using the "cc_latency" in the cfg file, and you can choose how many CC values to be remembered during this time using the "max_events" parameter in the cfg file.

But maybe you don't want CC smoothing at all. Then you can set the cc_latency to zero, and then max_events is ignored. A queue is not created anymore and the MIDI events are processed first come, first served - and they are all processed, no limit (no midi event is lost). And with this the behavior is identical to the versions of Zyn, before CC smoothing was implemented (e.g. version 515).

I hope that makes some sense.

Another addition is the "max_voices" option in the cfg file which sets the polyphony of Zyn. If you have a powerful computer this can be all the way to 128 or maybe more, but then this is very CPU intensive. For less powerful computers I suggest using a smaller value like about 30.

If the polyphony limit is exceeded, note stealing has been implemented to kill the notes that are the most quiet, and save CPU.

Version .522 was not released to the public. I did a quick fix for myself for a scenario where the setup was flooded with so many CC messages that the queue was always missing / ignoring some of them, so I implemented a way to disable that completely by setting "cc_latency" to zero.

[per99]

Of course, in order have time to insert these, it would need some time, so all the received CCs are a little bit delayed internally.

Thanks for your answer, it's very comprehensive! Regarding the quoted sentence: I assume that it is only the midi messages from the slider that controls e.g. an effect that is slightly delayed, and that this only applies to one slider movement at a time, so to speak, so that a first delay is not added to the delay (/latency) caused by the next slider movement, and so on? And surely the delay (/latency) doesn't affect one single note timing (exactly when, in time, the key on the keyboard is hit)?

Two or three years ago, the version came where the internal buffer size is, so to speak, decoupled from the buffer size that the daw uses. I experimented a bit, then, to find an optimal setting for the internal buffer size. But I've forgotten now what I came up with. May I ask: do you have a recommended setting for the value of the internal buffer size (and oscil size)?

[jackoo]

All midi CC messages are delayed by the amount set by "cc_latency". This means mod wheel (CC1) and all other CCs from CC2 to CC127. All CCs are meant to be continuous, so the smoothing tries to smooth every CC message.

I believe also the pitch Bend is also delayed (and smoothed) by the same amount. I remember that when I moved the pitch bend wheel very fast, I could hear some "staircase" pitching - before I tried to implement the smoothing.

Note On, Note Off messages are NOT delayed (note timing is unchanged).

The delays are not cumulative (multiple sliders modified at one time don't make the delay / latency higher).
Recommended oscillator size is always 512.

For the internal buffer size...
- try a power of 2: 16, 32, 64, 128, 256.
- lower value means better note timing accuracy but slightly more CPU usage
- 16 is really extreme and would not go lower. I think I got it to work also with 16 (but the overhead doesn't justify the benefit).

I use 64, I think. Just from experience. I don't need tighter timing. You can also experiment...
Use 32 if you think you really need tight timing.
Example: At 44.1 KHz sample rate, 32 samples should mean an accuracy of 32/44.1 = 0.73 ms accuracy for the notes.

Trying to achieve even better accuracies would be very difficult, because then you run into limitations of the windows process scheduler, the operating system itself not being designed to handle precise low-sub millisecond intervals.
I read that modern computers are not the best equipment to use as midi clock or as a sync signal generator because they have jitter in the millisecond ballpark, unlike the older AtariSTs, which had the physical MIDI ports

[G_Major]

Hi. I don't have Bitwig easily available. Do you think you could provide some screenshots?
Does it happen also with previous Zyn versions?
Also what version of Bitwig and Windows?

Hi, sorry for the late answer. Sure, I'm dropping you some screenshots.

Top image is before moving the windows and the bottom one is after moving somewhere on the screen.

And a couple of examples of others windows.


About testing previous version on bitwig, it seems the same I think.
Bitwig version is the latest one (4.4.6) and windows 10 64bits 21H2 (19044.2486)

[Lake_Otter]

So I've installed VST ver. ZynAddSubFX VST v2.4.1.523beta
I assume this is the latest version I don't have to pay at least $45 for (while I'm struggling) or that won't go silent after 10 minutes?
Thank you