soundfont for drums

[rabarar]

soundfont for drums

[shimpe]

Traditionally in MIDI track 10 (or 9, if you count from 0) is reserved for percussion. If I import the .midi generated by the drumpattern example in lmms, then play it through the built-in sf2 player with a drum kit selected, it sounds as expected to me. This link makes me wonder if perhaps there's something missing in your soundfont (or something not layed out according to standard practice ?): https://stackoverflow.com/questions/23564706/no-preset-found-on-channel-9-when-playing-midi-with-newly-created-soundfont

[rabarar]

Can you share a link to the soundfont file you're using that correctly render the drums?

[shimpe]

Sure... I used the Arachno soundfont: http://www.arachnosoft.com/main/download.php?id=soundfont-sf2
bank 128, patch 0 (standard drum kit)

[shimpe]

Just to be sure, did you render to channel 10? e.g.

r"""

with track 0 channel 10:
    bassdrum r4 bassdrum r4 bassdrum r4
    
with track 0 channel 10:
    r4 closedhihat r4 closedhihat   

"""

[rabarar]

Looks like the soundfont that you specify has the drum kit on channel 9.

$ fluidsynth /usr/local/share/fluidsynth/Arachno\ SoundFont\ -\ Version\ 1.0.sf2 
FluidSynth version 1.1.8
Copyright (C) 2000-2017 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.

Type 'help' for help topics.

> channels
chan 0, Grand Piano
chan 1, Grand Piano
chan 2, Grand Piano
chan 3, Grand Piano
chan 4, Grand Piano
chan 5, Grand Piano
chan 6, Grand Piano
chan 7, Grand Piano
chan 8, Grand Piano
chan 9, Standard Drum Kit
chan 10, Grand Piano
chan 11, Grand Piano
chan 12, Grand Piano
chan 13, Grand Piano
chan 14, Grand Piano
chan 15, Grand Piano
> 

Can I programmatically map channels in expremigen? Or does that have to occur in fluid synth?

[shimpe]

in midi, for some reason percussion is always played on channel 10 (9): see https://en.wikipedia.org/wiki/General_MIDI#Percussion

channel number is 10 if you count from one (as expremigen does), 9 if you count from zero (as fluidsynth does) (I may have mentioned channels 11 and 10 at some point but that was the result of me misremembering the numbers)

I'm not sure what you mean with programmatically map channels? Do you want to dynamically reroute midi channels? If so, there are tools to do just that. In the past I've used "mididings".

[rabarar]

Thanks for the clarification. As you can tell, I'm not totally familiar with the MIDI conventions. I think what I'm hearing you say is that the specification in the midi-generated file is fixed, and then you make channel mappings with your SF2 file and the player (fluid synth for example) that uses your SF2 file to render the midi file on those given mapped instruments.

[shimpe]

I think we say the same thing, although I'm not entirely certain.

Indeed, the messages in a MIDI file basically consist of instructions like "on MIDI channel 5, do a "note on" for note number 65 with a velocity of 64", meaning that the channel number is hard coded in the binary midi messages themselves.

Tools like mididings, as well as midi players or digital audio workstations that speak MIDI can change the channel number on-the-fly for you (by taking the MIDI messages apart, and then regenerating them with modified channel numbers), but in a MIDI file it's all fixed.

[rabarar]

Did you create a comment lexicon for your MISEPL language?

[shimpe]

If with "comment lexicon" you mean a way to specify comments in MISPEL, it should be possible using c++ style comments, i.e. two forward slashes for a single line comment and a block enclosed in /* */ for a multi line comment, e.g.

// for single line comments, or

/*
for a block of
multiple lines
*/

But to be honest, I don't recall testing it so it might not even work correctly (ouch!).

[rabarar]

Cool -- I'll try it!

…

On Oct 27, 2017, at 6:00 PM, shiihs ***@***.***> wrote: If with "comment lexicon" you mean a way to specify comments in MISPEL, it should be possible using c++ style comments, i.e. two forward slashes for a single line comment and a block enclosed in /* */ for a multi line comment, e.g. // for single line comments, or /* for a block of multiple lines */ But to be honest, I don't recall testing it so it might not even work correctly (ouch!). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rabarar]

both comment-styles work. Good stuff.