Finally got it to build with Visual Studio in Windows.

[bitwise]

Unless I am mistaken, not too much of that has been translated back to the official copy.

>balks at the functions in math.h
If I recall, a good number of those functions should be referenced through cmath, which should have a better ability to distinguish between types.
The codebase is a bit of a mix though.

I don't know why MSVC had such a hard time finding the proper overload

It finds ambiguities:

'pow' has 6 overloads:

Code: Select all

	
long double pow(long double, int)
long double pow(long double, long double)
float pow(float, int)
float pow(float, float)
double pow(double, int)
double pow(double, double)

consider the line 95 in 'analogfilter.cpp':

Code: Select all

tmpgain = pow(gain, 1.0 / (stages + 1));

'gain' is float so it has 2 options:

Code: Select all

	
float pow(float, int)
float pow(float, float)

'1.0 / (stages + 1)' is double, but there's no

Code: Select all

float pow(float, double)

and the compiler has to cast it to one of the 2 options... which?


replacing every fabs, sqrt, exp, log, pow, fmod
with FABS, SQRT, EXP, LOG, POW, FMOD

and defining the following in 'globals.h':

Code: Select all

#define FABS(a) fabs((REALTYPE)(a))
#define SQRT(a) sqrt((REALTYPE)(a))
#define EXP(a) exp((REALTYPE)(a))
#define LOG(a) log((REALTYPE)(a))
#define POW(a, b) pow((REALTYPE)(a), (REALTYPE)(b))
#define FMOD(a, b) fmod((REALTYPE)(a), (REALTYPE)(b))

should work in both compilers

There was an instance of a case statement that used ranges, rather than single values.
MSVC doesn't allow ranges in case statements,

I remember comming across some of those.
As far as I can tell, it is a gnu C/C++ extension that should not be in
'portable' code.

it's in 'MIDIFile.cpp'.

This could be translated in the original copy like this

'switch (msg)' turns into 'switch (msg & 0xF0)'

and

'case 0x80 ... 0x8F:' turns into 'case 0x80:' and so on.


To make the original copy a little more portable, if i remember,
there's also a 'not' keyword that should be translated into '!'

[ishkabbible]

Finally! I successfully compiled my very own stand alone ZynAddSubFx under MSVS 2010, and it WORKS. Wooooo Hooooo!
I started with the Sonicports fork just because it has build configurations for the standalone MME and DS versions. Was unable to build ASIO and VST versions because Steinberg is only offering V2.2 of ASIO and version 2.4 of VST, both MUCH newer than this project is expecting. I see jackoo's version is set up for VST 2.3, so I will study that part of his code next. (although I still have some misgivings about the whole VST concept...)

At any rate, I think my early work will be on the standalone version. Since I am actually having fun playing real music with it, I want the instant gratification of being able to USE my mods.

So a couple of questions for the experts here:
1) The Sonicports ASIO version doesn't seem to work on my machine. Does anyone know anything about this library? Does it offer any advantages over MME or DS in a Windows environment? Just wondering how much effort I should put into getting it working on my machine.

2) I stumbled across a sequencer hidden inside of the code. I presume it is hidden because either it isn't done or it is seriously broken. Anyone know which? Is anyone actively working on it?

3) Delays upon delays upon delays.... they are driving me crazy. It seems that everything in the signal chain takes a millisecond or two to do its thing and pass the data on to the next block. USB controller --> MIDI_OX --> MIDI-Yoke --> Jazz++ --> ZynAddSubFx --> Virtual Audio Cable --> Audacity --> Sound card - By the time they all take their bite out of time, it is nearly impossible to play along with the last track I recorded. Is this "normal" or am I doing it wrong? Is this what the whole VST concept was supposed to solve? (because from what I've learned so far (which I freely admit is very little), VST seems like a solution in search of a problem)

4) All the readme files say "please share your cool patches." Where? I've been having a lot of fun with this gadget (http://soundcloud.com/ish-kabbible) and would be happy to share. I am currently working on a better drum kit, among other ideas. The power of this synth continually amazes me.

And finally 5) More of a rant than a question, but what the hell happened to MIDI? I walked away from electronic music 30 years ago when MIDI was just a baby. 30 years later the state of the art is truly amazing, having ridden the wave of Moore's law right into the 21st century, but MIDI is still stuck in 1985. I would think that by now it would be running at 10GB/s over fiber with 2^32 command channels, 128 digital audio channels, binary patch blocks, wavetable blocks, etc. etc. etc. I was puzzled why the Eigenharp used a proprietary interface, now I understand. Is there a 21st century open instrument interface out there that I don't know about?

