search

prof-spock / FluidSynthPlugin

Simple Wrappers Around the FluidSynth Library as DAW Plugin and Pedantic Command Line Processor
4 stars 0 forks source link

unable to compile on Ubuntu 22.04 or Windows 10 #2

Closed mrbumpy409 closed 4 months ago

mrbumpy409 commented 5 months ago

When compiling from git or latest release on Ubuntu 22.04, I receive the following error:

In file included from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.h:19,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.cpp:16:
/home/chris/Programs/source/FluidSynthPlugin/buildSetup/../src/BaseTypes/Primitives/Natural.h:25:18: error: ‘BaseTypes::GenericTypes’ has not been declared
   25 | using BaseTypes::GenericTypes::GenericNumber;
      |                  ^~~~~~~~~~~~
In file included from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleList.cpp-inc:15,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleList.h:93,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.h:20,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.cpp:16:
/home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleList.cpp-inc: In member function ‘void Audio::AudioSampleList::setToZero(BaseTypes::Primitives::Natural, BaseTypes::Primitives::Natural)’:
/home/chris/Programs/source/FluidSynthPlugin/buildSetup/../src/BaseTypes/Containers/MyArray.h:57:23: warning: ‘void* memset(void*, int, size_t)’ clearing an object of non-trivial type ‘Audio::AudioSample’ {aka ‘struct BaseTypes::Primitives::Real’}; use assignment or value-initialization instead [-Wclass-memaccess]
   57 |         CString_memset(array, 0, (int) (count) * sizeof(ElementType))
      |                       ^
/home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleList.cpp-inc:50:9: note: in expansion of macro ‘clearArray’
   50 |         clearArray(sampleArray, AudioSample, effectiveCount);
      |         ^~~~~~~~~~
In file included from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSample.h:18,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleList.h:20,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.h:20,
                 from /home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.cpp:16:
