Finally got it to build with Visual Studio in Windows.

Official support for: zynaddsubfx.sourceforge.net
RELATED
PRODUCTS

Post

ishkabbible wrote: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.
Yes, I suppose you are correct... But still thinking about it...

Isn't calculating 512 samples going to take a *little* less time than twice the time it takes to calculate 256 samples? Because of caching and branch prediction... and the way the OS assigns CPU cycles to your code...

It is just a gut feeling, that the more time you give a modern CPU to do the same operations over and over again, it will increasingly do them a little bit faster because it optimizes itself even at hardware level. Please correct me if I'm wrong..., as I said this is more of a ...feeling... I may be saying complete rubbish.

ishkabbible wrote: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 :(
uuh... that's indeed weird... will think about it.

Even if Podium is running on one CPU and standalone zyn is on the other.. they still have to talk to eachother... I'm not sure how MidiYoke deals with this. Another way to have the host on one CPU, and the plugin on another CPU is by bridging them, with a tool like jbridge. I use this when I play with my host, EnergyXT, because this host doesn't support multicore. Hmm...

LE: Ok, forget about jBridge...

I tried the same thing you did, but in EnergyXT.
In the host, I set the output driver to MME (too free the native ASIO driver) and routed the midi out through Midi Yoke to the standalone version (ASIO build). It sort of works, and I see *no* CPU load in EnergyXT, and the only program that's using the CPU being Zyn standalone exe. However! I still hear cracks in the sound if I'm using the ASIO build of the standalone!! If I use the MME version then I hear no cracks but the latency is huge.

To sum it up... if I use the ASIO build, I cannot play around with my mouse on the virtual keyboard without cracks (using the killer patch)... with or without MidiYoke, or other software. Can you?! :shock:

LLE: I tried the standalone asio 2008 with 512 buffer size, 512 oscil size and 512 ASIO buffer from soudcard's control panel. And I cannot madly play with the mouse without hearing cracks. While on EnergyXT + VST at the same settings (512 everywhere) I already have a hurting arm while moving the mouse left and right with no cracks in audio. It's strange if it happens the other way around with your setup... Did you originally tried with the asio standalone, or the MME, during your first performance tests?
Last edited by jackoo on Sat Aug 18, 2012 5:02 pm, edited 2 times in total.

Post

:-) I have to say thanks again for making me aware of the sonicports 2008 ASIO version. Been playing since my last post and it sounds heavenly. Still seems to be setting my M-audio samplerate and buffer perfect from zyn's File\Settings, latency feels real good. What ever change was made from the 2005 version seems to have fixed talking with the soundcards ASIO driver :-)

Post

This is interesting to read:
http://www.gearslutz.com/board/music-co ... usage.html
gearslutz.com wrote:Typical offenders are network card drivers (especially wifi) and graphics card drivers (ie, the solution is to disable/replace the device or get a version of the driver that reduces or eliminates the problem.)
also the tool can be found here:
http://www.thesycon.de/deu/latency_check.shtml

Post

@FrettedSynth -
With a little luck there will be a 2012 ishkasonic build before long. And with a lotta luck, it might even be an improvement on the '08 build. :D

Post

This is interesting to read: ...
Thank you. That makes a helluva lot more sense, and is basically what I surmised above. It is the per-buffer overhead (and perhaps some of the other crap going on) that is killing me. The machine I am using is the house server, so it has other jobs running at all times.
Making Zyn (and everything else) multiprocessor needs to happen sooner than later. Moore's law has bumped its head on the physical limits of getting heat out of the chip - 200W / cm^2 is a LOT of heat, so we simply are not going to see a 4GHz pentium outside of liquid-cooled supercomputers. WE will, however, be seeing 8 and even 16 core, 2.5GHz chips at affordable prices within the next couple of years. The *right* answer to Subsynth's CPU-hogging ways may well be to fire it off in its own thread with a slightly elevated priority so it can monopolize one CPU while leaving the rest free for other stuff.
I have spent a few hours staring at the code now, and I think I am getting deep enough into Paul's head to have a feel for what he is going to do next. I am almost ready to start fiddling...
Image

