Finally got it to build with Visual Studio in Windows.

[ishkabbible]

I just found out that the 'stick' part of your patch sounds quite wrong...

I had never considered the buffer size affecting the sound in that way. I will look into it. Along the same lines, in the ASIO universe, who controls the buffer size? Does the application tell the driver what buffer size to use, or does the driver tell the application? (or neither and it is up to me to make sure they match?) Same question for VST - do the host and plugin negotiate on buffer size, does the host give the plugin a buffer and the plugin has to live with it? etc.

I suppose this was the way you intended for it to sound...

LE: Now I do see that the standalone *does* sound quite different...

The standalone with both the output and oscillator buffers at 512 is what it is supposed to sound like.

Does the wrong sound also gets solved for you if you increase the internal buffer?

I'll let you know once I figure out what the hell Cubase did to my system and get it back working again.

Also, I MUST congratulate you for your synthesis skills.... amazing!

Thank you. I've been doing this (with the help of computers) for a long time. And I do have to give a lot of credit to Dario Straulino for the idea of breaking the sound into 4 voices - I was trying to do it all with 2 and it just wasn't quite right.
But I started playing around with analyzing audio back in the late 60s on an IBM 1130 (http://ed-thelen.org/comp-hist/mak-IBM-1130.html) - my early codes for analyzing harmonic content vs. time, using the newly (re-)discovered FFT algorithm, had to run overnight on the 300KHz processor (which was actually blazingly fast for the time), and the output was on a 1627 drum plotter. Now that I can throw some real compute power at the problem, I can easily visualize the harmonic structure through time ( - this is the crash cymbal I am working on, at roughly half speed) which gives me a good head start on creating a patch to mimic it.

I love the Subsynth for doing these metallic "crash" type of sounds, because the sounds have closely spaced non-harmonic frequency peaks all the way from DC to light. In the analog world, I would be using a couple of ring modulators with filtered white noise ("pink" noise) on one input and some harmonic-rich waveform on the other. I can get nearly the same structure with the subsynth by starting with a very low fundamental frequency (I think I used 135Hz for my ride cymbal), then suppressing the first 5 or 6 harmonics and opening up the bandwidth. One bug in the synth that I intend to fix sooner than later is that for some reason the AddSynth disables the ring modulator when you select the white noise source (why?). I might even be inclined to add a ring modulator in the effects path, where it could have access to 2 independent voices.

Anyway, everything has to wait now until I rebuild my audio / MIDI system. GRRRrrrrr

Your CPU load numbers make perfectly good sense compared to mine. I am running a quad 2.4GHz CPU (~18% slower than yours, so for single CPU stuff your 80% is my 100%), 2GB RAM, Tascam US-600 audio system with native ASIO, WinXP SP3 32 bit.

[ishkabbible]

@FrettedSynth said

I did a bit more testing and it seems as if the sonicports ASIO version does not talk well with ASIO driver in the soundcard.

From the breadcrumbs I found in the sonicports code, I am reasonably certain that my 2008 build was with version 1.6 of the ASIO SDK (I think the current version is 2.4), so your 2005 build was most certainly built with a very early version of the ASIO code. One would hope that the code has improved significantly in the last 7 years, and It wouldn't surprise me in the least if the old code has "issues" talking with a driver built on the later code.

As soon as I can clean up the mess Cubase made of my system, I will get back to work on compiling the sonicports ASIO standalone with the 2.4 SDK (I think I figured out why the compile fails), then hopefully it will start behaving like a "real" ASIO program.

[ishkabbible]

Whew!
I never thought I would say "thank god for a m$oft product", but thank god for system restore. I was able to rewind my machine to Tuesday before I installed Cubase, and now the sun is shining , the birds are singing , everything is working again , and I learned a valuable lesson.

The standalone with both the output and oscillator buffers at 512 is what it is supposed to sound like.

I forgot to add that you also need to turn off the reverb that is enabled by default in the stand alone version (another thing I intend to fix, although it appears you already fixed it in the VST version).

[FrettedSynth]

@FrettedSynth said

I did a bit more testing and it seems as if the sonicports ASIO version does not talk well with ASIO driver in the soundcard.

From the breadcrumbs I found in the sonicports code, I am reasonably certain that my 2008 build was with version 1.6 of the ASIO SDK (I think the current version is 2.4), so your 2005 build was most certainly built with a very early version of the ASIO code. One would hope that the code has improved significantly in the last 7 years, and It wouldn't surprise me in the least if the old code has "issues" talking with a driver built on the later code.

As soon as I can clean up the mess Cubase made of my system, I will get back to work on compiling the sonicports ASIO standalone with the 2.4 SDK (I think I figured out why the compile fails), then hopefully it will start behaving like a "real" ASIO program.

When I did a search for ZynAddSubFX sonicports ASIO the 2005 version was all I could find, but from the sounds of what you mention the 2008 version is still quite out of date so it still would not help. I wish I understood code the way you guys do, but I am just an old bass player who loves gear and the sounds this synth can create.

I would very much appreciate if you could share any updates to the Zyn ASIO version and would like to help in any way I could?

Joe

[ishkabbible]

I found the 2005 version first as well. If you found the same one I did, it has some serious math issues (have you noticed that half of the patches in the banks folder just make awful screeching noises? And sometimes even just one note makes an awful noise while the rest of the notes sound fine? It took me a while to locate the 2008 build from sonicports.
You can download it here: http://sourceforge.net/projects/sonicpo ... on%202008/

[FrettedSynth]

I found the 2005 version first as well. If you found the same one I did, it has some serious math issues (have you noticed that half of the patches in the banks folder just make awful screeching noises? And sometimes even just one note makes an awful noise while the rest of the notes sound fine? It took me a while to locate the 2008 build from sonicports.
You can download it here: http://sourceforge.net/projects/sonicpo ... on%202008/

Wow thank you for this, it seems as if ASIO had been worked on in the 2008 version? When I set (File\Settings) sample rate to 48khz, buffer size 128samples and restart Zyn it shows on my M-audio control panel as correct.

The latency is much more usable and I still have no break-up I have always left the OscilSize to 512 as I am not 100% sure what it does? I thought that was the size of the compiled waves used internal and thought it would not affect latency as much as it would the tone?

Joe

[FrettedSynth]

Damn, even at 48khz with a 64sample buffer I have no break up? Latency feels very good compared to the 2005 version. And again when set in Zyn than restarted it all registers correct in my soundcards control panel.

[jackoo]

Along the same lines, in the ASIO universe, who controls the buffer size? Does the application tell the driver what buffer size to use, or does the driver tell the application? (or neither and it is up to me to make sure they match?) Same question for VST - do the host and plugin negotiate on buffer size, does the host give the plugin a buffer and the plugin has to live with it? etc.

The user sets the ASIO buffer in control panel (so the driver is the master here) to set the balance between latency and CPU load. In previous posts, I made an embarrassing confusion: the size of the ASIO buffer is measured in *samples* and not in bytes. The latency is therefore the length in time corresponding to one full (first) buffer.

latency [ms] = ASIO size[samples] / Sample rate [kHz]

That's why I said that 512 buffer size @44.1kHz is almost 12ms. The larger this buffer, the greater the latency, and the more time the CPU has available, in order to compute the buffer, so for low buffer sizes you stress the CPU harder, which usually causes clicks and artifacts.

The host application should interrogate the driver and set its buffer size accordingly. The VST plugin can somehow ask the host what the buffer size is, through the VST API. I don't think there is any negotiation... I don't think the plugin has anything to say to change the driver's buffer size, but I *could* be wrong. So yes, as far as I know, the plugin has to live with it.

Zyn VST is not smart enough to check this so it checks its cfg file. Although the VST *does* interrogate the host for the sample rate

I was able to rewind my machine to Tuesday before I installed Cubase, and now the sun is shining , the birds are singing , everything is working again.

Wonderful news!

BTW: What 'gear' did you use to plot that spectrum vs. time?

[FrettedSynth]

The user sets the ASIO buffer in control panel. The VST plugin can somehow ask the host what the buffer size is, through the VST API.

Most applications should be able to set the sample rate and buffer from their preferences? Most soundcards should be able to receive that data from the host and set to match on run. I do have a Tascam US-800 that will set the sample rate from the host but it dictates the buffer from its control panel.
The plug-in will have to use what ever is set in the host and compensate for the change.

Zyn VST is not smart enough to check this so it checks its cfg file. Although the VST *does* interrogate the host for the sample rate

Somehow I think this is why I can run the newer 2008 ASIO standalone at 48khz sample rate and a 64 sample buffer with no breakup, but the VST running in a VSThost with the same setting will crack and pop? IMHO it has to do with the way the buffer is handled in the Zyn.VST? But again I am no coder or engineer just an old musician.

Joe

[jackoo]

Most applications should be able to set the sample rate and buffer from their preferences? Most soundcards should be able to receive that data from the host and set to match on run. I do have a Tascam US-800 that will set the sample rate from the host but it dictates the buffer from its control panel.
The plug-in will have to use what ever is set in the host and compensate for the change.

Yes, the 'recording' application can set the sample rate, but I believe the ASIO buffer size is not so easy to set.

And in the VST, try to manually set the buffer in the settings dialog to match the driver. But as I noticed, a value less than 512 may produce 'wrong sound' when used with ADDSynth, under some conditions.

This may have to do that the buffer size should not be less than oscil size. And the VST crashes for oscil size < 512. It may do with the number of harmonics that's being made available for ADDSynth.

But I started playing around with analyzing audio back in the late 60s on an IBM 1130

Wow... that's one mean machine... I've been looking over the manual out of curiosity... this was before the first microprocessor...

I'm surprised to see that the basics of computer architecture were as they are today... back in the 60's... (or at least seems to be when I look over the instruction set)..

[ishkabbible]

Glad I could help!
Once I get the code to compile with the 2.4 ASIO SDK I will have to find someplace to post it. If I say pretty pretty please maybe Jackoo will give me write access to a little corner in his sourceforge project for standalone versions.
It appears that the sonicports project has been abandoned - is there any facility in sourceforge for someone to come along years later and pick up where the original author(s) left off? Or is the "proper" way to do it to download their files and start a new project?
And this brings up an interesting administrative / political issue:
It seems to me that right now Zyn is all forked up
There is the sonicports standalone windows version, Jackoo's VST windows version, some other fork that I read about ("yoshimi"?), a linux version, and I don't know if Paul still has a dead project out there. And there is a place and a need for all of these: The windows standalone version is perfect for stage musicians - I know a few who would kill for a synth with Zyn's capabilities and nice, fat sound. A mac port would draw in even more in this class. The VST version is great for studio work. And there appears to be a very active linux music community.
I know I'm the new kid on the block, but it seems to me that all of these would benefit from operating on a common code base. I understand that there is some politics involved, perhaps some bad blood here and there. Is there any chance of us all getting together and just getting along? The unix guys would have to put up with a bunch of #ifdef WIN32 (or #ifdef WIN64), the windows guys would have to remember to add them where necessary (and both groups would have to do regression testing on the other platform, or toss new code over the fence to the other group), and the sonicports code is already set up to compile as either standalone or VST, so we know that those two can operate on a common code base. (And I'd be happy to teach jackoo that mutex is really his friend )

Am I dreaming here? Or are these groups just too far apart in their goals, management, and organizational structure? Any thoughts?

[jackoo]

no bad blood from my side

I'd be most happy to share, but I actually *don't* have a sourceforge account...

So actually there's no official storage space for my version... It's hosted on mediafire, and kept alive by this forum.

I took the code from what I think was a port earlier than what is at sonicports now. If you look in main.c there is " Native Windows Port 2005 by J&H, Audio Development Team, Germany". That is where the windows port originates from (I'm talking about a project in MSVS... before that, I think Paul compiled himself for windows using cyqwin). This *native* port is based on linux version 2.2.1.

I think the version from sonicports is also based on it (I don't think they are the same person... but I can't know for sure)

So I took that code, and replaced the files (except main.c) from the linux version of 2.4.0, and got it to compile at VST, and well... removed everything non-VST (because I, for myself, could not get a practical use of the standalone). Then I added stuff from linux version 2.4.1 (unison, legato-mode, updated reverb). Then I made my own 'Midi Learn' window for assigning CC's. Also added the possibility to have audio inputs (made use of the VST API) so I could apply zyn's effects to sounds generated by other synths.

During all this time, I posted my version of the dll on mediafire, along with the zipped 'SOURCES' folder.

Then I found that the GUI was created from the same thread that handles the AUDIO, and that was bad, and tried to put the GUI in a separate thread. I was totally new to programming with threads, and the pthread lib was not my best friend.

After I did all this, it was beyond my reach timewise to go back and put things back in the linux version, without breaking the synth in linux (i'm not really used to that development environment).

Maybe the linux developers (there was 'fundamental' on these forums) can also join the discussion.

BTW: I'd love to learn all about multithreading and mutex but at the time it was just too much for me. The communication between the GUI and the 'sound engine' was a tough topic for me.

Please use what I could manage to do so far (as in code ) for all good purposes... . It's just that I don't have the time anymore to be too involved... But I'll gladly give out whatever I've learned.

[ishkabbible]

The larger this buffer, the greater the latency, and the more time the CPU has available, in order to compute the buffer, so for low buffer sizes you stress the CPU harder, which usually causes clicks and artifacts.

I understand the latency vs. buffer size - you need to fill the first buffer before you hand it off to the host or driver, and that shows up as a delay. I do NOT understand the buffer size vs. CPU load relationship (and your recent test results seem to agree with me). If it takes me X ms to calculate 256 samples, it is going to take me 2*X to calculate 512 samples, and 0.5*X to calculate 128 samples. Where does this change the CPU load? I *can* see how the overhead involved in passing the buffer to the driver plays here, if I am passing twice as many buffers per unit time, I am incurring twice the overhead.
And speaking of experiments, I did one last night that has me very puzzled - I downloaded the MidiOut plugin that just pumps the Podium MIDI commands back out to an external MIDI device, used MIDI-Yoke to pipe this into the standalone Zyn, and had Zyn send the audio straight to the hardware. I figured this way I could get Zyn running on one CPU (which I know works well), with Podium running on another CPU. It didn't work that way. For some reason I was STILL pegging the CPU meter in Podium! And in this configuration (all other channels muted), Podium shouldn't have been generating any audio at all. I will continue to work this as a workaround to the killer-snare patch issue - it SHOULD work dammit

I'm surprised to see that the basics of computer architecture were as they are today... back in the 60's... (or at least seems to be when I look over the instruction set)..

The one thing you will see conspicuously absent is the stack - that wasn't "invented" for another couple of years, so recursion was nearly impossible. The CALL instruction copied the (PC)+1 into a reserved word immediately preceding the first instruction of the subroutine, then jumped, and the RETURN instruction was just an indirect jump to the address stored in that word. Parameters were passed by placing them immediately after the CALL (accessed by offsetting the return address), and the function was then responsible for incrementing the return address past the parameter block. Painful, but it worked.
I have always found it deliciously ironic that the FORTH language, which is nothing BUT a stack, was initially developed on the 1130

BTW: What 'gear' did you use to plot that spectrum vs. time?

I do almost all of my coding these days in a data processing package called "Igor" (http://wavemetrics.com/). It is an amazing environment, lightning fast, C-like compiled programming language, wonderful visualization capabilities, kind of like IDL or Matlab on steroids. I wrote all the ground data processing software for the Mars Odyssey Gamma Ray Spectrometer, both the commanding and data processing code for the TEGA instrument on the Mars Phoenix lander (getting NASA to approve my commanding code was "interesting"), and the data processing code for the Mercury MESSENGER Gamma and X-ray spectrometers in Igor. I actually use the same code I developed to locate peaks in the gamma ray spectra to locate the "important" frequencies in the audio spectra.

[ishkabbible]

I finally got the ASIO standalone to compile with the 2.2 ASIO SDK! Woooo Hoooo. Sounds like crap, but it compiles. I guess I have to actually RTFM on the SDK now.
Or download the latest portaudio.....

[FrettedSynth]

I finally got the ASIO standalone to compile with the 2.2 ASIO SDK! Woooo Hoooo. Sounds like crap, but it compiles. I guess I have to actually RTFM on the SDK now.
Or download the latest portaudio.....

If you need anyone to help test please let me know?

The windows standalone version is perfect for stage musicians - I know a few who would kill for a synth with Zyn's capabilities and nice, fat sound.

That would be me Have tried for years to have a version of Zyn that I could just play, but on windows the latency has either been too high or snap crackle pop was all I got Had a version running on puppy Linux with Jack that was great, very low latency lots of poly with no crap. But all the app's I use are windows so I eventually gave up on Linux for audio. For now that is! still want BeOS back.

Joe