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
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
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
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
-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
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
rt (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
.
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
== 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
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
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
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
les 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 "
101 - 113 of 113 matches
Mail list logo
