#1 - fluidsynth process sometimes starts automatically at boot. This really shouldn't happen. Fluidsynth is a synth and is the backend for QSynth and fluidsynth.dssi. This distro contains a lot of synths and there's no reason why this particular one should auto-start. Also, when fluidsynth starts in this way, I can't end the process in System Monitor - I have to do the ol' "killall -9 fluidsynth".
There doesn't seem to be much consistency in what's happening. However, the two above phenomena seem connected. For example, just now, on booting, fluidsynth was auto-starting. It did this twice in a row. Then, on the third boot, I had the login-freeze issue. I restarted sddm.service, logged in, and fluidsynth did not autostart. Then I rebooted again, the login worked fine and fluidsynth didn't start. Everything seemed in order.
Another possible connection is that this might be more likely to happen after I've booted into Kubuntu on the same laptop, shut it down, and then booted into Ubuntu Studio. Before this latest round of auto-starts, I had just booted into Kubuntu. In Kubuntu, fluidsynth never auto-starts. The issue(s) also seem more likely to happen after certain system updates (as opposed to software updates).
There is a fluidsynth.service in systemd. However, when I list in the terminal all systemd services, running or otherwise, including ones that are supposed to start at boot, fluidsynth doesn't show up in the lists. It also doesn't show up in the Ubuntu Studio settings for startup programs.
To try to get to the bottom of this (not really knowing what I'm doing, just following tips on the 'net), I found that the UID for fluidsynth process was 1278, so, in the terminal, tried the following (posted as a pic because I don't know how to paste the nesting)...
(The chart continued but I only copied to here to save space. Fludisynth doesn't connect to any of the remaining entries. Note that in the above, it is the default-GM soundfont that fluidsynth is loading. Fluidsynth needs a soundfont to be loaded before it can make any sounds. In that sf3 folder, there are several soundfont files, but for some reason this one is loading.
In the file, /usr/lib/systemd/user/fluidsynth.service, under [Install], the WantedBy= variable was set to default.target, which triggers a start at boot. Kubuntu 20.04, on the other hand, had this set to multi-user.target and the process didn't auto-start.
This creates a new folder in /home/user/.config/systemd/user called fluidsynth.service.d, and a new override file in this folder, and opens the latter for editing in the terminal. Under the line, "Anything between here and the comment below will become the new contents," I added...
I have a bizarre issue I can't figure out. I installed fluidsynth and the soundfont recommended from the wiki page. It's great, I can play midi files fine when I use aplaymidi -p128:0 FILE. I can also start the fluidsynth daemon by running the command:
But here is the strange thing, the /etc/rc.d/fluidsynth init script fails to start with that exact command in it. (I changed the original script so that fluidsynth uses pulseaudio instead of alsa). When I type:
It will work as a normal user, but it will NOT work as sudo or when I am su'd into the root account. I can't for the life of me figure it out. I have ensured that before starting fluidsynth each time, that it has already been terminated cleanly, so it's not that. I've even tried changing the shell the script runs as, no luck.
I have the exact same problem...it is very very frustrating. fluidsynth works perfectly as long as I don't try to start it at boot time. I have no idea why this is the case. It can't seriously be that PulseAudio somehow requires a tty, because that would be well, simply absurd and ridonkulous.
Does it work if you invoke sudo from within the rc script? I get the same problem trying to start your script as root. But I can start it if I login as root and run "sudo -u connor ./fluidsynth" or "su connor -c ./fluidsynth".
For me it seems to work when run manually, using sudo or running as root from a shell. Thus the statement about how ridiculous it is that a shell is required although I neither know or believe if that is actually the restriction/problem. It may just be a symptom of a different problem. I can't recall the results when a legacy fluidsynth init script is used in /etc/init.d but Anytime I try to start it using the following systemd file or any variation of it, I get the status listed below:
If using the pulse output, it will attempt to connect at startup and maintain a constant active source. This is the biggie - if started with any form of pulse output, pulse must be ready when fluidsynth starts. This is in contrast to programs like mpd, which only open a source during actual playback. If not for this caveat, we wouldn't be having this discussion --;
Mine is with jack and fluidsynth. What should I do in this case? I have Audacity installed and I would like to keep it. Should I uninstall fluidsynth and reinstall it later, or should I uninstall Audacity and then reinstall it later?. I really would like to keep it if possible. I have noticed that fluidsynth has a lot dependencies.
I've been using ykhwong's build of dosbox which I'm assuming includes this patch. Is there anyway to set the gain of fluidsynth in the config options? Looking at the code on the lauchpad I can't see it. If it isn't, adding in an option to set the gain in the conf file with the rest of the midi options would be great. Especially as all soundfonts aren't recorded at the same level. If I'm being an idiot and a gain option is already included, please inform me as to how. I saw in one of the old fluidsynth topics where a setting might have been implemented as synth.gian=* but I tried that to no success. Short of re-doing the soundfont I would like to use and upping the base magnitude all around I don't see any other way to go about it, other than a volume control attached to the entire midi section.
As Rob already stated, Windows builds of DOSBox-X have built-in support of FluidSynth MIDI driver. Set mididevice=fluidsynth and a sound font (via fluid.soundfont option) to enable the built-in FluidSynth feature. A DOSBox-X Windows build that enables the FluidSynth MIDI driver by default is also available from here.
On Windows, the simplest method is to grab the 32-bit or the 64-bit version and place the extracted fluidsynth.dll in your ZDoom directory. The fluid_patchset console variable must be set to point to a valid SF2 sound font for it to render any output; however ZDoom may be able to automatically detect one if it exists, depending on your hardware and operating system: on Unix systems, it will look for /usr/share/sounds/sf2/FluidR3_GS.sf2 and on Windows it will look for CT4MGM.SF2 and CT2MGM.SF2 in the system directory (Creative drivers usually install one of them so if you have a Creative sound card it may work out of the box).
Qsynth is a fluidsynth GUI front-end application written in C++ around theQt framework using Qt Designer.Eventually it may evolve into a softsynth management application allowing the user tocontrol and manage a variety of command line softsynth but for the moment it wrapsthe excellent FluidSynth. FluidSynthis a command line software synthesiser based on the Soundfont specification.
"@context":"http:\/\/schema.org\/","@id":"https:\/\/lucidbeaming.com\/blog\/running-fluidsynth-on-a-raspberry-pi-zero-w\/#arve-youtube-pkbfhrptfwk65884bc0e20ac132876989","type":"VideoObject","embedURL":"https:\/\/www.youtube-nocookie.com\/embed\/pkbfHrPtFWk?feature=oembed&iv_load_policy=3&modestbranding=1&rel=0&autohide=1&playsinline=0&autoplay=0"This video is a demo of the same sound set used in this project, but on an earlier iteration using a regular Raspberry Pi 3 and a Pimoroni Displayotron HAT. I ended up switching to the smaller Raspberry Pi Zero W and using a webapp instead of a display.
"@context":"http:\/\/schema.org\/","@id":"https:\/\/lucidbeaming.com\/blog\/running-fluidsynth-on-a-raspberry-pi-zero-w\/#arve-youtube-z4pjqsnjrc865884bc0e25f0656434612","type":"VideoObject","embedURL":"https:\/\/www.youtube-nocookie.com\/embed\/z4pJQSNJRC8?feature=oembed&iv_load_policy=3&modestbranding=1&rel=0&autohide=1&playsinline=0&autoplay=0"Posted in BuildingTagged DIY, Raspberry Pi, Raspberry Pi Zero W, Synthesizer, TutorialMore blog posts:
If your fluidsynth application is set to use alsa as driver, the sound card will be accessed directly and pulseaudio and applications using pulseaudio will not be able to work properly. You can modify the configuration file /etc/conf.d/fluidsynth and change the driver to PulseAudio, then restart fluidsynth and PulseAudio:
Gm Program Changer, with the basic 128 instruments in the 16 categories and a channel changer using the popup external. Also a rudimentary way of accessing the generators within a soundfont (*.sf2) via NRPN. Rudimentary means BE CAREFUL in this case as all notes-off/controllers-off does not necessarily work in this case and the quickest way out is to close fluidsynth/Qsynth or other soundfont player when things go wobbly
Download the very excellent soundfont SGM-V2.01.sf2 (around 250MB uncompressed) from Copy to /usr/share/sounds/sf2/SGM-V2.01.sf2. Then In a terminal type:- fluidsynth /usr/share/sounds/sf2/SGM-V2.01.sf2 to fire up fluidsynth. open QjackCtl make the connections in audio [fluidsynth #### to system], then in alsa connect your [midi-in to pure data] and [pure data to fluidsynth] Alternatively setup Qsynth with the SGM-V2.01.sf2 and connect jack similarly
The gain and polyphony settings work just fine, but I'm not sure why the chorus and reverb settings don't. I don't believe this is just an issue with me, as I've used various installs of audacious on multiple computers running some variant of Ubuntu 20.04. This was not an issue with prior versions of Ubuntu such as 18.04, but I forget what version of Audacious was in the Ubuntu repository for that release. If this issue could be investigated, or if I'm doing something wrong, any assistance would be appreciated. I don't have enough experience with the fluidsynth API to be able to fix this myself.=
760c119bf3