First thing. It was no small task, but I finally got the latest stable source to build under Visual Studio 2008. A few things of note:

1) For whatever reason, the MS compiler really balks at the functions in math.h being called the way they are being called in the program, I had to build several fix-up macros to keep the compiler happy (essentially explicitly casting the arguments...)

2) There are several instances where a buffer was initialized to a variable size. MSVC did not like this at all, so as a quick hack, I set all of those buffers to a fixed size. This increases the stack foot print quite substantially in some cases, but the alternative was to allocate the memory on the heap. A few related crashes later, and everything is humming along smoothly. The build I attempted under MinGW always had problems with hanging when trying to bring up the banks, or reading the config file, the VC build does not.

Only one oddity I found was in the fluid UI stuff: The combo boxes in some of the effects appear to have white text on a white background. I checked other builds and they all have white text on a green background. I diffed the code I had altered for the MSVC build and could find no difference. After looking at the .fl files in fluid, it seems that it was assigned that way. What happened?

Thanks for such a great soft-synth, btw...

>I finally got the latest stable source to build under Visual Studio 2008.

By any chance would you like to help make this a more official build?
Right now none of the developers on the official team are really windows people.
At this moment, there is also jackoo (on these forums) who has done some work on getting the windows VST to compile.
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.

>The build I attempted under MinGW always had problems with hanging when trying to bring up the banks, or reading the config file, the VC build does not.

Odd, last time I attempted to get something to work under cygwin, the compile took forever, but there did not seem to be a show stopping bug.

>What happened?
I recall seeing this in the past, but never tracking down why.
I think that it might be related with the fltk version having a tiff with some other local libraries.
I think that the problem disappeared when installing a more recent fltk version last I had it. (though this could be one of the minor glitches I saw when building in cygwin.)

I'd love to, I'll have to do some clean-up on what I have though, to make sure the build goes smoothly in both environments. I know there are some spots where I had to tweak the code a bit to get MSVC to accept it. There was an instance of a case statement that used ranges, rather than single values. MSVC doesn't allow ranges in case statements, so I needed to change that to an if-then-else structure. I hope I can keep what I've tweaked to stay within the standards.

Also, are there any objections to including with the VC project file the headers and prebuilt .libs of the dependencies? This would simplify things in terms of maintaining the build. If Zyn needs a new version of that library, that one could be brought down and recompiled to update the Windows version.

The alternative is that I could simply provide a binary for each release, but we know how that usually works out



Hmm, I don't remember seeing cmath anywhere. Honestly, I don't know why MSVC had such a hard time finding the proper overload. But, it was documented in the MSDN library as needing explicit casts in some cases.



Part of the problem might be my unfamiliarity with the MinGW environment. It appeared to be a bug similar to one reported here, dealing with a version of zlib going into an infinite loop. I looked at the patch that was given, but it seemed like it was already in the official source.



Generally, that's how it works



It almost appears as if the version of FLTK I'm using requires the parameters for the colors in a different order (Just a guess, since the button appears green, but the text background is white, in the other builds the text background is green, while the button is white)

Any chance of releasing, it might be more stable for some of us
This plug really deserves some loving attention on Windows as it is one of the best sounding synths out there

@ Guineh

Glad to hear somebody else is working on this. Some questions though:

1. Which exact version did you use for your port? Because a lot of optimizations took place after the stable official 2.4.1 (memset stuff, some changing of the structure of the classes, i think...) If you do not see cmath, you're not dealing with the latest code.

2. How do you deal with multithreading inside a VST? I'd also appreciate if Mark could elaborate on why there are so many different threads needed in linux, and why they use mutex. There should be a way to eliminate this. VST hosts like control VST in series, sequentially , not in multithreads.

I also believe multithreading inside the VST is reponsible for some GUI problems of the host (menu clicks not being recognised always and so on)

3. Does the latest sourcecode version that you compiled deal in anyway with parameter automation? I heard they were also working for this in the linux version.

I've tried also to integrate the latest changes in linux, but they are not compatible to what i've done in the 'Midi Learn window' and it takes a lot of time to sort through the changes

I personally think that it is a good idea to stick to MSVS for the VST, which is not 100% compatible to the linux compilers. So it would be difficult to integrate the VST code in the original because part of some code would not work on both platforms.

1 : using 2.4.1 at the moment.

