Re: [fluid-dev] Revised patch for new channel field is_drum_channel
On 2011-01-29 21:01, jimmy wrote:
--- On Fri, 1/28/11, David Henningssondi...@ubuntu.com wrote:
On 2011-01-28 23:07, jimmy wrote:
Here's the revised patch file for the new channel
field is_drum_channel.
Thanks, but you're missing the patch :-)
// David
Oops, here it is.
Thanks. I've fixed a few bugs in your patch - see the attached diff.
But there was one thing keeping me from committing the fixed version:
+
+ /* if style == XG and bankmsb == 127, convert the channel to drum mode.
+ * How should newval above be calculated (same as MMA style) ??? */
+ if (style == FLUID_BANK_STYLE_XG (127 == bankmsb))
+ {
+ chan-is_drum_channel = CHANNEL_TYPE_DRUM;
+ }
+
...this doesn't feel right. First, it seems you can alter your channel
type via MIDI to be a drum channel, but there is no way to alter it back
to melodic (?).
Second, how should we calculate the new banknum in XG mode? Given your
comment, you don't seem to be certain yourself.
Could you start off with my fixed version of your patch, fix this as
well, and send a new diff back? Thanks!
// David
diff --git a/fluidsynth/include/fluidsynth/synth.h b/fluidsynth/include/fluidsynth/synth.h
index 0e7dec7..94b06d2 100644
--- a/fluidsynth/include/fluidsynth/synth.h
+++ b/fluidsynth/include/fluidsynth/synth.h
@@ -100,6 +100,15 @@ FLUIDSYNTH_API int fluid_synth_program_reset(fluid_synth_t* synth);
FLUIDSYNTH_API int fluid_synth_system_reset(fluid_synth_t* synth);
+enum fluid_midi_channel_type
+{
+ CHANNEL_TYPE_MELODIC = 0,
+ CHANNEL_TYPE_DRUM = 1
+};
+
+int fluid_synth_set_channel_type(fluid_synth_t* synth, int chan, int type);
+
+
/* Low level access */
FLUIDSYNTH_API fluid_preset_t* fluid_synth_get_channel_preset(fluid_synth_t* synth, int chan);
FLUIDSYNTH_API int fluid_synth_start(fluid_synth_t* synth, unsigned int id,
diff --git a/fluidsynth/src/synth/fluid_chan.c b/fluidsynth/src/synth/fluid_chan.c
index 50850e7..235a16a 100644
--- a/fluidsynth/src/synth/fluid_chan.c
+++ b/fluidsynth/src/synth/fluid_chan.c
@@ -67,8 +67,9 @@ fluid_channel_init(fluid_channel_t* chan)
fluid_preset_t *newpreset;
int prognum, banknum;
+ chan-channel_type = (chan-channum == 9) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;
prognum = 0;
- banknum = (chan-channum == 9)? 128 : 0; /* ?? */
+ banknum = (chan-channel_type == CHANNEL_TYPE_DRUM) ? DRUM_INST_BANK : 0;
chan-sfont_bank_prog = 0 SFONT_SHIFTVAL | banknum BANK_SHIFTVAL
| prognum PROG_SHIFTVAL;
@@ -231,9 +232,9 @@ fluid_channel_set_bank_lsb(fluid_channel_t* chan, int banklsb)
int oldval, newval, style;
style = chan-synth-bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_GS ||
- chan-channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ FLUID_BANK_STYLE_GS == style ||
+ chan-channel_type == CHANNEL_TYPE_DRUM)
return; /* ignored */
oldval = chan-sfont_bank_prog;
@@ -251,11 +252,10 @@ fluid_channel_set_bank_msb(fluid_channel_t* chan, int bankmsb)
int oldval, newval, style;
style = chan-synth-bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_XG ||
- chan-channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ FLUID_BANK_STYLE_XG == style ||
+ chan-channel_type == CHANNEL_TYPE_DRUM)
return; /* ignored */
- //TODO: if style == XG and bankmsb == 127, convert the channel to drum mode
oldval = chan-sfont_bank_prog;
if (style == FLUID_BANK_STYLE_GS)
@@ -263,6 +263,7 @@ fluid_channel_set_bank_msb(fluid_channel_t* chan, int bankmsb)
else /* style == FLUID_BANK_STYLE_MMA */
newval = (oldval ~BANKMSB_MASKVAL) | (bankmsb (BANK_SHIFTVAL + 7));
chan-sfont_bank_prog = newval;
+
}
/* Get SoundFont ID, MIDI bank and/or program. Use NULL to ignore a value. */
diff --git a/fluidsynth/src/synth/fluid_chan.h b/fluidsynth/src/synth/fluid_chan.h
index 879dc6f..38caf8f 100644
--- a/fluidsynth/src/synth/fluid_chan.h
+++ b/fluidsynth/src/synth/fluid_chan.h
@@ -74,6 +74,10 @@ struct _fluid_channel_t
* flag indicating whether the NRPN value is absolute or not.
*/
char gen_abs[GEN_LAST];
+
+ /* Drum channel flag, CHANNEL_TYPE_MELODIC, or CHANNEL_TYPE_DRUM. */
+ int channel_type;
+
};
fluid_channel_t* new_fluid_channel(fluid_synth_t* synth, int num);
diff --git a/fluidsynth/src/synth/fluid_synth.c b/fluidsynth/src/synth/fluid_synth.c
index d583154..b134704 100644
--- a/fluidsynth/src/synth/fluid_synth.c
+++ b/fluidsynth/src/synth/fluid_synth.c
@@ -1876,13 +1876,13 @@ fluid_synth_program_change(fluid_synth_t* synth, int chan, int prognum)
/* Special handling of channel 10 (or 9 counting from 0). channel
* 10 is the percussion channel.
*
- * FIXME - Shouldn't hard code bank selection for channel 10. I think this
+ * FIXME - I think this
* is a hack for MIDI files that do bank changes in GM
Re: [fluid-dev] MIDI bank select problems
On Thu, Nov 28, 2013 at 11:53 PM, Chris Robinson chris.k...@gmail.comwrote:
On 11/28/2013 08:05 PM, Element Green wrote:
Good idea to read through the archives.. I also did this and came up with
a thread which occurred around the date when the code was checked in for
the synth.midi-bank-select option. I came up with this email in
particular
from Pedro which describes the MMA mode:
https://lists.nongnu.org/archive/html/fluid-dev/2010-08/msg00046.html
Hmm, odd. According to that, Creative thinks MMA mode should be CC0*128 +
CC32, but neither the GM1 or GM2 standards define this behavior. In fact,
GM1 doesn't have bank select messages, and GM2 hadn't been adopted yet when
the SoundFont (1 or 2) stuff was created. Looks like this is just what
Creative thought the MMA was going to standardize on, but it's really an XG
mode that doesn't ignore CC0 as part of the bank number.
The original MIDI standard pretty much spells that out, though I think
there was some confusion around it leading to divergent vendor standards.
CC 32-63 are supposed to be the least significant bytes and CC 0-31 the
most significant bytes of 14 bit controller values.
Instead, the MMA went a different way with GM2. CC0 selects a channel type
(120 = percussion (only allowed on channels 9 and 10), and 121 = melodic),
and CC32 selects a bank (must be 0 on percussion channels).
I don't really see it as a different way in respect to MIDI, but more in
comparison to the other instrument mapping standards. Interpreting CC0 and
CC32 as MSB/LSB of a 14 bit number (as the GM2 article on Wikipedia also
says), then GM2 percussion is on bank 15360 and the melodic banks start
at 15488. While SoundFont files physically can store up to a 16 bit value
for bank numbers, the specification says it should be limited from 0-127
for melodic banks and 128 is for percussion. So it seems like if a GM2
mode were to be added to FluidSynth, the actual bank numbers would be set
to the usual SoundFont convention, rather than trying to conform SoundFont
files to the GM2 spec. So a GM2 SoundFont would contain melodic
instruments and variations on the various banks and percussion presets
would still be on bank 128, as usual. A gm2 mode could be added to
FluidSynth which would respond to a CC0 MSB bank value of 120, by assigning
percussion bank 128 and ignoring the LSB. Or in the case of CC0 MSB being
121, CC32 LSB would be used to select the bank number.
I'm personally curious though, why you chose GM2 as your
MIDI variation of choice?
Mainly because GS and XG are vendor-specific, while GM2 is about as
standard as you can get here. And unlike GM1, GM2 allows switching channel
9 to act like a normal channel, which I feel adds an important bit of
flexibility in letting the app developer worry about where and how
instruments can be mapped in a custom soundfont.
What becomes standard is what is wide spread and adopted, whether its
defined by a vendor or MMA. SoundFont for that matter is a vendor
specification. I haven't seen many GM2 SoundFont files around and I'm not
sure how many MIDI files there are out there, perhaps someone can elighten
me on this. I agree though, that having more flexibility in regards to
percussion channels is good. Currently the only MIDI mode which FluidSynth
supports which has that feature is XG mode (bank 120-127 selects
percussion, anything else is melodic).
In reading that above email, however, it seems Creative says SF2 synths
must use GS mode by default, and I'm aiming for OpenAL Soft's MIDI
extension to provide an SF2-compatible synth so developers can know what
they're working with. So I guess I shouldn't try forcing GM2 on
initialization.
Still, that leaves the question of how to allow apps to use the
bank/instrument they want on channel 9. I suppose the correct way would
be for them to send a GM2 On sysex message {0x7E, 0x09, 0x03}, as described
here http://www.midi.org/techspecs/midimessages.php, if they want it.
But I don't think FluidSynth recognizes that.
The other possibility is that I could watch for CC32 being set to 120 or
121 on channels 9 and 10 in OpenAL's MIDI event handler, switching the
channel to be percussion or melodic accordingly via
fluid_synth_set_channel_type, and leaving CC0 to be the bank number as per
GS mode (basically reversing the bytes as described in GM2).
Supporting the GM2 On sysex message sounds like the better option to me,
as its the more standards-compliant way. Watching CC32 is also a
possibility, but I'd like to avoid custom behavior if I can.
I had worked on some code which selected the MIDI mode based on SYSEX
messages, but I think it was abandoned at some point, can't remember why.
Perhaps it was the complication of other caveats in regards to MIDI modes
(not just bank selection). Seems like SYSEX mode selection would be a good
thing to have for other MIDI modes as well, though.
At any rate, I think such logic should
Re: [fluid-dev] Unloading unused patch between MIDI playbacks + force bank
Hello Christian, On Sun, 2008-04-20 at 10:13 +0200, Christian Casteyde wrote: Hello, First of all, thanks for fluidsynth which is... fluid! It's fast and works reliably on any machine I used it, without latency and without CPU hog. Seems too to have less noise in the output sound thand Timidity:-) I'm thinking however to small things, that IMHO prevent fluid from being a good candidate for default soft synth on low end machines (at least on linux), till having high sound quality. Sound quality is really fine with good SF2, but good SF2 are huge. So I'm wondering if fluidsynth could have an option to tell it to unload instruments when it is not playing any MIDI file (as timidity option -U). So fluid would reduce its RAM requirements when it's not used (OK, that could be swapped out by the system, but then it would be prone to latencies). Or maybe mlock RAM only before playing the file? Better: I'm also wondering if it would be possible to add an option for loading only instruments used by a MIDI file? (It could be tricky if the MIDI file uses program changes of course: that would imply preparsing it. Moreover, that could not work with generic MIDI clients connected). So, instead of having, say 64MB of sound samples in memory, only having 2-4MB while playing a file... Another question: I tried to play a file I played on a yamaha piano, that uses XG. Precisely, it uses a MSB/LSB 128 to select its own bank. fluidsynth does not recognise it, and the file is not played. However, apart from the bank, the instrument number is the same (1 for Grand Piano), so would it be possible to simply ignore bank change if the bank is not present in the SF2, just to be able to still play everything with GM instruments? (timidity indeed seems to do that... at least with is option --force-bank. Meanwhile I'm compelled to edit the MIDI file with RoseGarden, or select standard piano on my piano before playing). Thanks for all Regards The new Swami does its own instrument processing and supports sample loading on demand (when a preset is assigned). I'm not sure if in practice this is fast enough for MIDI file playback though, but I imagine it usually would be. Pre-scanning the MIDI file for program change events would help, as you suggested. I'm still not certain what to do with the FluidSynth instrument processing. I have thought about moving more of the functionality from libInstPatch and Swami in regards to the synthesis instrument handling into FluidSynth. An alternative may be to use Swami directly, but that kind of removes the freedom of choice that FluidSynth has offered. It would definitely be nice to have more flexible sample loading and sample streaming support as well. Best regards, Josh ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] 1.1.0 release TODO and commit status
Here is my current FluidSynth TODO list for 1.1.0: - Fix documentation issues (private files in files list, missing docs) - Add new functions in fluid_synth.c to public headers. - fluid_sequencer_process() relative time? - Revert to incremental instrument selection per channel - Update FluidSynth man page - Change yes/no settings to boolean options with yes/no string compatibility code. - Have shell help command default to help help to list help topics. Let me know if there is anything I have missed. I went ahead and removed the midi-mode and note-off ignore code. It wasn't very useful at this point, as David pointed out. We can add it when there is improved gm/gs/xg support. David: What do you think about converting fluid_sequencer_process() to use relative time instead of absolute? Would there be any reason to move backwards in time? The current API is limited to ~48 days of sequencer time, not that I plan on writing any masterpieces that are that long ;) Ebrahim mentioned that he preferred the previous default instrument assignment, which was incremental program numbers for each channel. This is nice for just testing out different instruments at high speed, by just switching channels. I think it was changed to be more GM compliant. Any opinions on this? When we add real GM support, the instruments can be reset to Piano for all channels when GM mode is entered. It might be good to keep backwards compatibility with previous versions of FluidSynth in this regard. Most boolean setting options in FluidSynth are currently string values with yes/no options. This seems semi inconsistent and messy, since there is at least 1 boolean parameter which is an integer 0/1 with a TOGGLE hint. I'm tempted to turn all boolean options into integer ones, but still allow for string assignment of yes/no (maybe even true/false). This would likely be transparent to most programs. I think it would be a good idea to have help default to what is currently help help in the shell. I think many users overlook the fact that there are more commands than what is just listed for the General help. This would help to prevent that. Summary of more prominent recent commits: Removed fluid_file_renderer_get_(type_names/format_names/endian_names) from API, since they are now settings. A valid audio format will be searched if a file type is used and the s16 format fails. This means Ogg/Vorbis works with latest libsndfile. Added audio.jack.server and midi.jack.server settings for specifying Jack server. OSS and Pulse drivers now honor realtime settings. Improved/added command line help output for many options (-a, -E, -m, -O, -T) and added Rendering audio to file 'filename.wav'.. and welcome message to -F fast render option. Regards, Josh ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
Hi Jimmy,
I am not a FluidSynth developer, just an interested person, so my opinions
don't represent the view of the FluidSynth project.
This seems like a valuable generalisation of a previously hard-coded value.
Given that your new flag will default to 0 for all channels and 1 for
channel 9, it won't change anything but add a useful new feature.
A few points: Firstly, in the future could you attach your patches as
attachments instead of pasting them at the end. It makes them much easier to
read and apply.
Add a flag to struct:
_fluid_channel_t
to indicate it is a drum channel, using int type, with value:
0: melodic channel
1: drum channel
Since this is a boolean (the name is is_drum_channel), your code should
use the constants FALSE and TRUE instead of 0 and 1 (existing FluidSynth
code uses these constants, but uses the type 'int' instead of 'bool').
Might it be better to generalise to an enum?
enum fluid_channel_type
{
CHANNEL_TYPE_MELODIC,
CHANNEL_TYPE_DRUM
};
And call the field fluid_channel_type channel_type.
It's questionable whether there would ever be more channel types in the
future other than melodic and drum, but at least it would make code clearer
to see, for instance, chan-is_drum_channel = (9 == num) ?
CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC; instead of chan-is_drum_channel
= (9 == num) ? 1 : 0;. Can anybody think of any reason why, in the future,
there would be more channel types than melodic or drum?
+
+ /* Drum channel flag, 0 for melodic channel, 1 for drum channel.
+ * Previously, even for 32, 48, 64 channels only channel 9 can be drum,
+ * channel 25, 41, 57 were not treated as drum channel at all, even
though
+ * ALSA shows 2, 3, 4 ports (each with 16 midi channels).
+ * We can optionally initialize channel 25, 41, 57 be GM drum channel if
we
+ * want for each of those 16 midi channels -- need to change channel
+ * initialization, but may break existing apps unless they explicitly
set
+ * these channels.
+ * Moreover, GM2 allows 2 drum channels 10 and 11 (9, 10 with
zero-indexing).
+ * Some older XG may use drum channels 9 and 10 (8, 9 with
zero-indexing).
+ * Added at end of structure, hopefully existing apps using this
structure may
+ * still work without having to recompile for the time being. */
+ int is_drum_channel;
+
This comment reads more like a commit log than a comment -- the changes you
have made and the rationale for them (and discussion of breakages) don't
belong in comments in the code itself. I would delete all but the first line
of this comment.
As for the issues raised in there, I think we should definitely only set
channel 9 to drum, for backwards compatibility.
- *
- * FIXME - Shouldn't hard code bank selection for channel 10. I think
this
- * is a hack for MIDI files that do bank changes in GM mode. Proper way
to
- * handle this would probably be to ignore bank changes when in GM mode.
- JG
*/
I don't think this FIXME has been fully resolved. I don't quite understand
it, but it says that the proper way to handle it would be to ignore bank
changes, which isn't what your patch is doing. Can you explain what this
comment means and why it's OK to remove it?
Good work on that patch.
Matt
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Fluidsynth Channels
Craig David: I have been doing something similar with Fluidsynth and Rosegarden. I simply add additional Fluidsynth 'engines' (done at the bottom of the Qsynth window). Each such engine independently handles 16 MIDI channels. In Rosegarden, I add additional General MIDI banks/devices. I assign 16 MIDI channels to one, 16 MIDI channels to the next, etc. If you have a fast enough processor, you could easily add enough Fluidsynth engines for the 100 or so instruments in a symphony orchestra. If your processor is not sufficiently powerful, but you have a Soundblaster (or Audigy) sound card with the emu10k1 processor, it gives you 4 hardware synthesizers (16 ports each, = 64 simultaneous instruments), with very little processor overhead. You could also connect to multiple external synthesizers. Another way, is to do 16 MIDI tracks, then record it to an audio track, then do the next 16 MIDI tracks playing with the audio track. This process can be repeated. Beware of latency, which can get you in such a process. It's no problem if you are improvising/playing against what you hear, but if you are going from notation, it could be a problem. You can use the Jog Right segment command, but that is only approximate, and in my experience, can cause worse latency problems. - Aere On Wed, 2011-11-30 at 08:45 +0100, David Henningsson wrote: On 11/29/2011 09:14 PM, Craig wrote: My question is, gleaning the fluidsynth source and docs it appears that fluidsynth can handle midi channels above the 0-15, given that information, how does a midi file format hand of a midi event with a standard note on - 144 + midi channel, message1, message2, and time stamp. If I increas the 144 + midi channel, I end up in 160 land which is a different midi event. I am a 50 year old man who write symphonies. I would love to have access to more that 16 channels. How does fluidsynth do this? Hi Craig and thanks for your interest in FluidSynth! The MIDI file format does not support more than 16 channels - this is a limitation in the MIDI file format, not FluidSynth. You'll have to use special API calls in order to make use of more than 16 channels. That said; XG level 2 and level 3 seems to support more than 16 channels. Does anybody know if there is a MIDI file meta event that would switch group of MIDI channels for this track or something? I haven't found anything myself, but it would be very useful if it existed. Also, please ask questions on the mailinglist when everyone can benefit from the answer. Thanks! // David ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev -- Sincerely, Aere ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] [ANN] The QStuff* Autumn'19 Release
Hello there! It's coming true: the old bunch of Qstuff*, QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all catching up and aligning to the magical version 0.6.0 :) That's all pretty much and enough for now ;)... ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.6.0 (autumn'19) is out! QjackCtl is a(n ageing yet modern, not so 'simple' anymore) Qt [7] application to control the JACK [8] sound server, for the Linux Audio [12] infrastructure. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: https://sourceforge.net/projects/qjackctl Downloads: https://sourceforge.net/projects/qjackctl/files - source tarball: https://download.sf.net/qjackctl/qjackctl-0.6.0.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.rncbc.suse.src.rpm - binary package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git Change-log: - Graph: avoid self-connecting over their own ports when client nodes are selected as a whole group; also try to match port-types in a orderly fashion when connecting multiple selected ports. - Changing current JACK buffer size from Setup dialog (cf. Settings / Frames/Period) may now take effect just immediately ;) - An 'Apply' button as been added to the Setup dialog; ask whether to restart the JACK audio server, if any settings are changed. - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Command line arguments (--start, --preset=[label] and --active-patchbay=[path]) are passed and take effect on the current singleton/unique application instance, when enabled and already running. - System-tray icon context menu has been refactored to be exactly the same as the main-window context menu that is re-instantiated on demand. - Make sure compiler flags comply to c++11 as standard. ** Qsynth - A fluidsynth Qt GUI Interface [2] ** Qsynth 0.6.0 (autumn'19) is out! Qsynth is a FluidSynth [10] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Website: https://qsynth.sourceforge.io http://qsynth.sourceforge.net Project page: https://sourceforge.net/projects/qsynth Downloads: https://sourceforge.net/projects/qsynth/files - source tarball: https://download.sf.net/qsynth/qsynth-0.6.0.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.6.0-19.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsynth/qsynth-0.6.0-19.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.6.0-19.x86_64.AppImage Git repos: https://git.code.sf.net/p/qsynth/code https://github.com/rncbc/qsynth.git https://gitlab.com/rncbc/qsynth.git https://bitbucket.com/rncbc/qsynth.git Change-log: - Updated the old yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - System-tray icon context menu has been refactored to be exactly the same as the main-window context menu that is re-instantiated on demand. - Make sure compiler flags comply to c++11 as standard. ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.6.0 (autumn'19) is out! Qsampler is a LinuxSampler [11] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Website: https://qsampler.sourceforge.io http://qsampler.sourceforge.net Project page: https://sourceforge.net/projects/qsampler Downloads: https://sourceforge.net/projects/qsampler/files - source tarballs: https://download.sf.net/qsampler/qsampler-0.6.0.tar.gz - source package: https://download.sf.net/qsampler/qsampler-0.6.0-31.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsampler/qsampler-0.6.0-31.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.6.0-31.x86_64.AppImage Git repos: https://git.code.sf.net/p/qsampler/code https://github.com/rncbc/qsampler.git https://gitlab.com/rncbc/qsampler.git https://bitbucket.com/rncbc/qsampler.git Change-log: - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Make sure compiler flags comply to c++11 as standard. ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.6.0 (autumn'19) is out! QXGEdit is a live XG instrument editor, specialized on editing MIDI System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus probably a baseline for many other XG devices. Website: https://qxgedit.sourceforge.io http://qxgedit.sourceforge.net Project page: https://sourceforge.net/projects/qxgedit Downloads: https://source
Re: [fluid-dev] Tickets, project status, and 1.1.0
Hi David, Quoting David Henningsson launchpad@epost.diwic.se: j...@resonance.org skrev: Good questions! I converted a lot of functions over in fluid_synth.c to use the thread safe lock free event queue if not called by the synthesis thread, as we discussed. Its not currently buildable though, and there is still a bit of work to do (it has started to feel a little bit like an overhaul). I tested things with basic note-on/note-off messages through the queue, which worked fine. I think we should try and make FluidSynth 1.1.0 completely thread safe (as far as crashes and potential synthesis anomalies). Okay. I agree that it would be dumb to leave the thread safety half-implemented for 1.1.0. But if you feel that you don't have the time to work with it, perhaps we can work on it together. Let me know if you would like that. Sure, if you would like to work on it too, that would be great. I was a bit apprehensive about checking things in in a broken state. How do you want to go about collaborating on things? Do you think we should create a separate work branch or just assume that subversion trunk will be broken sometimes? Once we decide this, I can check my changes in and describe what I'm doing. One user who is building FluidSynth on the iPhone, mentioned that glib is not supported currently on that platform. I started to think that we might want to make glib optional for certain platforms. The iPhone seems like a case where building FluidSynth single threaded would be OK, which would mean less boiler plate as far as needing to implement the thread related functions. Perhaps Windows might also be a candidate for optional glib, though that might be a bit more of a pain to maintain. I'm leaving all glib specific code out of most FluidSynth source files and providing simple macro #defines or implementations in fluid_sys.c. I changed g_return_if_fail to fluid_return_if_fail for example. This means glib is something we should try to avoid rather than try to use, when we write new code? What about the data structures (lists etc), should we copy glib code for that, like we did before glib was introduced? Yeah.. It will make things more difficult for us. glib is nice and convenient for many of these data structures. We could make a little standalone glib compatibility library which gets statically linked in, in which we borrow code directly from glib. The license is compatible, so there shouldn't be any problem with that. It seems like one of the main things going for FluidSynth in certain environments is the minimal amount of dependencies that it has. It would be great to be able to just work on free software projects and make money at it too ;) I read somewhere that the Daniel Langlois Foundation sponsored FluidSynth a while ago. Perhaps you could see if they're willing to do that again. Sponsorship would be an interesting thing to look into. Setting up paypal donations could also be good or having a bounty system (users pledge an amount for a certain task). I have not yet seriously attempted making money at working on free software, though it has consumed much of my time in the past 10 years. The need to make an income definitely affects how much time I have available for free software projects though, so receiving money for working on FluidSynth would definitely give me more time to work on it. I don't think we should rush the release of 1.1.0 at this point though, since there aren't a huge amount of features that are being held back. I'd much rather get things right and have a more well rounded FluidSynth worthy of the 1.1.0 version bump. On the whole I agree with you here, but I also have a personal interest in getting it into Ubuntu. I've made sure we have 1.0.9 in the upcoming Karmic (release in October), but I'm less sure that 1.1.0 will make it into that version now. What particular features are you trying to get into the next version of Ubuntu? Perhaps we could release another 1.0.x version if need be, which include these changes. As far as I am aware there aren't a whole lot of tasks in progress at the moment. While there may be many tickets assigned to myself, only the FluidSynth config file and thread safe event queue tasks are currently being worked on by me. I'm not aware of any other tasks in progress. Others on the list: Please speak up if you are currently working on one or more FluidSynth tasks. As for myself, I'm not working on anything at the moment. Things I'm thinking of fixing is one or some of these: Sounds great! Let me know how I can help make things easier for you to work on tasks. - Compatibility with GM/GS/XG/GM2 etc. Problems: Need do buy documentation, unless anybody has it? In particular, fix correct default values. This will of course be a change of behaviour, perhaps we need a legacy mode as well to keep backwards compatibility? I imagine most
Re: [fluid-dev] Revised patch for new channel field is_drum_channel
--- On Fri, 1/28/11, David Henningsson di...@ubuntu.com wrote:
On 2011-01-28 23:07, jimmy wrote:
Here's the revised patch file for the new channel
field is_drum_channel.
Thanks, but you're missing the patch :-)
// David
Oops, here it is.
Jimmy
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_chan.c fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.c
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.c 2011-01-28 13:30:52.0 -0500
@@ -52,6 +52,7 @@ new_fluid_channel(fluid_synth_t* synth,
chan-synth = synth;
chan-channum = num;
+ chan-is_drum_channel = (9 == num) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;
chan-preset = NULL;
chan-tuning = NULL;
@@ -68,7 +69,7 @@ fluid_channel_init(fluid_channel_t* chan
int prognum, banknum;
prognum = 0;
- banknum = (chan-channum == 9)? 128 : 0; /* ?? */
+ banknum = (chan-is_drum_channel) ? DRUM_INST_BANK : 0;
chan-sfont_bank_prog = 0 SFONT_SHIFTVAL | banknum BANK_SHIFTVAL
| prognum PROG_SHIFTVAL;
@@ -231,9 +232,9 @@ fluid_channel_set_bank_lsb(fluid_channel
int oldval, newval, style;
style = chan-synth-bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_GS ||
- chan-channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ FLUID_BANK_STYLE_GS == style ||
+ chan-is_drum_channel)
return; /* ignored */
oldval = chan-sfont_bank_prog;
@@ -251,11 +252,9 @@ fluid_channel_set_bank_msb(fluid_channel
int oldval, newval, style;
style = chan-synth-bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_XG ||
- chan-channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ chan-is_drum_channel)
return; /* ignored */
- //TODO: if style == XG and bankmsb == 127, convert the channel to drum mode
oldval = chan-sfont_bank_prog;
if (style == FLUID_BANK_STYLE_GS)
@@ -263,6 +262,14 @@ fluid_channel_set_bank_msb(fluid_channel
else /* style == FLUID_BANK_STYLE_MMA */
newval = (oldval ~BANKMSB_MASKVAL) | (bankmsb (BANK_SHIFTVAL + 7));
chan-sfont_bank_prog = newval;
+
+ /* if style == XG and bankmsb == 127, convert the channel to drum mode.
+ * How should newval above be calculated (same as MMA style) ??? */
+ if (style == FLUID_BANK_STYLE_XG (127 == bankmsb))
+ {
+ chan-is_drum_channel = CHANNEL_TYPE_DRUM;
+ }
+
}
/* Get SoundFont ID, MIDI bank and/or program. Use NULL to ignore a value. */
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_chan.h fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.h
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.h 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.h 2011-01-28 13:08:42.0 -0500
@@ -74,6 +74,10 @@ struct _fluid_channel_t
* flag indicating whether the NRPN value is absolute or not.
*/
char gen_abs[GEN_LAST];
+
+ /* Drum channel flag, CHANNEL_TYPE_MELODIC, or CHANNEL_TYPE_DRUM. */
+ int is_drum_channel;
+
};
fluid_channel_t* new_fluid_channel(fluid_synth_t* synth, int num);
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_synth.c fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_synth.c
--- fluidsynth.svn399.20101221/src/synth/fluid_synth.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_synth.c 2011-01-28 13:48:14.0 -0500
@@ -1876,13 +1876,13 @@ fluid_synth_program_change(fluid_synth_t
/* Special handling of channel 10 (or 9 counting from 0). channel
* 10 is the percussion channel.
*
- * FIXME - Shouldn't hard code bank selection for channel 10. I think this
+ * FIXME - I think this
* is a hack for MIDI files that do bank changes in GM mode. Proper way to
* handle this would probably be to ignore bank changes when in GM mode. - JG
*/
if (prognum != FLUID_UNSET_PROGRAM)
{
-if (channel-channum == 9)
+if (channel-is_drum_channel)
preset = fluid_synth_find_preset(synth, DRUM_INST_BANK, prognum);
else preset = fluid_synth_find_preset(synth, banknum, prognum);
@@ -1893,7 +1893,7 @@ fluid_synth_program_change(fluid_synth_t
subst_prog = prognum;
/* Melodic instrument? */
- if (channel-channum != 9 banknum != DRUM_INST_BANK)
+ if ((! channel-is_drum_channel) (DRUM_INST_BANK != banknum))
{
subst_bank = 0;
@@ -4990,3 +4990,22 @@ void fluid_synth_api_exit(fluid_synth_t*
}
}
+
+
+/**
+ * Set midi channel type
+ * @param synth FluidSynth instance
+ * @param chan MIDI channel number (0 to MIDI channel count - 1)
+ * @param type CHANNEL_TYPE_MELODIC, or CHANNEL_TYPE_DRUM
+ * @return FLUID_OK on success, FLUID_FAILED otherwise
+ */
+int
Re: Re: [fluid-dev] Re: Son of ticket #65
Gents, my personal observations and thoughts without being a programmer: I can second that since FS release 1.1.1 patches of bank 0 [bank 1 after Chris' definition] using CC00 are *not* called correctly, until we introduce to re-route bank 0 patch calling using CC32. In jOrgan we can do so, but indeed it would be preferable to have bank 0[1] patch calling working with CC00 for default. There was already a bank 0 patch calling issue in FS 1.0.9 release, resulting a voice substitution. I was informed by FS error messages, that FS didn't found patches which were correctly set up in the soundfonts, and had replaced them by bank 0 patch 0. Strange though, the sounds themselves weren't replaced in fact, as they were set up correctly in the soundfonts. In FS 1.1.1 those error messages correctly appear only when patches in the soundfonts are missing in fact, but bank 0 patch calling using CC00 remains not to work correctly. I've never tested if FS 1.0.9 did work correctly with CC32. Another thought: I understood a bank change has *always* to be followed by a program change, else it's not performed at all, by definition. So may be both MSB and LSB have to be followed by a program change? Regards Bernd. - Folgende Nachricht wurde empfangen - Absender: Elimar Green Empfänger: S. Christian Collins Zeit: 2010-08-02, 04:00:28 Betreff: Re: [fluid-dev] Re: Son of ticket #65 Its been a while since the topic of MIDI bank selection was discussed, so I'm frustratingly in the dark again about it. From what I read a bank/program change is sent as such: Bank MSB (CC #0) Bank LSB (CC #32) Program change So in that case if 1 was sent for MSB and 0 was sent for LSB it would mean bank #128. If only a MSB is sent though, as in the cited example case, I'm suspecting that should be interpreted instead as an LSB value? Not sure exactly what standard defines such behavior though. Does this sound like what the issue is related to? Elimar On Sun, Aug 1, 2010 at 12:53 PM, S. Christian Collins s.chriscoll...@gmail.com wrote: Well if a default behavior has to be honored, wouldn't supporting the GS standard of bank switching be preferable to the current implementation? From what I've read, instead of selecting a patch from bank 1, FluidSynth is selecting from the percussion banks instead. Isn't this what channel 10 is for? I would expect there to be far more MIDI files using the bank select to select GS (or similar) instruments rather than trying to select a drum set on one of the melodic channels (1-9, 11-16). Perhaps I'm misunderstanding the problem, but when this was changed (sometime after 1.0.9), it seems to have been to a far inferior solution. As the composer of the March mentioned in the discussion, I expect those bank 1 patch change commands to select a specific strings preset when used with GeneralUser GS, and if a patch isn't available on that bank, then it falls back to the corresponding preset on bank 0 (in this case 48:Fast Strings). Every synth I've played this March on has behaved in this way. I would never expect those instruments to become drum sets. -~Chris On 08/01/2010 01:08 PM, David Henningsson wrote: 2010-08-01 19:33, Pedro Lopez-Cabanillas skrev: I assume that this issue is irrelevant for the people that manages this project. So probably fluidsynth 1.1.2 is going to be released with this bug? If that was a question to me, I would say you are welcome to commit a change assuming it fixes more songs that it messes up, basically. What's not likely to happen in 1.1.2 is behavior being dynamic, i e changed based on GM/GM2/GS/XG sysex'es in MIDI files. // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: Son of ticket #65
Bernd, The banks selectable via CC0 are numbered 0 through 127 with bank 0 containing the initial instrument set (or capital tones). Using Bank 0 in reference to the first bank beyond the initial tone set is misleading and incorrect. Bank 0 is the bank containing the initial tones, bank 1 would be the first variation tones set. If you use CC0 to select bank 0, you will end up selecting the initial instrument set. -~Chris On 08/02/2010 03:31 AM, Bernd Casper wrote: Gents, my personal observations and thoughts without being a programmer: I can second that since FS release 1.1.1 patches of bank 0 [bank 1 after Chris' definition] using CC00 are *not* called correctly, until we introduce to re-route bank 0 patch calling using CC32. In jOrgan we can do so, but indeed it would be preferable to have bank 0[1] patch calling working with CC00 for default. There was already a bank 0 patch calling issue in FS 1.0.9 release, resulting a voice substitution. I was informed by FS error messages, that FS didn't found patches which were correctly set up in the soundfonts, and had replaced them by bank 0 patch 0. Strange though, the sounds themselves weren't replaced in fact, as they were set up correctly in the soundfonts. In FS 1.1.1 those error messages correctly appear only when patches in the soundfonts are missing in fact, but bank 0 patch calling using CC00 remains not to work correctly. I've never tested if FS 1.0.9 did work correctly with CC32. Another thought: I understood a bank change has *always* to be followed by a program change, else it's not performed at all, by definition. So may be both MSB and LSB have to be followed by a program change? Regards Bernd. - Folgende Nachricht wurde empfangen - *Absender:* Elimar Green mailto:elimargr...@gmail.com *Empfänger:* S. Christian Collins mailto:s.chriscoll...@gmail.com *Zeit:* 2010-08-02, 04:00:28 *Betreff:* Re: [fluid-dev] Re: Son of ticket #65 Its been a while since the topic of MIDI bank selection was discussed, so I'm frustratingly in the dark again about it. From what I read a bank/program change is sent as such: Bank MSB (CC #0) Bank LSB (CC #32) Program change So in that case if 1 was sent for MSB and 0 was sent for LSB it would mean bank #128. If only a MSB is sent though, as in the cited example case, I'm suspecting that should be interpreted instead as an LSB value? Not sure exactly what standard defines such behavior though. Does this sound like what the issue is related to? Elimar On Sun, Aug 1, 2010 at 12:53 PM, S. Christian Collins s.chriscoll...@gmail.com mailto:%20s.chriscoll...@gmail.com wrote: Well if a default behavior has to be honored, wouldn't supporting the GS standard of bank switching be preferable to the current implementation? From what I've read, instead of selecting a patch from bank 1, FluidSynth is selecting from the percussion banks instead. Isn't this what channel 10 is for? I would expect there to be far more MIDI files using the bank select to select GS (or similar) instruments rather than trying to select a drum set on one of the melodic channels (1-9, 11-16). Perhaps I'm misunderstanding the problem, but when this was changed (sometime after 1.0.9), it seems to have been to a far inferior solution. As the composer of the March mentioned in the discussion, I expect those bank 1 patch change commands to select a specific strings preset when used with GeneralUser GS, and if a patch isn't available on that bank, then it falls back to the corresponding preset on bank 0 (in this case 48:Fast Strings). Every synth I've played this March on has behaved in this way. I would never expect those instruments to become drum sets. -~Chris On 08/01/2010 01:08 PM, David Henningsson wrote: 2010-08-01 19:33, Pedro Lopez-Cabanillas skrev: I assume that this issue is irrelevant for the people that manages this project. So probably fluidsynth 1.1.2 is going to be released with this bug? If that was a question to me, I would say you are welcome to commit a change assuming it fixes more songs that it messes up, basically. What's not likely to happen in 1.1.2 is behavior being dynamic, i e changed based on GM/GM2/GS/XG sysex'es in MIDI files. // David ___ fluid-dev mailing list fluid-dev@nongnu.org mailto:%20fluid-...@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev ___ fluid-dev mailing list fluid-dev@nongnu.org mailto:%20fluid-...@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
On Wednesday, August 11, 2010, Elimar Green wrote: Actually I take that back, about it sounding good.. It seems like adding a MIDI mode which requires manual assignment of that value, without proper SYSEX handling, will likely lead to many MIDI songs not working properly Please, back your claim with some URLs. If there are really many MIDI songs not working properly, you can probably find a few examples on Internet. (like if a user is playing multiple MIDI files which are of different modes). The 1.0.9 logic, should handle most MIDI modes, in regards to bank switching. Personally I think its a better option at this point. The only thing that logic doesn't do, is properly ignore certain messages. Messages which are unlikely to be sent in their respective modes anyways, though I admit I'm not sure how many MIDI files might be out there which don't follow that rule (for example send LSB MIDI messages though they expect them to be ignored). I suppose you could still add the setting, but have a special auto or compatibility mode which follows the 1.0.9 logic. The user could then force a particular mode with that setting. FluidSynth-1.0.9 doesn't properly handle neither the GS nor the XG bank select messages, mainly because it doesn't ignore the CC messages that can't understand, processing them in a wrong way that sometimes and only by chance sounds acceptable. The new implementation in 1.1.2 at least handles well all GS files by default, and can be set to correctly handle the other standards as well. About your doubts WRT the LSB messages: The LSB/CC#32 message is common in MIDI files created for the Roland Sound Canvas instruments [1]. This is an excerpt from my SC-88's Owner's Manual, Chapter 7. Appendix, page 21. The SC-88 recognizes the Bank Select LSB (controller number 32) as a flag for switching between the SC-88MAP and the SC-55MAP. With a Bank Select LSB of 00H, the map selected by the front panel SC-55MAP button will be selected. With a LSB of 01H, the SC-55MAP will be selected. With a LSB of 02H, the SC-88MAP will be selected. Some other GS devices do not recognize the Bank Select LSB (Controller number 32). The SC-55 was an older model of the Roland Sound Canvas family. Indeed, *there are* songs on the net created for the SC-88/SC-55 that aren't correctly handled by FluidSynth-1.0.9, and are better handled by our current 1.1.2 implementation. And eating my own dogfood, here is one. Song: -Funny Funny Little Girl- Galaxy Fraulein Yuna OVA#1 Opening http://webspace.webring.com/people/rr/rgm111/funny.mid Initial MIDI channel assignments. chancc#0cc#32PC 1 0 164 2 0 132 3 0 15 4 0 148 5 0 150 6 8 148 7 8 130 8 8 161 9 0 184 10 0 18 11 0 125 12 0 154 13 0 152 14 0 1100 15 0 1115 16 0 116 Rendering this file with FluidSynth-1.0.9, using Christian's GeneralUser font. $ ./fluidsynth -a alsa GeneralUser_GS_FluidSynth_v1.43.sf2 funny.mid fluidsynth: ALSA driver: Using format s16, rw, interleaved FluidSynth version 1.0.9 Copyright (C) 2000-2006 Peter Hanappe and others. Distributed under the LGPL license. SoundFont(R) is a registered trademark of E-mu Systems, Inc. Type 'help' for information on commands and 'help help' for help topics. fluidsynth: warning: Instrument not found on channel 0 [bank=1 prog=64], substituted [bank=0 prog=64] fluidsynth: warning: Instrument not found on channel 2 [bank=1 prog=5], substituted [bank=0 prog=5] fluidsynth: warning: Instrument not found on channel 1 [bank=1 prog=32], substituted [bank=0 prog=32] fluidsynth: warning: Instrument not found on channel 4 [bank=1 prog=50], substituted [bank=0 prog=50] fluidsynth: warning: Instrument not found on channel 5 [bank=1025 prog=48], substituted [bank=0 prog=48] fluidsynth: warning: Instrument not found on channel 6 [bank=1025 prog=30], substituted [bank=0 prog=30] fluidsynth: warning: Instrument not found on channel 7 [bank=1025 prog=61], substituted [bank=0 prog=61] fluidsynth: warning: Instrument not found on channel 8 [bank=1 prog=84], substituted [bank=0 prog=84] fluidsynth: warning: Instrument not found on channel 10 [bank=1 prog=25], substituted [bank=0 prog=25] fluidsynth: warning: Instrument not found on channel 11 [bank=1 prog=54], substituted [bank=0 prog=54] fluidsynth: warning: Instrument not found on channel 13 [bank=1 prog=100], substituted [bank=0 prog=100] fluidsynth: warning: Instrument not found on channel 14 [bank=1 prog=115], substituted [bank=0 prog=115] fluidsynth: warning: Instrument not found on channel 15 [bank=1 prog=16], substituted [bank=0 prog=16] channels chan 0, Soprano Sax chan 1, Acoustic Bass chan 2, FM Electric
Re: [fluid-dev] Program change problems with fluidsynth
_ Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=notation@nongnu.org] Im Auftrag von Tom M. Gesendet: Montag, 8. Mai 2017 21:36 An: FluidSynth mailing list Betreff: Re: [fluid-dev] Program change problems with fluidsynth > I think the issue is created with the converstion tool from the .abc to the > .mid file. > All midi Program Changes (also those for track/chn 1,2,3) are placed to track > 4. > [...] To my knowledge a Program Change of a track/chn should be set within > the track and not outside the track. You're right. The order of events is determined by their tick and implicitly by their order within a track. Scattering the events across tracks loses the implicit order criteria, which obviously can result in strange behaviour (Note however that it's absolutely legal to do that). Relevant is that the NoteOns of channel 1,2,3 happen at the same tick (noteably tick 1) as the prog changes of chans 1,2,3. Apparently fluidsynth comes along, reading and enqueueing the NoteOns first, later finding the prog changes and enqueueing them at the same tick, but after the note ons... which is too late. The standard doesnt seem to be very verbose on the effect order of midi events that happen at the same tick. Probably because there is no such order. The only statement regarding program changes I could find: "The program must change upon the receipt of the Program Change message. However, the program need not be changed for a note which is already sounding." (The Complete MIDI 1.0 Detailed Specification, document version 96.1) Which basically means that everybody can do what they want, i.e. some synths start the notes as organ, others dont. > Moving the Program Change to the appropriate track solves the issue. Probably only because you've put the prog changes before the note ons (same tick). Doing it the other way round wouldnt work. [Reinhold] Tom: Thanks for digging into the spec. We at Notation Software have analysed tons of midi files and find a Program Change event only in the same track. This is the first time that I see a midi file where a Program Change is not in the same track. But you are right, everybody can do what they want. Francesco: so just make sure that every program change happens one tick before note ons. For your file, change the byte at offset 0x05AC from 0x01 to 0x00. [Reinhold] Francesco: There is the great freeware tool PSRUTI from Heiko Plate available (Please see: <http://www.heikoplate.de/mambo/index.php?option=com_content=blogcategory=67=44> http://www.heikoplate.de/mambo/index.php?option=com_content=blogcategory=67=44 ) which shuffles around the midi events and brings all into the right order. The tool has an old fashioned user interface but many years of experience and feedback have been put into this tool. The internal logic is excellent. Running your midi file through this tool with "GM Conversion" or "XG Optimization" solves the issue. Reinhold Tom 2017-05-08 19:32 GMT+02:00 Reinhold Hoffmann <reinh...@notation.com>: Hi Francesco, I think the issue is created with the converstion tool from the .abc to the .mid file. All midi Program Changes (also those for track/chn 1,2,3) are placed to track 4. When playing the first Note On of track 1,2,3 at that point in time the Program Change settings of track 1,2,3 are undefined for the playing program. Therefore the default setting Piano is used. Later (not timewise later but from an execution of the playing software) when playing track 4 the Program Change of track 1,2,3/chn 1,2,3 are set to be 21 which will modify the sound to organ for all notes to be played later. To my knowledge a Program Change of a track/chn should be set within the track and not outside the track. Moving the Program Change to the appropriate track solves the issue. I have checked the issue because we at Notation Software (www.notation.com) use the fluidsynth libraries, too. From the fluidsynth perspective I believe fluidsynth is fine. Our software acts as such that Program Change is only allowed within the same track. With our software in your example track 1,2,3 play as piano throughout, track 4 as organ throughout. Hope this analysis help Reinhold -Ursprungliche Nachricht- Von: fluid-dev [mailto:fluid-dev-bounces+ <mailto:fluid-dev-bounces%2Breinhold> reinhold=notation.com@nongnu. <mailto:notation@nongnu.org> org] Im Auftrag von Francesco Ariis Gesendet: Dienstag, 2. Mai 2017 11:31 An: fluid-dev@nongnu.org Betreff: [fluid-dev] Program change problems with fluidsynth Hello fluidsynth users/devs, today I tried to render a midi file (attached) with fluidsynth via command line: fluidsynth -a alsa -F audio.ogg -T oga /usr/share/sounds/sf2/FluidR3_GM.sf2 hymn1.mid I attach the first few seconds of the audio file too. As you can hear, the first note (the first beat I should say)
