On this year's Linux Audio Conference there was a very interesting paper on threading, with real-world testing backing up what the authors said.

Their conclusion was that all programs should use exactly the same number of threads as there were processor cores (calculated at run-time) for maximum work distribution and throughput.

The experimental results, based on 4 cores, showed peaks where this was true, with typical exponentially lower peaks at x2, x4, x8 etc.

Thanks!!

at last i have a stable ZynSubFX in my vst folder

Subz

i'd love to help you with the UI on this. please click my sig to view my work and contact me if you want my help.

this has the potential to be a giant slayer

This is so huge.

Hopefully this time around we'll have a better looking, and better working VST version.

Cheers!

Thanks Matterblue,
i am giving a fast try to the VSTi and now it work.

Another thing: why your VSTi is 1.531.904 byte and the VSTi BETA5 (2005) is 1.650.688 byte.
There is some changes or is only a question of better otpimization made by compiler ?.

The size changes come probably mainly from using a 2 generations later (newer) compiler.
But there were also some internal changes applied. For instance: The 2005 binaries used an older version of a precompiled FFT (Fast Fourier Transform Library). I updated the library to the latest version and compiled those sources directly into the code. This way the compiler can do better optimization. But the optimization isn't made for size but for speed!

So that's anyhow a side effect. I also think, that the latest version is better performance optimized in general, because I removed several unneccessary float - double (and vice versa) conversations. The internal processing is consequently 32 bit (also inside the FFT routines). I decided to remove all internal 64 bit processing for a certain reason: VST requires generally 32 bit for the output (commonly). So I think it is a good idea to do all consistently with internal 32 bit floating point processing and not permanently doing internal conversions between 32 and 64 bit.

And I think, nobody really would hear a difference whether a plugin uses 32 or 64 bit internal processing. That's a marketing hype and nothing for real *smile*. Really.

Note: There isn't currently any SSE2/3 optimization set used. All the processing uses normal floating point units of the processors. Switching to SSE (especially with the internal FFT routines) probably needs exhausive testing. But Zyn - on the other side - uses FFT merely for preprocessing. Not so much for the realtime processes.

So: You don't need to be affraid. There's nothing missing inside... only some SlimFast cure ...

---

The UIs look great!!!
Especially the 'SilverBox'.

Did you took a closer Look at Zyn yet?
This synth is huge! There are many internal windows and an entire battery of parameters. It is even multitimbre (on 16 MIDI channels). So it's in principle an entire Audio Workstation itself !!!

Designing and implementing a new GUI would be really HUGE work for all parties...
That isn't made in a few days...

---

This needs to be known! :O ZynAddSubFX is finally in motion again!

Will be keeping close watch of this thread! Good luck with the project.

great isn't it?

A big thank you to all involved in ZynAddSubFX


the sound of this thing is unreal!

i'm starting a new course teaching the ungrateful youth music production at my local community center,

this & helix will be much welcomed there

Subz

matterblue; thanks very much. yes i have used zyn and it is a great instrument. the UI is confusing, but functional. i think i could help you there. how much flexibility will be afforded for UI redesign?

i've done many complex projects for many years now; including skinning/themeing shell replacements/os utilities in addition to the instruments/effects. i have seen how complex zynaddsubfx can get but maybe it could be tamed a bit by some patient men?

what the ... !?? can i believe this???is the development of this beauty finally continuing??? [is off to try] ....
damn, grym, yeees, do a gui for it! one screen only, with tabs for the sections ... will ya?

brok; you know that ease of use and comprehension are my two #1 goals. but i cant speak for matterblue about the migration from windows -> tabs -- this is something only he can say.

yeah, of course ....
i was just finger-dreaming, so to say ...
btw, do i have to download the whole developer package from sourceforge?
or is there a compiled version as a dll or an installer?
if so, where is it?