2 : Not building the VST, just the Windows application build. Though it's conceivable that I could switch the config over to the VST version, my interest was more along the lines of building the standalone. As far as some of the UI Quirks in the VST, I think it may have to do with the tooltip display. I've noticed that if Zyn displays a tooltip, the host tends to miss a few clicks.

Really, the program needs a UI that would fit the VST plug-in model better, I'm not willing to tackle that. I'm happy to have it run standalone, and interact with a sequencer via midi.

Making code portable is a very complicated issue. You really need to separate out the Windows specific stuff, and make sure what you're adding is also available for the Linux side.

I'm more than happy to have you continue developing the VST plugin I more in it just to get a dang executable working in Windows w/o jumping through numerous hoops.

Just realized something.... This is what was causing me so much grief. I'd debug a crash when dealing with some of the buffers, and the program wouldn't terminate after the debug session. It would sit there as a zombie. Strangest thing I've seen. Even after killing Visual Studio, the program would still be there, zombified. Kept wondering why that happened...

As far as multiple threads go... I would guess to take advantage of multi-core systems.

I'll stop now before I expose my ignorance I haven't looked at the code in detail, yet.

A warning, this is a looong post:


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.


I would prefer to make use of cmake over the project file (less redundancy).
It also feels a little messy having prebuilt libs for deps, but quite reasonable
to do so, so no objection there.


Well, assuming that everything gets integrated, this should mean that there will
be a binary up on the official downloads page (I doubt every windows user
wants to compile from scratch)

>zlib...
Here is the link for reference:
http://sourceforge.net/tracker/index.php?func=detail&aid=294 6492&group_id=62934&atid=502312

Next Post

*opens can of worms*

Well, with the standalone program you need at least two threads.
One for the UI and one for the sound generation.
In the Linux version there are also some helper threads (like for midi).
(It was cleaner to implement with different midi and audio drivers).
If all things were done The Right Way (tm) then the mutex usage would be minimal
to nonexistant, but it was not done so.
The crux of the issue is passing messages from the UI to the internal structures
of the synth.
It is unsafe to directly modify them when building the sound is going on
(race conditions and stuff).
A mutex was used to make sure that these conditions did not happen.
As such there is now the issue that UI actions may block when the audio
generation needs to occur causing stutters.

In experimental there has been a good bit of work to replace the existing
structure (lock(mutex), directly_modify_structure(with,foo), unlock(mutex)).
It has been replaced with a message passing system.
For the most part it works and mutex usage has been dropped considerably.
(without the UI there are almost no issues with the evil mutex.

Unless I am mistaken, the VST architecture does some of the management of this
for you, so it allows for you to avoid the trap (realtime vs threadsafe) that
the standalone has fallen into.
If you look back on the mailing list you should see a bit of information from a
'Cal'.
He worked on this issue for a while, but IMHO he had a horrible idea of
cooperation, thus yoshimi. (all of these forks/alternates get a bit old after
a while [no offence])


> deal in anyway with parameter automation?
Unless I misunderstand what you are referring to, that is the experimental code,
which allows for midi to be directed at any 'Control'.
(it is rough, but it does 'work')


*Cough* *Cough* #ifdefs and make system (cmake) *Cough*
hm, must have a cold.


> As far as multiple threads go... I would guess to take advantage of multi-core systems.
That would be nice, but as far as I can tell with toolkits like JACK, this
cooperation is not 100% reliable (realtime constraints *argh*), so it is not
possible to 'reliably' do this.

Programmer and electronic musician since the days of punched cards, recent convert to ZynAddSubFx and new to this forum, running it on Windows (XP, quad core machine), and itching to get my hands greasy playing with the guts. Currently using MSVS 2003 to maintain Windows / Solaris cross platform code (with lots of *cough* *cough* #ifdefs ). Would love to work on this in MSVS just because I am familiar with it and it has the integrated debugger, but at my age I've used so many compilers / environments that porting my brain to the native environment (whatever that is) is probably easier than porting the code to my favorite environment.
The Win build that I have (December '06, folder name is 2.4.1.480beta) does have some serious bugs, the worst of which appears to be a math-related instability in the oscillators. I was actually going to start attempting the port myself until I saw this post. So...
a) I would be happy to help OP out on a MSVS port, and
b) where can I find the latest *built* windows stand-alone executable (never used sourceforge before so I am wandering around blind), and
c) does anyone know where I can find copies of those signal flow maps from the documentation in a larger-than-postage-stamp resolution (and any other code documentation, for that matter)