Post

ishkabbible wrote:With a little luck there will be a 2012 ishkasonic build before long
Hopefully also a VST version for the rest of us mortals :lol: :hihi:

If you fire a new thread, can you also tell it to run on a separate core?!

Post

I don't think we would want to "tell it" to run on a different core, since some people still have only one core. What we can do it give winders permission to run it on a different core if one is available.

I will take a long hard look at the VST SDK and at your VST code to try to understand how a multiprocessor application should interact with the VST host, but I will have to rely heavily on you on that score.

I just looked at the most recent release of the portaudio library, and it looks much improved from the one used in the '08 sonicports build. As much as I hate to think about it, it may well be time to bring all the libraries up to date (including *gulp* FLTK)

Post

If I may chime in on the multicore issue.

While it would be nice to shove subsynth to another core, it does introduce some non-determinism into the program, which conflicts with the need for low latency in audio programs. If your program had the entire computer to itself, then this would be a fine approach, but you do need to contend with the system's scheduler. This could introduce sufficient jitter in how long the calculations take to prevent the program from reaching its time deadlines. I am sure it can be done, but I am sure it will be easy to shoot one's foot in the process as concurrency is very easy to do incorrectly. (this is not mentioning any of zyn's existing threading blemishes and the difficulty of implementing this within zyn) [also it is typical that all audio processing is done on one core for these reasons currently]

PS. jackoo, if you have not unrolled the main filtering loop of subsynth, you can get about a 20% speed boost there (see zyn's source)
One of the developers on the ZynAddSubFX open source synth
The author of the Zyn-Fusion UI for ZynAddSubFX

Post

concurrency is very easy to do incorrectly
Indeed. But isn't this already a solved problem? From my (admittedly limited) understanding, the multi-processor DAWs out there do exactly what I am talking about just on a grander scale - they fire off each plugin (or each track) in its own thread, and let the OS manage it. Presumably they have some kind of a "gatherer" in the main thread that collects the buffers from the plugins as they come trickling in, then at the last second decides what to do about any missing ones.

It seems to me that you have to make the assumption that the sound generating code can operate faster than the sample rate, otherwise the whole concept makes no sense. Then the trick is to do something intelligent (and hopefully unintelligible) when you detect that the assumption has been violated.
Now from my reading of the Zyn code, it doesn't use this "gatherer" architecture, but instead relies on all the pieces summing their results into a common buffer as they are calculated. Which made perfectly good sense under DOS where memory was the scarce resource. But at least on the Intel architecture, there shouldn't be any efficiency penalty to filling one buffer, then summing it into a second buffer. Assuming they are the same size and properly aligned, I think the sum can be done in one instruction.
Sorry - rambling and thinking out loud.
:)

Post

> But isn't this already a solved problem?

Well, it is a problem that has solutions, but I would not say that it is fully solved. I have not played with too many DAWs, nor have I read through their internals, so I may have some incorrect assumptions about them. With that said, I would expect the DAWs to gain much more from multithreading when running in a sequenced rather than a live mode, as the deadlines are much softer there. With softer deadlines multithreading things in most cases will get you better throughput; It's a trade-off.


> It seems to me that you have to make the assumption that the sound generating code can operate faster than the sample rate

You seem to be thinking of this only in terms of throughput, which works with soft deadlines, but if you want lower latency then you need to factor in the time to properly sync the threads, which could be an issue depending upon the implementation.

> Now from my reading of the Zyn code

Well, if this was to be done to zyn, the obvious spot for the break would be at the part level, as each one of those is independent and IIRC, each one has its own buffer.

> Which made perfectly good sense under DOS where memory was the scarce resource

Just because you have more of a resource, it does not mean that it should be spent without a fair reason.

> Assuming they are the same size and properly aligned, I think the sum can be done in one instruction.

I don't know what instruction set you have on your machine, but the best instruction I can think of sums 4 packed floats in one instruction, which is much less than a standard buffer size.
One of the developers on the ZynAddSubFX open source synth
The author of the Zyn-Fusion UI for ZynAddSubFX

Post

when running in a sequenced rather than a live mode,
I am a newbie to the DAW world, but it seems that they have pretty stringent latency requirements because they are typically used in both live and sequenced mode simultaneously - playing back the sequenced tracks while you record the next track. Crazy way to run a railroad, but somehow they make it work.
Well, if this was to be done to zyn, the obvious spot for the break would be at the part level, as each one of those is independent and IIRC, each one has its own buffer.
I've done a little poking around on sourceforge, and what I haven't found yet is any "developer" documentation. Is there anything besides reading the code to help get someone up to speed?
While looking at that Subsynth filter loop I did notice that you guys have cleaned the code up (syntax wise) quite a bit since 2.2.1, which is the version I believe sonicpots started with. Thank you - that does make it MUCH more readable.
Just because you have more of a resource, it does not mean that it should be spent without a fair reason.
Very true. I was thinking in terms of using memory to buy time. But tonight's testing I think has invalidated my assumption that the CPU is the bottleneck, so I am having to rethink a bunch of stuff. I still DO think that multiprocessor is the way of the future, but it may not be as important for right now.
I don't know what instruction set you have on your machine
Sometimes I don't either :oops:

Post

Virtually all of the documentation (developer or otherwise) can be found at:
http://zynaddsubfx.sourceforge.net/support.html
There is some extra documentation that can be gotten from parsing the doxygen comments, but I am not sure how useful it would be.

If you need help on understanding anything about the program as a whole, I am usually idling in IRC ##zynaddsubfx on freenode. (also if any of the DSP does not seem to make sense, I should be able to help you there as well)
One of the developers on the ZynAddSubFX open source synth
The author of the Zyn-Fusion UI for ZynAddSubFX

Post

so we simply are not going to see a 4GHz pentium outside of liquid-cooled supercomputers
Well damn those clever little elves at Intel. I stand corrected. They just released the Core i7-3770. Four cores running at 3.4GHz sustained, 3.9GHz turbo. On 77W. That just makes my little heart go pitter patter :love:

Post

Well I completed my first recording using Podium and the VST version of Zyn.
I think I could get used to this DAW thing...
http://soundcloud.com/ish-kabbible/research
I called it "Research" from the old saying, "copying from one source is plagiarism, copying from many is 'research'" It is more of an arrangement than a composition - I have had this passage from Debussy's Engulfed Cathedral running through my head for about a month, so I just had to dump it on the keyboard. Maybe it will leave me alone now. And I have been playing around with harpsichord patches using some Bach/Pachelbel-ish riffs, and when Podium magically stuck them in the middle of my Debussy :roll: they all just seemed to fit, sort-of-ish and with a little encouragement.
I did find that the final mix from Podium sounded "muddy", so in the end I pulled all the bounced group 32-bit .wav files into Audacity and did the final mix there. That preserved the "brightness" that the Podium export was missing.

And introducing my kettle drum patch, and my new and improved low cymbal.
(I have one of those 4-pad MIDI drum controllers showing up sometime this week - gonna have FUN beating on those electrons with sticks!)

Post

WOOOO HOOOO! I am up and running on my new motherboard: quad 3.4GHz (3.9 max) Core i7, 8GB RAM, 512GB SDD, running Win7-64 - BWAHAAHAAHAA. :D
Podium works well with Zyn, and I can actually run 10 drum tracks (including 2 snare tracks) in real time without banging the stops. The only part of my system that I had to change (besides downloading x64 drivers for everything) was MIDI-Yoke, which had "issues," so now I am using another freeware product called "LoopBe1" (http://www.nerds.de/en/loopbe1.html) to connect between MIDI-OX and Podium.

I guess I just needed a CPU that can wait faster :?

Post Reply

Return to “ZynAddSubFX”