/home/chris/Programs/source/FluidSynthPlugin/buildSetup/../src/BaseTypes/Primitives/Real.h:36:12: note: ‘Audio::AudioSample’ {aka ‘struct BaseTypes::Primitives::Real’} declared here
   36 |     struct Real : GenericNumber<Real, double> {
      |            ^~~~
gmake[2]: *** [CMakeFiles/FluidSynthFileConverter.dir/build.make:76: CMakeFiles/FluidSynthFileConverter.dir/home/chris/Programs/source/FluidSynthPlugin/src/Audio/AudioSampleFifoQueue.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:173: CMakeFiles/FluidSynthFileConverter.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

I am not sure if this matters, but I am trying to compile a version of the plugin without AVX as I have an Intel Core i7-990X CPU. I have commented out the two lines in CPPCompilerConfiguration.cmake pertaining to AVX compiler flags. I am also using JUCE 7.0.9 (latest). Any help would be greatly appreciated. Thank you. :)

mrbumpy409 commented 5 months ago

I am also getting the same errors trying to compile in Windows using Visual Studio Community 2022. I have updated the issue title to reflect this.

prof-spock commented 5 months ago

Hello mrbumpy409, sorry to answer that late, but I had missed your issue. I shall have a look into your problem, but in principle the AVX should not make a difference (it just gets a little slower...) As soon as I have found the issue, I will help you. Best regards, Prof Spock

mrbumpy409 commented 5 months ago

Thanks for looking into this, Prof, I appreciate it!

prof-spock commented 5 months ago

Hello mrbumpy409,

first of all sorry for your inconvenience! Unfortunately you seem to be the first to build this project yourself, so I'm afraid you are either some sort of a guinea pig or a pioneer (whichever you prefer :wink:)

I have screwed up the upload to GitHub after some file reorganization and by that there are two header files with unwanted and outdated duplicates elsewhere. And additionally JUCE 7 has an undocumented breaking change (when not using ProJucer): there is no file called juce_VST3_wrapper.cpp any longer.

So if you are still willing to try, the fix in your workspace should be as follows:

So this is a quick and dirty local fix. Good Luck! If this does not work out, I shall check in some branch for you to try instead.

Best regards, Prof Spock

P.S.: By the way: we both had a personal contact several years ago about bit-exact reproduction of sound-fonts in DAWs since you are an absolute expert in this area. I feel greatly honored to have you here :blush:

mrbumpy409 commented 5 months ago

Hi Prof, I want to thank you again for your help. I was able to get both the Linux and Windows version of the plugin to compile without errors. However, I am having issues getting the plugin to work correctly.

The Linux VST3 plays everything at too high of a pitch. It sounds as though it's internally operating at 44.1 KHz whereas my audio setup is locked to 48 KHz (using Jack). Specifying "synth.sample-rate = 48000.0" does not change anything. Also, if I mess with the plugin for long enough, it eventually freezes up REAPER and apparently my whole Jack session.

The Windows VST3 loads, but after I provide a SoundFont file reference and program and click "Confirm", it says "fluidsynth library could not be loaded". I have tried using the latest FluidSynth dlls as well as those bundled with FluidSynthPlugin v0.2.1 to no avail. I also tried running the Windows VST3 in Wine, but it will not accept any keyboard input in the GUI, so is unusable there (at least as I have tried it through yabridge in REAPER). I'll admit I'm less familiar with compiling software in Windows, so I may have missed something there.

As I get time, I'll look to see if I can create a debug build as mentioned in the manual to see if it can provide any answers.

P.S.: Small world, man! I don't remember whatever I might have said, but I hope it ended up being good advice, haha. 😁

prof-spock commented 5 months ago

Hello mrbumpy409,

thanks for your patience!

Our conversation took place about 4 years ago, where I was searching for a DAW plugin reproducing soundfonts bit-exactly to FluidSynth in the manner you had described in your essay from 2016. We both were quite sure that there is no such thing, so I had to do it myself...

Regarding your build efforts: I am a bit surprised that there is a problem with the sample rate, since the sample rate is set by the DAW. So it does not help to set the sample rate to some value in the plugin edit window, because this normally does not match the current rate in the DAW and is (hopefully?!) ignored.

Technically there is a call in the JUCE framework to a function called prepareToPlay handled by class FluidSynthPlugin_EventProcessor. This then sets the "synth.sample-rate" to the value given by the DAW and this is subsequently routed to the so called settings object of FluidSynth. According to the spec, the sample rate settings of a FluidSynth synthesizer object may be changed any time, but honestly I have not yet tried it.

Since I am using Reaper myself, I am going to find out and reproduce your setup at the weekend. Maybe I can locate the problem.

Regarding the DLL location in Windows at least in the Windows release ZIP file there are the DLLs included in the VST folder. So you could try and put libfluidsynth-3.dll, libgcc_s_sjlj-1.dll, libglib-2.0-0.dll, libgobject-2.0-0.dll, libgomp-1.dll, libgthread-2.0-0.dll, libinstpatch-2.dll, libintl-8.dll, libsndfile-1.dll, libstdc++-6.dll and libwinpthread-1.dll into the same directory as the VST3 file.

Maybe you have a look at the layout of the VST3 included in the Windows release ZIP file? Since those come from the official fluidsynth distribution, there should be no problem with your processor architecture.

For Linux, I have to check my Linux system at the weekend, but similar reasoning applies: there should be no problem with the sample rate, but I have to check that.

I am sorry to keep you waiting, but until Friday night I cannot answer your request competently 😉

Best regards, Prof. Spock

mrbumpy409 commented 5 months ago

I already did put the above listed DLL files along with the VST3 file just as they are in the 0.2.1 binary release of FluidSynthPlugin downloaded from GitHub. I'll do some more testing and see if I can come up with any clues.

mrbumpy409 commented 5 months ago

I built the Linux version of the plugin using the Debug config, but I cannot figure out where the log file is ending up. It is not showing up in $TMPDIR (/tmp), and if i define the $temp variable as indicated in the documentation, it is not showing up in that location either.

prof-spock commented 5 months ago

According to the documentation logging should be active, when you are building a Debug version. But at the moment the implementation unfortunately does not follow this documentation: I had disabled logging completely for all builds, because I wanted to use the debug build for debugging with a debugger and did not want to cope with log files getting so large.

So in the build setup the setting had been commented out.

Now I have checked in the corrected version. Affected files are buildSetup/CMakeList.txt and src/BaseModules/LoggingSupport.cpp, so please do a PULL on the repository.

When you are using the debug version, the log file should occur in either $tmp, $temp, /tmp (whichever comes first...) and is called FluidSynthPlugin.log. Be aware that a lot of information is logged, so the log file can become quite large and, of course, the performance of the plugin is impaired (since it is mostly engaged in logging).

mrbumpy409 commented 5 months ago

I'm getting an error building from the latest Git:

[ 26%] Building CXX object CMakeFiles/FluidSynthFileConverter.dir/home/chris/Programs/source/FluidSynthPlugin/src/BaseModules/File.cpp.o
/home/chris/Programs/source/FluidSynthPlugin/src/BaseModules/File.cpp: In member function ‘BaseTypes::Primitives::Natural BaseModules::File::read(BaseTypes::Containers::ByteList&, BaseTypes::Primitives::Natural, BaseTypes::Primitives::Natural)’:
/home/chris/Programs/source/FluidSynthPlugin/src/BaseModules/File.cpp:125:18: error: ‘memcpy’ is not a member of ‘std’; did you mean ‘wmemcpy’?
  125 |             std::memcpy(ptr, charArray, (size_t) bytesRead);
      |                  ^~~~~~
      |                  wmemcpy
gmake[2]: *** [CMakeFiles/FluidSynthFileConverter.dir/build.make:132: CMakeFiles/FluidSynthFileConverter.dir/home/chris/Programs/source/FluidSynthPlugin/src/BaseModules/File.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:173: CMakeFiles/FluidSynthFileConverter.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

I don't really know C++, but it looks like perhaps you may need #include <cstring> for the std::memcpy function?

I should also mention: I have been using cmake -S <pathTo>/CMakeList.txt -D CMAKE_BUILD_TYPE=Debug instead of cmake -S <pathTo>/CMakeList.txt -B . --config Debug from the manual, as the latter formatting appears to be deprecated in newer cmake. Does this mean I should also update the build command to cmake --build . CMAKE_BUILD_TYPE=Debug instead of cmake --build . --config Debug?

prof-spock commented 4 months ago

Hello mrbumpy409,

sorry to keep you waiting.

I did a build on Ubuntu 22.04 with clang and as far as I can tell it worked without problems. I did some code corrections before to get rid of some C++20 warnings (also incorporating your observation about the missing <cstring>, although previous compilations for Linux had worked without any problems).

So when you compile, please do a git pull first to get all the updates.

Also use cmake -S <pathTo>/CMakeList.txt -D CMAKE_BUILD_TYPE=Debug cmake --build . and finally cmake --install . My gut feeling is that you do not have to specify the configuration for the Linux build and install since CMAKE in Linux relies on the make generator and the latter is not a so-called "multi-configuration tool". Hence you cannot specify the configuration when doing the actual build and install, because that had been fixed before during the cmake setup phase (the first step above).

Once you have succeeded in building the plugin, there is a test setup for Reaper in _DISTRIBUTION/test:

Due to lack of time I did the check only in Windows, but here the setup also works for a 48kHz sample rate...

Sorry to flood you with information; I hope it helps you in getting things operational. But if you do not succeed in building the plugin yourself, I shall provide a new release for Windows, Linux and MacOs without AVX. The difference in performance between AVX and SSE instructions should not be so critical and then you do not have to build it yourself...

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

Everything builds successfully now (Linux... haven't tested Windows yet), and I was able to generate the WAV files per your instructions. However, opening the "testFluidSynth-48000.rpp" project file immediately crashes REAPER Linux x64 and causes QJackCtl to become unresponsive. JACK appears to be in a zombie state until I kill all JACK processes and re-launch JACK again using QJackCtl.

I am able to add FluidSynthPlugin into an empty project, but as before, the pitch is too high in each SoundFont I have tested. Other virtual instrument plugins sound at the correct pitch.

I have attached FluidSynthPlugin.zip containing the following log files:

  1. FluidSynthPlugin-trying to load test project.log: This is the log file that was generated when unsuccessfully trying to load testFluidSynth-48000.rpp.
  2. FluidSynthPlugin.log: This log file was generated via the following steps:
    1. Launch REAPER.
    2. Add FluidSynthPlugin instance to a MIDI track.
    3. Load a SoundFont preset via the following text: 
      soundfont = /home/chris/Personal/Audio/Samples/SoundFonts/GeneralUser/GeneralUser GS v1.52.1.sf2
program = 0:0
    4. Play a few notes via my MIDI keyboard.
    5. Quit REAPER.

I hope the log files provide some clue as to what might be happening. I'll run a few more experiments on my end and see if I can get any clues.

mrbumpy409 commented 4 months ago

I was able to test using a different audio device, one that I can set to either 48 KHz or 44.1 KHz in JACK. Here are the results:

44.1 KHz sample rate, 256 buffer size, 2 periods: FluidSynthPlugin plays at the correct pitch. The "testFluidSynth-44100.rpp" project still crashes REAPER, but doesn't cause JACK to hang up at all. 48 KHz sample rate, 256 buffer size, 2 periods: FluidSynthPlugin plays at too high a pitch.

So, it's definitely a sample rate thing. However, the log file clearly shows that the plugin is getting the correct sample rate from the host. I am using the latest libfluidsynth (2.3.4), but I will try the older, Ubuntu repository version (2.2.5) to see if that makes any difference.

EDIT: Downgrading libfluidsynth did not change anything. I will keep it at v2.3.4 for now.

prof-spock commented 4 months ago

Hello mrbumpy409,

okay, I can reproduce the effect of the pitch shift. But first of all, the pitch shift also occurs in the command line version - the pedantic fluid synth converter - but not in FluidSynth itself. So the test is futile, because it checks the VST plugin against a pitch shifted WAV file and both are identical (but both wrong in an identical fashion 😉).

Sorry for my previous misleading analysis, you have been correct (of course).

As you had already found out by log file analysis, this means that the sample rate change seems to be ignored by the FluidSynth library API. I assume that once the FluidSynth synthesizer object is set up, some parameters may not change (although the API documentation claims that this only holds for the synth.verbose parameter...).

I can also "somewhat" reproduce the crashes of the test projects in Reaper: when I try to load the project in Linux with the other sample rate, Reaper hangs. After a restart, the project can be loaded without problems, so there is some initialization or - more likely - finalization of the plugins going astray. But it is puzzling that the same projects in Windows load without any problems.

I'll have a closer look into the sample rate topic and maybe check with the FluidSynth maintainers.

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

Thanks, Prof!

Also, I think I have figured out why Windows builds are failing for me (Visual Studio 2022). The cmake configure process creates the folder "FluidSynthPlugin.vst3". Later, when the build process tries to create a file by the same name, it fails because there is already the identically-named folder there. If I delete the "FluidSynthPlugin.vst3" folder before building, then the build fails at "Linking CXX shared library FluidSynthPlugin.vst3" when trying to copy the "FluidSynthPlugin.vst3" file into the folder of the same name, which doesn't (and can't) exist in the same folder.

Also, regarding the sample rate issue, perhaps a peek at Fluida.lv2 might provide some clues, as that plugin also uses FluidSynth, but doesn't have the sample rate issue (it does have a host of other issues, though, mostly related to its buggy GUI).

prof-spock commented 4 months ago

Hello mrbumpy409,

okay, here we go.

I have changed the API call to recreate the synthesizer whenever the sample rate is changed. And there is some mysterious description in the FluidSynth API for a deprecated function called fluid_synth_set_sample_rate:

This function is broken-by-design! Don't use it! Instead, specify the sample-rate when creating the synth.

So this supports my hypothesis: sample rate changes for an existing FluidSynth synthesizer object are not advisable...

Now I have checked in a version where this should be fixed: the synthesizer is recreated when the sample rate is specified by the DAW or the command line. At least I checked it with Linux and Windows with the Reaper test project and the pitch seemed to be identical to genuine FluidSynth 😉

Referring to your Windows problem: the build process must generate a folder called FluidSynthPlugin.vst3 and embedded in some subfolder structure within there is a file called FluidSynthPlugin.vst3. This is the currently specified format for VST3 plugins. For your convenience I have enclosed my current Linux version and my current Windows version here (without AVX instructions); you can check what should be produced. FluidSynthPlugin-Linux-x86_64.zip FluidSynthPlugin-Windows-AMD64.zip

If this is not what comes out, there is some problem in the build setup I would like to know.

And unfortunately the crash topic seems to be some incompatibility in Reaper; I found the following post in the Reaper forum. The symptom is not identical, but similar: finally some assertion in line 152 of IpatchSF2Gen.c fails within Reaper. The proposed workaround ("oversampling") is not helpful, because I want to use exactly the project sample rate for well-known reasons.

Looks like someone is going to write another bug report to Justin...

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

Thanks! I look forward to checking out those builds. In the meantime, I have created a video showing the compilation process as it happens on my system. Hopefully it will tip you off as to what is going on.

Peace 🙂

mrbumpy409 commented 4 months ago

Here are my notes so far testing the latest builds you created.

Linux

The Linux plugin now works perfectly, as far as I have tested in REAPER. I spent a good deal of time trying out various SoundFonts and settings and didn't have any issues at all. It would seem the previous JACK instability had been caused by the sample rate differential, which is now fixed.

Windows

Attempting to use the plugin in REAPER still fails. When I add the plugin initially, the track becomes muted, and after I have entered settings and clicked "Confirm", I get "fluidsynth library could not be loaded". So, I tried the plugin in Mixcraft 10, and it works perfectly.

Investigating further in REAPER, I see all of the FluidSynth DLLs on the "Plugins that failed to scan" list, and manually attempting to re-scan them doesn't remove them from the list. I will have to do more research on what can be done about this. Perhaps moving the FluidSynth libraries into a system path?

EDIT: I have just confirmed this REAPER behavior on a second system, this one with a very clean REAPER install, and running on a CPU with AVX instructions. The same issue also happens with plugin v0.2.1 from the GitHub release. This is on REAPER v7.11, installed via Chocolatey. The plugin (FluidSynthPlugin.vst3 folder) in all cases is installed to C:\Program Files\Common Files\VST3.

The other issue I ran into was when attempting to use the DLLs from the latest FluidSynth (2.3.4 64-bit binary release from Git) with FluidSynthPlugin (in Mixcraft), which results in an "unable to load SoundFont " error. Perhaps I may need to try compiling my own FluidSynth version and see if that works.

Thanks again for all of your help with this! I'm curious, do you play keyboard at all? I have been working on a few SoundFonts you might find interesting.

mrbumpy409 commented 4 months ago

One last post for now. You had wanted to know if my build process was resulting in a different file/folder output from what you were getting. Here is the difference between my compiled Linux version (left) and yours (right):

image

prof-spock commented 4 months ago

Hello mrbumpy409,

first of all thank you for your effort in producing the video and all your patience during the last weeks!

Great that Linux works now! And for the Windows build I see that the final installation step fails.

The reason for that is that the Windows VST has to contain the library DLLs and those are not provided in the project. As far as I remember I deleted them in GitHub, because they are "external libraries"; this was, of course, not helpful when they are needed for the build 😞

To ensure that a build from scratch in Windows works I have enclosed a walk-through installation description for Visual Studio and by using CMAKE on the command line. BuildForWindows.docx

Please check if this works now. By the way: it is necessary to specify the configuration for a Windows build, because the Visual Studio CMAKE generator is multi-platform.

I have no real answer for the scan problem in Reaper: the DLLs are in the path of the VST3 plugin and hence Reaper assumes that those are VST3 components. But, of course, they do not react to VST3 API calls and then Reaper flags them as "bad". I have to check how other plugins deal with that problem. I have the same effect, but choose to ignore it.

[Difference between installed layout in ZIP archive and locally for mrbumpy409]

This is no problem; the ZIP file has a more elaborate layout, because it might also contain the plugins for other target platforms...

I'm curious, do you play keyboard at all? I have been working on a few SoundFonts you might find interesting.

I am not a keyboard player, but a guitarist and I used to do arrangements for a company band. Soundfonts are an integral component of my toolchain so I am always interested in good ones :wink:

But my focus is on realistic sounds for band instruments in pop and rock arrangements (e-piano, organ, piano, synthesizer, guitar, e-bass, drums). I tried out several GM soundfonts, but so far I am quite satisfied with FluidR3_GM.sf2 and a little bit of tweaking via polyphone.

You are so well-known for systematically improving sound fonts (both via your analysis from 2016 or by your work for MuseScore) that I am absolutely positive that any of your soundfont creations is excellent 👍

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

To ensure that a build from scratch in Windows works I have enclosed a walk-through installation description for Visual Studio and by using CMAKE on the command line.

The Windows build completes successfully now! Unfortunately, it suffers the same issue as the others. So far, no build of FluidSynthPlugin will work in REAPER in Windows on any machine I've tried (3 different systems). It's always the same "fluidsynth library could not be loaded" error.

I have no real answer for the scan problem in Reaper: the DLLs are in the path of the VST3 plugin and hence Reaper assumes that those are VST3 components. But, of course, they do not react to VST3 API calls and then Reaper flags them as "bad". I have to check how other plugins deal with that problem. I have the same effect, but choose to ignore it.

If I read your comment correctly, you have the FluidSynth DLLs on REAPER's "failed to scan" list, but yet the plugin works for you? What version of REAPER are you on?

But my focus is on realistic sounds for band instruments in pop and rock arrangements (e-piano, organ, piano, synthesizer, guitar, e-bass, drums). I tried out several GM soundfonts, but so far I am quite satisfied with FluidR3_GM.sf2 and a little bit of tweaking via polyphone.

I am currently working on a new GM SoundFont based on FluidR3. There's still a ways to go before it's ready for a first release, but I have developed some really cool techniques for achieving more realistic dynamic control. This is especially noticeable when playing the instruments via MIDI keyboard, as there are no perceivable sample splits across the velocity range. FluidSynth is the only SoundFont softsynth that can properly handle the programming for this.

Here are demos of my Rhodes and Yamaha DX7 electric piano presets that use these techniques, at 11.5 MB and 15.8 MB sample size respectively.

Peace. 🙂

mrbumpy409 commented 4 months ago

I discovered that if I drop the FluidSynth DLL files into C:\Windows\System32, FluidSynthPlugin now works in REAPER. So for whatever reason, the plugin under REAPER can't seem to find the DLL files from within the .vst3 folder. Next I removed the FluidSynth DLLs from C:\Windows\System32 and instead added C:\Program Files\Common Files\VST3\FluidSynthPlugin.vst3\Contents\x86_64-win to the system %PATH% variable. This also worked. So at least for now, I have a workaround.

prof-spock commented 4 months ago

Hello mrbumpy409,

I have adapted the code for both the sample rate problem and also the search paths for the dynamic libraries.

In my opinion everything should work as expected now and hence I have published the changes as a new release. If you want to, you can have a look whether everything is okay. Please ensure that you do a fresh git clone, because I have rebased the git history.

The bug with the sample rate change crashing libfluidsynth is still there; I have to investigate this with the Reaper and the FluidSynth maintainers.

Thanks for your support and perseverance! Now I will have a look at your soundfont demos...

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

I have adapted the code for both the sample rate problem and also the search paths for the dynamic libraries.

I just confirmed that the Windows version of FluidSynthPlugin can find the libraries in REAPER now. Excellent!

One feature I am really excited about is the ability to use environment variables in the SoundFont path. This allows me to save a project in one OS and resume it in another, as the environment variables can be set in each OS to point to the same samples folder on a shared drive.

Thanks again for all your help!

mrbumpy409 commented 4 months ago

Hi Prof, I have a couple questions.

  1. Is the FluidSynth library version included with FluidSynthPlugin documented somewhere? I've been compiling with the latest version downloaded from fluidsynth.org since I wasn't sure.
  2. FluidSynth allows setting the sample interpolation method per midi channel via fluid_synth_set_interp_method() (API link). Normally this can be accessed via the FluidSynth console commands, but there doesn't appear to be a setting for it (e.g., "settings.interp"). So, I'm not sure if it would be possible to add support for this feature to the plugin, but if so, it would be nice to be able to select the highest sample interpolation (7th order) rather than the default (4th order) to avoid aliasing artifacts in some cases. Is this something that would be feasible?

Thanks. :)

prof-spock commented 4 months ago

Hello mrbumpy409,

  1. The fluidsynth library version included in the distribution is not documented (but you can find it by looking at the libraries folder). So currently we have version 3 of the fluidsynth library on all platforms... In principle, any version should work, since the library is dynamically loaded and bound. As long as the elementary functions of the fluidsynth library are syntactically and semantically unchanged, the version should not matter.
  2. Unfortunately - as you have described - there is no synthesizer setting for the sample interpolation method that can be directly passed through: so it does not work out of the box. Well, what I could do is introduce another artificial setting (like soundfont or program) that maps onto that function like e.g. synthesizer.interpolation-method with integer values 0, 1, 4 and 7. What do you think?

I am curious: is there any program where you can select this feature of fluidsynth (when the command line version obviously does not support it)?

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago 
1. The fluidsynth library version included in the distribution is not documented (but you can find it by looking at the [libraries folder](https://github.com/prof-spock/FluidSynthPlugin/tree/master/libraries)). So currently we have version 3 of the fluidsynth library on all platforms...

I was just curious, since I know sometimes there are compatibility fixes. The full FluidSynth release always has a version number like "2.3.4", so I'm not sure how that relates to the library v3.

   In principle, any version should work, since the library is dynamically loaded and bound. As long as the elementary functions of the fluidsynth library are syntactically and semantically unchanged, the version should not matter.

That's good to know.

2. Unfortunately - as you have described - there is no synthesizer setting for the sample interpolation method that can be directly passed through: so it does not work out of the box.
   Well, what I could do is introduce another artificial setting (like `soundfont` or `program`) that maps onto that function like e.g. `synthesizer.interpolation-method` with integer values 0, 1, 4 and 7. What do you think?

That would be amazing, and it would surely also make @DaforLynx happy, as he has an open feature request for this same function to be added to juicysfplugin.

I am curious: is there any program where you can select this feature of fluidsynth (when the command line version obviously does not support it)?

Actually, the command line version does support it in the FluidSynth shell via the "interp num" command (user manual reference). Looking around, I did find ways to change the FluidSynth interpolation method in jOrgan and csound, but I don't recall seeing it elsewhere. Comparing FluidSynth's default interpolation to BASSMIDI and Sobanth SoundFont synths, it is clear that the latter two use a higher interpolation quality than 4th-order, which is to be expected from pro audio samplers.

Anyway, thanks for considering this. As-is, this plugin is already proving invaluable to me. Thank you :)

DaforLynx commented 4 months ago

@mrbumpy409 Somehow I didn't register that the S. Christian Collins was in this thread. Thanks for all your work! Yeah, that's actually the main thing I'm using this plugin for, the interp 0 setting. It's great for some of my particular uses and having program changes work would make it great for the rest of them ;). Another plugin that I am aware of which has interp settings is Phenome, but it has its own issues.

mrbumpy409 commented 4 months ago

@mrbumpy409 Somehow I didn't register that the S. Christian Collins was in this thread.

I never seem to be very far from any SoundFont related bug report, LOL.

Thanks for all your work! Yeah, that's actually the main thing I'm using this plugin for, the interp 0 setting.

Wait, did you finally get juicysfplugin to compile? I eventually gave up.

It's great for some of my particular uses _and having program changes work would make it great for the rest of them ;)

Well, program changes work great in FluidSynthPlugin. Bank changes do as well, assuming you don't specify the initial program in the interface "program = 0:5" or whatever, because that appears to lock it to the specified bank.

Another plugin that I am aware of which has interp settings is Phenome, but it has its own issues.

Sobanth does as well, but neither of those are based on FluidSynth.

@prof-spock Sorry for my thorough hijacking of this bug thread...

DaforLynx commented 4 months ago

Wait, did you finally get juicysfplugin to compile? I eventually gave up.

No, never ended up happening, which is why I'm here.

Well, program changes work great in FluidSynthPlugin. Bank changes do as well, assuming you don't specify the initial program in the interface "program = 0:5" or whatever, because that appears to lock it to the specified bank.

Yeah, but MIDI-streamed Program Changes do not, sadly, and it seems to be a limitation of VST3 as described in the other open issue here.

DaforLynx commented 4 months ago

Also oh my god @mrbumpy409 I think you just found the VST I've always wanted for me

Sobanth has that interpolation setting, and can play multiple channels at once

Thank you!

prof-spock commented 4 months ago

Dear all,

@mrbumpy409 - as the grandmaster of soundfonts - may hijack any thread on soundfont related things any time :wink:

And the fluidsynth plugin is absolutely fine in following program changes in the MIDI stream on a per channel basis. There had been a VST2 version that did exactly that and also the AU-versions for MacOS are perfectly capable of handling those.

Unfortunately - as far as I understand - VST3 does not provide those program changes within the MIDI stream any longer, but by separate program change information disguised as API calls to the plugin. There is a kludge workaround to select the program in a DAW by changing the plugin preset (which is completely idiotic in my opinion, presets have a different purpose!) and this is served to the plugin.

But this seems to be the only way where the JUCE framework reacts to program changes for VST3 (see also this discussion) and, of course, the FluidSynth plugin supports it. But those changes are not in sync with the remaining MIDI stream and by that program changes may come too late relative to the MIDI notes. JUCE might decide to map those API calls to MIDI events served to the plugin, but currently they do not and by that follow the VST3 recommendation.

Also unfortunately the VST2 format is discontinued by Steinberg since May 2018 (because they claim to have the follow-up format VST3 since 2006). So you have problems in finding the VST2 Software Development Kit and hence also building plugins for that framework. This is no ill will by me but I have to rely on the boundary conditions of the JUCE framework and here VST2 is history...

And as already discussed in the other thread: I do not know how you use your DAW, but normally a single track contains a single instrument, because all the track postprocessing is normally tuned to that instrument. So the restriction of the FluidSynth plugin is not relevant in that case. But if a track on the other hand contains several instruments and changes (e.g. the Doom MIDI file), the fluidsynth plugin VST3 cannot be used for the above reasons. So it depends on your use case...

Regarding the interpolation: this is doable, I shall see how quickly this can be implemented...

Best regards, Prof. Spock

prof-spock commented 4 months ago

Dear all,

I have moved the enhancement request for the sample interpolation method to the new issue #4 and the VST3 program change discussion is already handled in issue #1.

Because the compilation issue seems to be solved, I would close the current issue in the next days unless there are objections by the original requester @mrbumpy409.

Are you okay with that?

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

No objections here. :)

prof-spock commented 4 months ago

Thanks, I close the issue.