Anyway, I figure I've pestered y'all enough for one night. If I get obnoxious or if there is a better place to discuss this stuff please let me know. ANd thanks for all the good advice on these forums, y'all are great!

[jackoo]

Finally! I successfully compiled my very own stand alone ZynAddSubFx under MSVS 2010, and it WORKS. Wooooo Hooooo!

Great!

I started with the Sonicports fork just because it has build configurations for the standalone MME and DS versions. Was unable to build ASIO and VST versions because Steinberg is only offering V2.2 of ASIO and version 2.4 of VST, both MUCH newer than this project is expecting. I see jackoo's version is set up for VST 2.3, so I will study that part of his code next. (although I still have some misgivings about the whole VST concept...)

I was also unable to get the ASIO version to build, back in the old days. My VST code WORKS under VST2.3 SDK, and could probably could be easily ported to VST2.4.

VST2.4 is not really that different from VST2.3

At any rate, I think my early work will be on the standalone version. Since I am actually having fun playing real music with it, I want the instant gratification of being able to USE my mods.

Yes, but you will have latency when routing MIDI to your exe, which will have again latency rendering the audio. MME and DS are poor drivers concerning latency.

So a couple of questions for the experts here:
1) The Sonicports ASIO version doesn't seem to work on my machine. Does anyone know anything about this library? Does it offer any advantages over MME or DS in a Windows environment? Just wondering how much effort I should put into getting it working on my machine.

IMHO, ASIO is the standard for low latency audio software, on windows.
Since it was quite a hassle for me to get ASIO working in the standalone, and even the built executables I saw on the Sonic Ports site still did not behave like using real ASIO (still having some lag), I preferred letting the host deal with the audio drivers.

2) I stumbled across a sequencer hidden inside of the code. I presume it is hidden because either it isn't done or it is seriously broken. Anyone know which? Is anyone actively working on it?

I think that part of the code was never used. Nor is it maintained. As far as I know, the guys in linux say it's not within the scope of the overall project anymore.

3) Delays upon delays upon delays.... they are driving me crazy. It seems that everything in the signal chain takes a millisecond or two to do its thing and pass the data on to the next block. USB controller --> MIDI_OX --> MIDI-Yoke --> Jazz++ --> ZynAddSubFx --> Virtual Audio Cable --> Audacity --> Sound card - By the time they all take their bite out of time, it is nearly impossible to play along with the last track I recorded. Is this "normal" or am I doing it wrong? Is this what the whole VST concept was supposed to solve? (because from what I've learned so far (which I freely admit is very little), VST seems like a solution in search of a problem)

I think your software chain is a little bit too long. Low latency drivers like ASIO are the key I would say. Also MidiYoke adds a little bit of latency from what I've seen. I have problems recording MIDI properly inside my DAW when MidiYoke is on, even if not used.

Virtual Audio Cable?! Really.... too much of a haslle. Using a host (which can be free) and VST, I use an ASIO buffer of 256B - so... typ. about 5ms of latency which is fine for musical instruments.

If you gather all the dependencies my code should be compile ready so you can already see your MODS happening in real time. Please feel free to contact me if you cannot get it to compile.

Besides, as a footnote, in the standalone you are probably missing the MIDI Learn feature, which I consider very powerful. With that you can assign MIDI CC's to the knobs and move them with your MIDI controller in realtime.

4) All the readme files say "please share your cool patches." Where? I've been having a lot of fun with this gadget (http://soundcloud.com/ish-kabbible) and would be happy to share. I am currently working on a better drum kit, among other ideas. The power of this synth continually amazes me.

How about on this here forum?

And finally 5) More of a rant than a question, but what the hell happened to MIDI? I walked away from electronic music 30 years ago when MIDI was just a baby. 30 years later the state of the art is truly amazing, having ridden the wave of Moore's law right into the 21st century, but MIDI is still stuck in 1985. I would think that by now it would be running at 10GB/s over fiber with 2^32 command channels, 128 digital audio channels, binary patch blocks, wavetable blocks, etc. etc. etc. I was puzzled why the Eigenharp used a proprietary interface, now I understand. Is there a 21st century open instrument interface out there that I don't know about?