OR

should I just build a linux machine to run this on

You may need MSVS 2008... to compile cleanly.



Really? 480beta was released by me in April 2011. Serious math bugs? In the oscillators?! Would you care to elaborate on that? The main issues are with multithreading and FLTK memory leaks... and some complain about the GUI.




Do you plan to port a standalone executable or a VST dll?

Hello jackoo. I was afraid this forum had been abandoned as many other Zyn repositories and projects have.

I am working on getting MSVS 2010 as we speak. Should have it in a day or two

Interesting... I trekked all over the internet looking for a windows build. I may have found the 12/06 executable packaged with your release somewhere. I have continued my trek since posting this message, and discovered a windows MSVS fork of Zyn, with executables, at http://sourceforge.net/projects/sonicports/, with the latest build in 2008. For some reason (perhaps something I read on one of the forums) I think that is based on version 2.2.1, and it appears to be abandoned. However, I did a quick check that activates the math bug in the 12/06 executable, and the sonicport build didn't blow up, so whatever it was was apparently fixed by then. (The problem I was having was that the oscillators were unstable, and would go into high frequency oscillation at the slightest provocation, with the oscillation even showing up in the waveform display.)
I just downloaded Git and will grab a copy of your code tonight and start poking through it.

I am a big fan of standalone programs, but I may just be showing my age. I am definitely a noob as far as this whole softsynth concept goes (*) - my last keyboard setup was 30 years ago with an ARP-2600, Sequential Circuits Pro-One, and a homebrew polyphonic synth (built into an old Allen C1 organ case).

So - I am certainly willing to be convinced that running the synth as a plugin inside of Audacity is a better option.
However, it seems that both you and jasonwebs have already done the porting (many thanks), so I should be able to get right to my real objective, which is trying out 30 years of bottled up ideas, both musical and algorithmic. Another thing I could tackle is re-integrating the sonicport version with the original.

And if you are interested, I did manage to wrangle some very pretty music out of that 12/06 build, in spite of the bugs - http://soundcloud.com/ish-kabbible/deadly-zyn

(*) Although I did spend 3 months in the studio back in 1979 with what could arguably be considered the first working softsynth: the "Coupland Digital Music Synthesizer" (http://en.wikipedia.org/wiki/Coupland_Digital_Music_Synthes izer) Except the one I used was a prototype, a bunch of wire-wrapped boards in a card cage, not the slick-looking instrument in the brochures.

My old setup:

OK, after beating Git about the head and shoulders with a blunt object, I finally got it to download the code. Based on the lack of .vcproj files, I must conclude that 2.4.3 has not been ported to MSVS.
Assuming that jasonwebs was indeed successful in porting the code, I would think that I could use his MSVS configuration files, diff his code against 2.4.3, and with some degree of effort bring his code up to 2.4.3.
I will post back when I have a better understanding of the magnitude of the task.

In the mean time, I am even more impressed-er now that I have a non-brain-dead version of the program to play with

So jackoo - did you do all of your VDX stuff with Zyn?

@ishkabbible: PM sent.

Will come back later when i have more time!

Yes, that's right. Actually, the present VST port (2.4.1.490) is based on the 2.4.0 linux codebase. After that I manually added linux features such as unison, some improved reverb, padsynth export by manually comparing code. Also added some features of my own for the VST platform such as MIDI learn, Parameter Automation, Separate threading for GUI, audio inputs so you can use only the effects on any sound... etc.

However, what I did is only focus on the VST build, and removing stuff I didn't need / like... like stuff inherited from the linux threading model and mutex...


Adding back new features from 2.4.3 (aftertouch ) would be really nice. I would do it myself, but my life's so darn busy these days...

Also compiling a 64-bit version is in demand here Some of the users who complain about the complicated GUI would like to see a rewrite... maybe replace the buggy FLTK with QT? (that'll be the day!)


Read your PM!



Yes, Zyn is present in almost all of my tracks... especially the FX. But it's not alone... The only tune done entirely with Zyn is a wacky Wild Cat In Space which I did for the OSC contest.

You were doing well until this. I would advise against dissing Cal. There are two sides to every story and plenty of us who remember the other side.