The project is about porting selected (open source) music-, and audio software to latest compilers and platforms...
Be the first to post a text review of Sonic Ports. Rate and review a project by clicking thumbs up or thumbs down in the right column.
With the latest source releases FLUID designer files were broken (because of VST plugin implementation). They are now updated and working again. It is possible to redesign the user interface with FLUID graphically and recompile the project. IMPORTANT: The project has now dependency of FLTK1 package (which is the latest FLTK 1.1.8 release). FLUID integration is still somehow problematic, because those files include alot of extra code on widget base (initialisation and callbacks), which complicates workflow if you work with an IDE. Also it is very cumbersome to find the code inside the UI designer if you want to apply changes or to fix bugs and so on. We are currently working on a better solution to improve the workflow while not completely loosing FLUID integration. This applies as long the main interface of ZynAddSubFx bases on FLTK. It may change if the Interface is completely ported to another GUI framework (i.e. VSTGUI framework). A global GUI change meight be neccessary in the future because of better audio plugin integration. Some VST Hosts (including Cubase) do not directly support full featured GUI applications like Zyn as a plugin for some reasons. Also Zyn has currently no realtime automation enabled internal parameter stucture (in VST all parameters are floating point values and limited to a range between 0.0 and 1.0). Zyn has currently merely limited MIDI automation support (128 byte range for MIDI controllers plus NRPN). This has to be changed for full audio plugin automation support, which means full parameter automation with floating point precision.
SVN repository has totally changed in structure. This step was neccessary because we needed to integrate Apple XTools realtime support. XTools has obviously some problems with SVN, if the sources aren't directly subfoldered. So the project files vor MS Visual Studio and Apple XCode have now different roots (directly on top of the project). The entire SVN folder stucture has changed to optimize the SVN workflow and to prevent useless blowing due to duplication of sources. Take a look at the new structure and check out the latest development tree. The new structure is very clean and provides excellent support for any future project integration. Yeah, SVN is a fine thing, but it needs some attention to its structure...
We removed the 'DevelopmentPacks' from Downloads. Please use SVN for latest sources. The 'DevelopmentPacks' were outdated. There are too many changes lately.
We changed the SVN folder structure because some projects share the same codebase. Therefore now 'DependencyPacks' exist. Each projectfolder has a 'Dependency' directory where all external libraries should be placed. This way the project files link to the right places and the projects can be recompiled without any changes or additional configuration. But those 'Dependency' folders are empty by default. This is where the DependencyPacks come into the game. Please download those DependencyPacks as extra zipped packages and place the contents into the project folders 'Dependencies' sub directory. There is currently a 'DependencyPack1' folder inside the trunk in SVN repository. DependencyPacks will be reeased as zipped files in the future (as far there no modifications to these libraries are made). We want to prevent unneccessary code blowing this way.
The downloads are available again. SVN repository is currently disabled. But we will reactivate / update it in the next days.
Some changes required to disable the download for a few hours. We will notify if the downloads are available again.
Be the first person to add a text review.
Copyright © 2009 Geeknet, Inc. All rights reserved. Terms of Use
Thanks for your rating!
Would you also like to write a review?