As far as I know, there is no 21st century MIDI... But I still think it's doing ok for its purposes

Anyway, I figure I've pestered y'all enough for one night. If I get obnoxious or if there is a better place to discuss this stuff please let me know. ANd thanks for all the good advice on these forums, y'all are great!

If you do take the discussion somewhere else, please let us know, because we're also interested

LE: I just googled steinberg VST2.3 SDK and I found it here, because you said you could not find it:

http://ygrabit.steinberg.de/~ygrabit/pu ... SDK%202.3/

That's the Yvan Grabit developer resource web page.

have a look at Cantabile host (videos and free version or demo) I think you will notice the latency difference if you load Zyn as VST. You simply have no delays.

LLE: I forgot to ask.. you do have a soundcard that has ASIO drivers right? If not there is AsioForALL (generic ASIO driver, but doesn't really work so good as a native ASIO driver specifically made for your soundcard by the manufacturer.

LLLE: Oh damn... Cantible Lite doesn't record midi... look at zynewave podium (free version)

Podium Free is a fully functional freeware edition of Podium. It is identical to the licensed version, except for the following limitations:

- MIDI interface setup is limited to one input and one output.
- 64-bit mixer engine option is disabled.
- Plugin multiprocessing is disabled.
- ReWire is disabled.
- Surround-sound playback is disabled.

[ishkabbible]

ishkabbible wrote:

2) I stumbled across a sequencer hidden inside of the code. I presume it is hidden because either it isn't done or it is seriously broken. Anyone know which? Is anyone actively working on it?


I think that part of the code was never used. Nor is it maintained. As far as I know, the guys in linux say it's not within the scope of the overall project anymore.

That is unfortunate. One thing I have noticed about Zyn is that it appears that the notes and the triggers travel together, whereas in a "real" synth, they can be operated on independently. Zyn does have some limited capabilities in this arena (like the "delay" setting, and allowing the LFOs to be triggered by note-on), but is missing some of the more powerful capabilities that a separate trigger path provides. The ones I miss the most are the ability to route an LFO into the trigger input of the ADSR generators for fast repeats (like picking a mandolin or doing a drum roll) and also using one LFO to trigger a sample and hold on a second LFO (generating random notes) while also triggering the ADSRs. And being the lazy bum that I am, I really miss having an arpeggiator, and many of the higher-order ideas I would like to implement have to do with the human performer giving "suggestions" to a highly intelligent arpeggiator which would use them to weave interesting computer generated melodies into the composition. Many of these capabilities would (or could) fall under the purview of a built-in sequencer (although providing a fully independent trigger path may involve attacking the code with numerous sharp objects).

MME and DS are poor drivers concerning latency.
IMHO, ASIO is the standard for low latency audio software, on windows.

So it sounds like I should get the ASIO working if I want to stick with the standalone version. I also don't think my sound "card" (RealTek HD Audio on the motherboard) has a native ASIO driver, so I may need to think about a different sound card.

I think your software chain is a little bit too long.

A gentle way of saying "the links in my chain are too damn inefficient". I have 4 processors each capable of doing 2.4 billion operations/second. Divide that by 44.1K samples/second and I have time to execute 218,000 instructions/sample. I think I ought to be able to move data from an output port to an input port faster than my fingers can move on a keyboard. If this is "normal", then "normal" is badly broken - But I'm an engineer, I can fix it.

Virtual Audio Cable?! Really.... too much of a haslle. Using a host (which can be free) and VST, I use an ASIO buffer of 256B - so... typ. about 5ms of latency which is fine for musical instruments.

So how do you get the audio out of your VST "rack" and into your multi-track recorder? Or does the recorder have to plug into the rack as well? It seems to me like Zyn should simply register itself with Windows as an audio input device, so downstream apps can open it just like they would a microphone or a line input. I say "simply" in the ignorant bliss of never having looked at exactly how much coding that would take, but windows drivers aren't THAT hard to write.
Ahhhh - just took a look at Zynewave Podium. So the idea then is that the MIDI sequencing and audio recording is actually done by the VST "rack".
This still bothers me, though. If the links in my chain are already taking too long to pass data along, how can adding yet one more layer of software improve the performance? I will, however, download their free version and play with it in the hopes that they have somehow violated the laws of physics.

4) All the readme files say "please share your cool patches." Where?

How about on this here forum?

