Finally got it to build with Visual Studio in Windows.

[jackoo]

I am indeed aware that Zyn has a problem when the host is in multithreading mode, however that issue was sort of beyond my windows programming knowledge. I didn't know how to fix it

all I could manage to do (and i did it by my own selftaught non-standard newbie way ) is make a saparate thread for the GUI. In the original sonic ports project, the GUI is created in the same thread with the main audio, and refreshing and event handling was done using a 'clock signal' from the host. These caused the problem that the Host GUI didn't react well... You had sometimes to click twice to get a menu to show. That is fixed now (i think) but multithreading for audio is not something I could understand.

Hope the GUI theading implementation is fixable to a more standardised way.

[ishkabbible]

OK, that answers that. I hate interface coding because I know only too well how quickly it can eat my lunch, but I do have several friends at the "guru" level of windoze coding that I can take out for a beer and pick their brains.

Where is the best place to start for plugin interface programming? Is Steinberg the arbiter of all things VST? Any good forums you can recommend for plugin developers?

[jackoo]

I also hate writing GUIs... That's why I liked visual basic in the old school days... I could draw buttons and for demanding code I could write it in C inside a dll and call it from there.

I don't know whether the way I implemented the GUI thread has anything to do with the disruption of sound as you mentioned earlier.

Zyn's GUI is based on FLTK. Normally, a VST instrument uses a window handle from the host where it can draw its stuff... But somehow that didn't work out with FLTK. So within the window 'provided' by the host Zyn just displays a bitmap (in the dummy window) and then a new thread is created (using some methods in pthread lib... Yuck) and then new windows are created from within that thread. The nasty thing is that I used some global variables to talk between threads, and I don't think that's standard procedure. There's a variable 'ten' meaning 'thread enable' and to kill my GUI thread I set ten=0 and then wait some miliseconds...

Anyway... The GUI is drawn using fluid.exe which has the format *.fl - i think sonic ports also has the .fl source files.

In fluid you can draw your buttons and it will generate the code for you.
It has been suggested that it is possible to make a VST GUI using QT toolkit instead of FLTK... Maybe that's a solution for keeping zyn multiplatform.

I've seen some VST code demos implementing the GUI in QT, but I don't really remember where.

There is also a section on this KVR forum which deals with DSP and plug-in development.

Hope you have better luck than me
Cheers

[ishkabbible]

OK, I give up. I've now done everything right (fast machine, good low latency audio hardware with native ASIO support), and am convinced that I was right all along - this whole VSTi thing is a bad idea. Well let me rephrase that - it is a wonderful idea whose time has not yet come - it would appear that I need at least an order of magnitude more compute power to make it practical. Either that, or Podium is a POS.
My problem is this: I have a wonderful snare drum patch, but it is very complex, consisting of 4 individual patches (2 AddSynth and 2 SubSynth patches) running in parallel. When I run the stand alone, sonicports ASIO code, I can do snare rolls all day long without even making the my CPU load line wiggle. I have no latency issues, and the sound is nice and crisp. But when I try to run that same patch on the VST version in Podium, I can't even get through 1 second before the "CPU load" meter is pegged and I start losing audio samples, and it has 2 of my 4 CPUs running at 100%, and even when the CPU isn't pegged the sound is kind of muddy and awful. ANd while some of what I want to do with ZynAddSubFx will cut down on the CPU load (like linking in an FFT/IFFT library that runs on the GPU instead of the CPU), I can see other of my ideas munching up any CPU cycles saved there and then some.
I really like the idea of composing in MIDI and having the MIDI code visible in parallel with the audio. I am about half done with my next composition in Podium - I may try to finish it up just using podium as a glorified MIDI editor, then export the MIDI and use Jazz++ to feed it into the standalone synth.
I got a copy of Cubase LE5 with my new audio hardware - I will install it and see what the performance is like before completely abandoning the idea.
NOT a happy camper

[jackoo]

My problem is this: I have a wonderful snare drum patch, but it is very complex, consisting of 4 individual patches (2 AddSynth and 2 SubSynth patches) running in parallel. When I run the stand alone, sonicports ASIO code, I can do snare rolls all day long without even making the my CPU load line wiggle. I have no latency issues, and the sound is nice and crisp. But when I try to run that same patch on the VST version in Podium, I can't even get through 1 second before the "CPU load" meter is pegged and I start losing audio samples, and it has 2 of my 4 CPUs running at 100%, and even when the CPU isn't pegged the sound is kind of muddy and awful.

