>Excellent! Great to hear. Could you post what you did to the mailing list, so other Windows users can benefit from that as well?
Sure with pleasure..
I tested on Windows 10 x64 in which Visual Studio 2010 is installed. I have an older version of windows sdk (7.0), that building for "64 is not available, so I get the requirements for Win32 instead from:
http://ftp.gnome.org/pub/gnome/binaries/win32
pkg-config_0.26
glib_2.26
glib-dev_2.26
proxy-libintl-dev_20100902
gettext-runtime 0.18.1.1
Unzipped all in a folder and added the path to system-> Advanced->Environment Variables
I also copied both dsound.h and ladspa.h files to VS include folder "Microsoft SDKs> Windows> v7.0A> Include"
In Cmake 3.9.3 :
Browse fluidsynth-ladspa source.
Browse a folder for build binaries.
Configure, pick target generator for project (VS 2010 in my case), and then Generate.
Cmake outputs:
Windows: yes
LADSPA support: yes
Audio to file driver: yes
All other options: no
(I get also some warnings regarding msvcp100.dll and msvcr100.dll does not exist.)
Configuration done.
Generating done.
Open the generated .sln file with visual studio, select Release from solution configuration, and then hit f7 to build.
Testing:
I copied a test .sf2 file to the release output folder (then no need to enter a path) and two LADSPA plugins for testing (delay_1898.dll and gverb_1216.dll used in Audacity. Complete plugins can be get from:
https://www.fosshub.com/Audacity.html/LADSPA_plugins-win-0.4.15.exe)
I'm using loopMIDI as virtual Midi port for fluidsynth Midi-in (or loopBe1 from http://nerds.de/en/loopbe1.html)
I played a midi file using a software sequencer and set its Midi out to the virtual midi port so that it will be available as fluidsynth's Midi-in.
Windowskey + Run-> cmd ->Enter
cd ..fluidsynth-ladspa/build/src/release
(where fluidsynth.exe, libfluidsynth.dll, .sf2, and ladspa test plugin .dll exist)
Following the documentation: (https://github.com/FluidSynth/fluidsynth/blob/ladspa/doc/ladspa.md)
\..\..>fluidsynth -o synth.ladspa.active=1
>
>load test.sf2
>ladspa_effect e1 gverb_1216.dll
>ladspa_link e1 Input Main:L
>ladspa_link e1 left Main:L
>ladspa_link e1 right Main:R
>ladspa_start
Regards, Ahmed
On 13 Nov 2017 5:05 pm, Kjetil Matheussen <address@hidden> wrote:
On Mon, Nov 13, 2017 at 3:39 PM, Tom M.
<address@hidden> wrote:
> 3. It wouldn't make sense to change ladspa.h if it was included in fluidsynth. So it wouldn't be a fork.
People tend to have fancy ideas ;)
> 4. If ladspa.h "upstream" would change in a way that would force plugins to be recompiled (and this won't happen), the only required change in fluidsynth would be to update the ladspa.h file.
If there is **any** change to upstream ladspa.h we should update our
own copy.
That's not going to happen. First of all, there is no upstream ladspa.h.
Secondly, ladspa.h hasn't changed since 2002, and even then
it was common to include ladspa.h. Even alsa-lib included ladspa.h.
Furthermore I am afraid that bundling ladspa.h could be the begin of
bundling even more dependencies.
It's hardly a dependency. It's a header file with almost no content, except
for a lot of comments.