I can post binaries here? I had figured (hoped?) there would be a repository somewhere that all Zyn users could access specifically for sharing patches. If that doesn't exist, then I guess here is where I will share them. How do I do it?
I am kind of curious why the patches are stored in binary - perhaps that made sense when Zyn was being run from a floppy, but I can't imagine any performance hit nowadays to storing them as XML ASCII text. Something else to look into, I guess.

If you do take the discussion somewhere else, please let us know, because we're also interested

I certainly would - but my question was more about where the "rest" of the Zyn users / coders hang out, and just how technical I should get on this forum. Between the several forks, there have been a few thousand downloads - are the only 5 people actually using and discussing the app here on this forum?

[jackoo]

So it sounds like I should get the ASIO working if I want to stick with the standalone version. I also don't think my sound "card" (RealTek HD Audio on the motherboard) has a native ASIO driver, so I may need to think about a different sound card.

Even on that RealTek chip, asioforall can do miracles. I think latency is not only about CPU power, but also about the drivers of the soundcard themselves. In ASIO, latency is usually "measured" by how large your ASIO buffer is.
With my M-Audio Revolution native ASIO drivers I can go as low as 128B without any audio clicks or distorsion in realtime. However I use it at 256B.

256B somehow means about 5ms latency, and 512 about 12ms latency. I'm not sure exactly why, and I'm not sure it has to do with the power of your CPU (i've seen the same latencies for the same buffer sizes on different CPUs)

So how do you get the audio out of your VST "rack" and into your multi-track recorder? Or does the recorder have to plug into the rack as well? It seems to me like Zyn should simply register itself with Windows as an audio input device, so downstream apps can open it just like they would a microphone or a line input. I say "simply" in the ignorant bliss of never having looked at exactly how much coding that would take, but windows drivers aren't THAT hard to write.

VST "rack"? Multitrack recorder? I'm not really an expert but here is how I see things:

The main audio program is called a DAW - Digital Audio Workstation, also known as the host. Podium, Cantabile, or the more expensive Cubase are hosts.

It is the host's job to talk to the soundcard, to record sound into wav files (yes, multitrack), to configure the ASIO driver, to record your MIDI notes instead of audio, and then sequence them to the plugin's MIDI IN, etc.

On most hosts you get to have an unlimited number of MIDI Tracks. Inside these tracks you store MIDI notes and Midi Controller CC events (pitchbend, modulation).

Also time synchronization (and tempo) is set by the host. The host sends the MIDI data inside the Midi Track to the plugin via the plugin's Midi In.

The host also provides some buffers to the plugin, and the size of the buffers, where the plugin has to render its audio.

During this process, the host calls
process (float **inputs, float **outputs, long sampleframes)
inside the plugin, and the plugin can be an effect (thus processing the inputs[<audio input #>][<sample>] where sample is < sampleframes
and then make some calculations and write them
to outputs[<audio output #>][sample]

So then the host has the sound buffers 'calculated' and can do whatever it wants with them (send them to soundcard via ASIO), or mix them with buffers of other plugins or audio, or send them to a file.

Midi Input for a plugin is handled in the processEvents(VstEvents *events) routine.

Ahhhh - just took a look at Zynewave Podium. So the idea then is that the MIDI sequencing and audio recording is actually done by the VST "rack".
This still bothers me, though. If the links in my chain are already taking too long to pass data along, how can adding yet one more layer of software improve the performance? I will, however, download their free version and play with it in the hopes that they have somehow violated the laws of physics.

There are just 2 programs. The host doing MIDI sequencing, MIDI recording, Audio Recording...., and the individual instrument plug-in which just listens to MIDI events and fills up an audio buffer.

However, I still think that *most* of your latency delay is caused by using MME drivers.

I can post binaries here? I had figured (hoped?) there would be a repository somewhere that all Zyn users could access specifically for sharing patches. If that doesn't exist, then I guess here is where I will share them. How do I do it?
I am kind of curious why the patches are stored in binary - perhaps that made sense when Zyn was being run from a floppy, but I can't imagine any performance hit nowadays to storing them as XML ASCII text. Something else to look into, I guess.

Binaries... well they are actually XML ASCII text, in zipped form. Why would anybody mind sharing those? (talking about those xmz files..). You can actually unzip those and get the actual XMLs.

I certainly would - but my question was more about where the "rest" of the Zyn users / coders hang out, and just how technical I should get on this forum. Between the several forks, there have been a few thousand downloads - are the only 5 people actually using and discussing the app here on this forum?

If you're working on windows, I really haven't seen any other decent discussion places. Maybe I wasn't looking deep enough. Of course if you find any, please share. There are not too many people talking about the technical side of Zyn for windows. And there are probably 4-5 developers still working on the linux version.

[ishkabbible]

So, I downloaded and installed the ASIO4All driver, and downloaded the free version of Podium, and I was able to actually get jackoo's DLL to make noise. However, I had to crank my buffer size up to 900 bytes before the little skips in the sound mellowed out. I clearly need to claw my way up the Podium learning curve now, but it appears to be a reasonably full-featured multi-track recorder / editor. I like the idea of keeping the MIDI and the audio together, will be nice if / when I decide that I would like to change a voice, or overlay the same melody in a new voice.
I did notice one disturbing thing - the instruments and full setups that I have saved from both the first brain dead version and then from the SonicPorts 2008 version don't sound quite right when loaded into this version. They have gone from fat to kind of flat, almost like the random phase shifts are no longer random (see http://dilbert.com/strips/comic/2001-10-25/), or my multiple, layered-and-slightly-detuned voices have all been put back into unison. I will have to explore this more - fortunately the ASIO driver seems quite happy to let me run Zyn both inside and outside of Podium simultaneously so I can do side-by-side comparisons.
I also noticed that the VST version seems to have issues with the configuration file - whenever I first load it it complains that it can't find the file and is creating a new, default one, but the next time I load it it says the same thing so it obviously DIDN'T create a new one.
Anyway, plenty to keep me busy. My real life job has gone from mellow to batshit crazy over the last couple of weeks, so I won't have much time to play until I get a few major fires put out. The light at the end of the tunnel really IS an oncoming train.

[ishkabbible]

Also, I do have a question for the wider audience here - If I decide that this project is worth actually spending some money on, is there a list somewhere of sound cards with native ASIO support? Any recommendations? Particular brands that have a good rep in the community?
IT doesn't seem to be a big selling point since manufacturers don't seem to brag about it much.

[jackoo]

about the config issue that's sort of my fault.. Because i didn't spend enough time to dig on how I could find the current path of the running dll in execution, and i didn't know where to searsch for the banks.

So i did it the dumb way: C:\ZynAddSubFX is the path hardwired inside the dll. But it won't create that folder for you. You have to make it manually in the C drive and at the first run, if the ZynAddSubFX folder exists zyn will write there a cfg file with defaults, and will read the cfg on the next runs. It is also a good idea to put the banks folder there also.

Also for best performance I'd say it's nice to put the internal buffer size in zyn (see settings or cfg file) the same as your real ASIO buffer or a multiple of that, better a power of 2.

[ishkabbible]

C:\ZynAddSubFX is the path hardwired inside the dll.

Ahhhh - I *do* remember seeing something about that in the readme. My bad.

[bitwise]

Other issues about portabilty:


A)

In Alienwah.cpp, 'out.real()' causes troubles

Code: Select all

        
out = tmp * oldl[oldk];
out.real() += (1 - fabs(fb)) * smp.l[i] * (1.0 - panning);
...
out = tmp * oldr[oldk];
out.real() += (1 - fabs(fb)) * smp.r[i] * (1.0 - panning);

perhaps in the original compiler (gcc ?) 'out.real()' returns
a reference to the real part, but that's not the case in MSVC, so:

Code: Select all

        
out = tmp * oldl[oldk];
out = complex<REALTYPE>(
  out.real() + (1 - fabs(fb)) * smp.l[i] * (1.0 - panning),
  out.imag());


out = tmp * oldr[oldk];
out = complex<REALTYPE>(
  out.real() + (1 - fabs(fb)) * smp.r[i] * (1.0 - panning),
  out.imag());

B)

Variable length arrays are not supported in MSVC.

These are defined, as local variables,
in methods in the following files:

adnote.cpp
REALTYPE unison_values[unison];

oscilgen.cpp
REALTYPE oscil[OSCIL_SIZE];


padnoteparameters.cpp
REALTYPE harmonics[OSCIL_SIZE / 2];

REALTYPE spectrum[spectrumsize];

int profilesize = 512;
REALTYPE profile[profilesize];

REALTYPE adj[samplemax];



they could be allocated dynamically:

Code: Select all

REALTYPE *oscil = new REALTYPE[OSCIL_SIZE];
...
delete[] oscil;

but if those functions are called inside the "audio" callback
this might be not a good idea.

It seems to work though, so either they're not in the callback
or they just lower the margin for glitches.

I notice that the vst version, ZynAddSubFX-VDX_VST-2.4.1.480beta,
allocates dynamically, but perhaps it doesn't free the buffers.

or

2)
preallocated as class members (fields)?

[ishkabbible]

AARRGGGHHHH - I will post this over on the Zynewave forum as soon as I am confirmed, but thought I'd toss it out here in case anyone here is using Podium with the ZynAddSubFx synth. The 2.4.1.480beta loads and plays just fine in Podium, but for some reason only the MIDI gets recorded. I see the level meters moving with the sound, and the sound comes out of my speakers when I am recording, but once I am done I can't for the life of me find the audio - the "Master" track is a flat line, and the audio waveform that is shown in parallel with the MIDI piano roll in all the pictures in the manual and tutorials just isn't there.
I am assuming this is a case of user error rather than something with the plugin, but after gnawing on this bone for 2 days I am at my wits end.
Help?

[jackoo]

very sorry to hear you have problems with Podium... I must confess I never actually attempted to reder to audio... I'm also having a little vacation moving alon across the UK for a while ... So I can't really check what's going on.

Just some ideas.. Can Podiom render the audio in realtime and not faster?

Did you try another VST plugin? There are a lot, freeware out there....

Is there an option in Podium to disable multithreading for audio?

Did you try version 490alpha of zyn? Fixes some unloading bug visible on win7 64bit... Some pointers were deleted twice i think....

Is multichannel option in Midi window in Zyn switched off? Otherwise audio output1 is not used...

Is buffer size in zyn the same as ASIO buffer size?

...i'm out of ideas for now... Hope you find how to fix it.

[ishkabbible]

very sorry to hear you have problems with Podium...

The folks on the Zynewave forums were very helpful. Your code is fine
The bug was in my entire understanding of the "new philosophy" of electronic music recording. The thought that the MIDI track was the fundamental "unit of storage" and that audio was a byproduct, generated as needed, would never have crossed my mind. But that is how Podium works. Apparently you are expected to create all your tracks as MIDI, edit as necessary, apply all effects by commanding them, while somehow managing to keep all your patches aligned with their respective tracks (I guess by running as many instances of of the VSTi as you have tracks, where somehow Podium knows how to set up each instance when you reopen the project) until everything is the way you like it, then push "GO" and "render" the entire thing to audio by running everything all at once! No wonder people are clamoring for a 64 bit port. Mark my words, they'll be clamoring for an MPI port next
(for the uninitiated, MPI is a system that distributes a job across all the nodes in a Beowulf cluster, allowing you to use as many CPUs as you can afford)
Anyway, I'm off and running with this new paradigm. It *does* solve the latency issues, tolerable even with my ASIO4All buffer set to 1024 to coddle my brain dead audio hardware. If I have a new piece recorded by the end of the weekend, and I haven't pulled out too much of my hair in the process, I'll admit you were right, spring the $50 for a Podium license, and get to work on the VST version of ZynAddSubFx.

And I have a new project on the complete other end of the technology spectrum... This is exactly how I got it. The guy who gave it to me says all the parts are there but it didn't work when he took it apart. He gave it to me because it is based on a Z-80 processor, and I spent many years writing Z-80 assembly code.
Gotta keep my old skills sharp too!

[jackoo]

splendid! I can't wait to hear some ZynAddSubFX tracks on souncloud.

I'm actually glad you also checked out the VST option, also because many users who make music on windows use it today that way.

Cheers and have an inspiring weekend.

[ishkabbible]

I downloaded the demo version of Podium to see how well it scaled to multiple processors, and discovered that ZynAddSubFx doesn't play well with itself in a multiprocessing environment. I was getting all kinds of odd beeps, boops, twangs, and other assorted noises that sounded like the synth was occasionally running random patches (definitely NOT buffer over/underflow type noises). As soon as I turned off the "plugin multiprocessing" option it seemed to straighten up and fly right.
Is this expected? Is the ZynAddSubFx VST multi-processing aware with bugs, or was I totally abusing it and just lucky that it didn't let the magic smoke out of my motherboard?