That doesn't sound right... Do you think you could somehow send me patches so I can try it on my hardware setup also using various other hosts?

I really can't believe that 2 AddSynth and 2 SubSynth patches kills the cpu so hard. I'd like to look into it, if you may.

I'm also quite confident that IF the patches are so hard on cpu, is not because of the VST framework.

Also... what sampling freq. are you using? hope it's not 192kHz. Actually I'm hoping it is precisely 44.1 kHz. I'm not sure what I did to the code that does resampling...

It's no use getting upset... . Maybe sometimes it's difficult to fix some things, and it takes a little bit of work, but usually things get solved.

I initially pointed out to Podium because as the best *free* DAW because it had all those functions in the free version. I actually never used it seriously with Zyn. If you're willing to pay for your DAW, there are probably better alternatives. That's why I'd also like to test your patches under different software environments (hosts)

So anyway... I'm quite surprised that your patches are consuming so much cpu... How many voices are generated per note? I would actually assume this drum patch would take almost no cpu time. I'm not sure where the problem lies, but would like to find out.

[ishkabbible]

what sampling freq. are you using?

I am running at 44.1KHz

If you're willing to pay for your DAW, there are probably better alternatives.

I am certainly willing to invest *some* money - I was ready to shell out the $50 for Podium *if* it worked, which at this point it isn't. I guess my pain threshold is around $100, might go to $200 if I REALLY like the program. But if I am going to pay $500+ for software, it better do its job absolutely flawlessly, and do my dishes and make my bed as well.
I just installed Cubase LE5, and will see how things behave there.

I'm quite surprised that your patches are consuming so much cpu...

I am too! And as I mentioned, when I run this patch in the stand alone synth it doesn't even make my CPU meter wiggle. I asked the Podium developer about his "CPU" meter, and he said that it is actually measuring the time it takes to fill an ASIO buffer vs. the total time (length) of the buffer. What I am seeing is the Podium CPU meter pegging almost instantly, while my real CPU monitor is showing that I have plenty of CPU margin. I'm not entirely certain how to interpret that.

Do you think you could somehow send me patches so I can try it on my hardware setup also using various other hosts?

I'll zip up the patch and a MIDI file that drives it crazy and send them to you this evening.

There is also the other issue that I mentioned before, and that is the sounds just aren't "right" in your version. They sound kind of muddy, or "flat" when compared to the same patch in the sonicports code, and there are some very odd cases where they are just wrong. For example, I have a crash cymbal patch I've been working on. It uses the addsynth with the ring modulator to generate the "ping" of the stick hitting the metal, then the subsynth for the actual "crash". I set the relative levels so when I smack it from my keyboard the stick hit is just barely audible, but when I render the track, the stick hit is MUCH louder relative to the crash.

I think a big part of what is pissing me off is that nearly all of the "issues" I am having seem related to the DAW and the interactions between the synth and the DAW. Now that I fixed my crappy audio hardware issue, I can use windows as my DAW with no serious latency issues. I just don't see the compelling advantage of a DAW that would justify me having to spend time screwing with it. If the DAW just worked, I would have a different opinion.

[FrettedSynth]

When I run the stand alone, sonicports ASIO code, I can do snare rolls all day long without even making the my CPU load line wiggle. I have no latency issues, and the sound is nice and crisp. But when I try to run that same patch on the VST version in Podium, I can't even get through 1 second before the "CPU load" meter is pegged and I start losing audio samples.

This is the same results I get with the VSTi version compared to the sonicports ASIO version from 2005. But the standalone sonicports ASIO version with the same buffer settings as my VST hosts 64samples, 48khz seems to have much more latency than the VSTi? Although when I check my soundcards settings it says 64samples, 48khz with the standalone?

Joe

[FrettedSynth]

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.

When I change the sample rate in (File\Settings) restart then look at the soundcards control panel, the soundcards sample rate changes to match what I set from the sonicports settings menu.

But if I change the buffer size in (File\Settings) restart then look at the soundcards control panel, nothing changes? So somehow the ASIO version is not reporting the buffer size right to the soundcards ASIO driver?

Joe

[jackoo]

as far as I know the sonicports ASIO version isn't really ASIO.

[ishkabbible]

I have been using a 3/10/2008 build of the sonicports code for comparison. I will try to reproduce FrettedSynth's results. For my quick test last night I had the buffer and oscillator sizes at their 512 default.

This is also something I need to check in the podium setup. Presumably I should have the synth buffer size matching the Podium buffer size?

[jackoo]

YES, try having buffers the same size

[ishkabbible]

ARRRGGGHHHHH
I am now officially very angry with Steinberg. I installed their Cubase LE5, found that it has exactly the same CPU overload issues that Podium has, and uninstalled it, and the bastards scrambled my MIDI and audio drivers! Now NOTHING works. Jazz++ crashes, the standalone ZynAddSubFx crashes, Midi-Ox crashes, and Podium crashes. They are like a psycho ex girlfriend - if I can't have you then NO ONE CAN.
Steinberg: "All your driver are belong to us" $&%^#%!!!!!!!!

[jackoo]

ARRRGGGHHHHH
I am now officially very angry with Steinberg. I installed their Cubase LE5, found that it has exactly the same CPU overload issues that Podium has, and uninstalled it, and the bastards scrambled my MIDI and audio drivers! Now NOTHING works. Jazz++ crashes, the standalone ZynAddSubFx crashes, Midi-Ox crashes, and Podium crashes. They are like a psycho ex girlfriend - if I can't have you then NO ONE CAN.
Steinberg: "All your driver are belong to us" $&%^#%!!!!!!!!

Ouch!!
Unbelievable! I've never had this happening to me, but then I never uninstalled Cubase...


On the other hand...

I've just started to play with your patch and the midi sequence...

First results:
tempo @130 BPM => Asio load of 50%
tempo @250 BPM => Asio load of 80%
(no actual smoke, no clicks or artifacts... but yes... too much load for one patch)

(Asio load is what the DAW reports...)


My specs:
Soundcard: M-Audio Revolution - native ASIO drivers
CPU: Intel Core2 Duo E7500 @ 2.93GHz
RAM: 4GB
ASIO Buffer: 256B
Sample Rate: 44.1kHz
OscilSize=512 (internal zyn param)
DAW: EnergyXT1.41 (single threading host, uses one core only)
OS: WinXP SP2 32bit

Most of (all) the cpu load is from the SUBSynth engine.
If I look in a taskmanager, the cpu load is lower than what the DAW reports.
Comparing cpu load in taskinfo I see similar load on the standalone exe and the VST (but I can't really call this an accurate measurement, because I compared playing with the mouse on the virtual keyboard).

I agree the cpu load is very high for just a SUBSynth patch... Key parameters for the load seem to be number of harmonics used and the release time of the amplitude envelope..

Still looking this up... I will try also with other hosts and report back.
Could you please state your specs also (cpu, buffer size, etc..)


LE: 85-90% load @250BPM in Cubase5 (same settings)

[Alfa210]

Test in savihost...

Check Temper, also.

[jackoo]

There is also the other issue that I mentioned before, and that is the sounds just aren't "right" in your version. They sound kind of muddy, or "flat" when compared to the same patch in the sonicports code, and there are some very odd cases where they are just wrong. For example, I have a crash cymbal patch I've been working on. It uses the addsynth with the ring modulator to generate the "ping" of the stick hitting the metal, then the subsynth for the actual "crash". I set the relative levels so when I smack it from my keyboard the stick hit is just barely audible, but when I render the track, the stick hit is MUCH louder relative to the crash.

I just found out that the 'stick' part of your patch sounds quite wrong... I initially had the internal zyn buffer size set to 256B. It sounded quite loud and very high-pitched. Then I set the internal buffer size to 512B. Then the 'stick' turned into a warm sound, sort of a kick sound, much quieter. I suppose this was the way you intended for it to sound... Can't explain now why this happens.

Now if I keep internal zyn buffer to 512, and soundcard ASIO buffer to 256, I hear overload artifacts and clicks. If I put then the ASIO buffer to 512 (same as internal zyn buffer) then I have no more clicks, but latency doubles (gets about 12ms). The CPU load unexpectedly doesn't get any lower, still at 80% @ 250BPM.

I say unexpectedly, because I expect for the ASIO load to drop, when increasing latency and the ASIO buffer.

BTW: When you compared cpu load performance to the standalone, did both setups had the same latency? Because if not, you cannot compare the two... the higher the latency the less cpu time required.

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

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

Also I hope you get to 'fix' your system and driver related issues

LE: Now I do see that the standalone *does* sound quite different (especially the SUBSynth component)... lots of mysteries...

LLE: OK... I'm lost for the day.... shouldn't the same mathematics give out the same audio signals, regardless of how they reach the soundcard??? Or is 'white' noise a different shade of white ... with each compile.......