How will MIDI files sound on the Pyra?

[JDTAY]

Just wondering. I've been learning to compose MIDIs in Sekaiju for a project of mine, and I've noticed they sound good on Windows, but terrible on Android. You Pyra geniuses surely have a way to outdo Android though, right?

If not, I guess I could convert to another format.

 

[slaeshjag]

It depends entirely on what midi software is installed and what patches are used. Here's an example:

A midi-file as played using the mostly-terrible windows midi mapper: Here's that same midi file as played on some (can't remember which) decent sequencer with good patches: http://t.rdw.se/techno6.ogg
But lets face it, the default configuration on most linux boxes is gstreamer with freepats or something. It is known to cause ears to bleed: http://t.rdw.se/techno6_freepats.ogg

In conclusion: If you want control over how it will sound; don't use midi.

 

[Eight Bit]

In conclusion: If you want control over how it will sound; don't use midi.

It's midi... just note on/off data. It sounds like what you control with it.
If you control crappy General Midi patches with it, it sounds like crap. I'm sure that's what the android does too.
If you let it control your own samples, soft synths, drum computers and/or external hardware it's how those sound.

In conclusion: If you want to control how it sounds, use midi.

@JDTAY You WILL be able to make it sound how ever you want on or with the pyra, it just needs a little more effort than just using a player that plays midi files.
There's TONS of free, nice soundfont files available on the net which contain all prepared, sampled instrument banks and sounds you like. With the large amount of memory the Pyra has I don't think it will be a problem using even the bigger and higher quality ones.

But yeah, Basic, small GM patches are generally horrible on any machine.
I have an old Ensoniq rack mount synth which sounds great, with moody pad and great piano sounds. Back in the days I routed my midi output device to that instead of the internal engine of my pc.

Sekaiju looks like a nice tool btw, it reminds me of cakewalk which I used on windows 3.11
[doublepost=1485944196,1485942935][/doublepost]I never use SF2 anymore but I just found this, it might be useful. It's on the debian repo too
http://polyphone-soundfonts.com/en/

 

[slaeshjag]

When I said "if you want control over how it sounds", I intended it in the context of releases. As in, as soon as you are not the one setting up the midi environment, you no longer have a say in how it will sound. Just wanted to clear that up.

 

[Eight Bit]

Ah right, yes. I agree. For distributional purposes midi is not the way to go.

 

[Kazuki]

I've always use GeneralUser GS SoundFont with FluidSynth or TiMidity++ depending on what I have access to.
http://www.schristiancollins.com/generaluser.php

 

[spud42]

ahh Cakewalk... brings back memories...... i had the AWE32 Soundblaster and maxed the memory dimms... havent played with midi for years.
thanks for the link Kazuki, have downloaded ... now to see if i can do anything with it..

 

[Eight Bit]

i had the AWE32 Soundblaster and maxed the memory dimms

Heh, yes! me too! 8MB 30 pin sims.
Eventhough all my friends told me to get a Gravis Ultrasound Max for demo purposes...

 

[Linux-SWAT]

Midi files can sound quite well with eawpats or freepats, but it highly depends on the mix and the chosen instruments.

 

[Kippykip]

I'm sure there's a way to use a SF2 soundfont to listen to MIDIs, probably through TiMidity or FluidSynth like Kazuki mentioned.

 

[JDTAY]

I used Kazuki's fave soundfont and MuseScore to convert a 34 second MIDI to OGG. Only problem: it went from 4 KB to over 400 KB. I'm gonna have to watch the total file size of my project's soundtrack. Wouldn't want to fill your poor Pyras all the way up.

 

[Haraldur]

I used Kazuki's fave soundfont and MuseScore to convert a 34 second MIDI to OGG. Only problem: it went from 4 KB to over 400 KB. I'm gonna have to watch the total file size of my project's soundtrack. Wouldn't want to fill your poor Pyras all the way up.

Have you considered using a module file? It seems essentially like MIDI, but with the samples/instruments included in the file to ensure identical playback on most machines. This type of music was used in the games Deus Ex, Unreal, Unreal Tournament, Tyrian and Star Control 2 (The Ur-Quan Masters), among others, and is usually smaller than a decent .ogg or .mp3 that would be generated from it -- depending on the size of the samples included in the file. The intro music from Star Control 2 takes about 75 KiBs, while the title music from Deus Ex takes 2 MiBs (both are about 2 and a half minutes long).

 

[JDTAY]

Thanks for the advice. I'll try making a MOD file from my MIDI later, then check the file size and quality.
[doublepost=1485982361,1485974543][/doublepost]I used OpenMPT with the GeneralUser soundfont to make an IT file from my 4 KB MIDI and it came to 382 KB. By comparison, my OGG file was 484 KB, so that's a pretty good savings.

 

[Kippykip]

I used Kazuki's fave soundfont and MuseScore to convert a 34 second MIDI to OGG. Only problem: it went from 4 KB to over 400 KB. I'm gonna have to watch the total file size of my project's soundtrack. Wouldn't want to fill your poor Pyras all the way up.

I think there's a way to use a soundfont on the fly though when playing MIDI's

 

[JDTAY]

I think there's a way to use a soundfont on the fly though when playing MIDI's

Yeah, just checked, the FluidSynth library does that. I'll try incorporating it later. Guess I'll unincorporate SDL2_mixer too since the only other sounds I'll be playing are WAVs and SDL2 itself can handle those.

FluidSynth is under LGPL v2. Anyone have advice on compliance with that?

 

[_jr_]

FluidSynth is under LGPL v2. Anyone have advice on compliance with that?

IANAL, but basically it comes down to this: when distributing binaries of a (L)GPLed work you have to distribute the corresponding source code, too. Not neccessarily in the same archive or location, but by the same means (e.g. http) used to distribute the binary. Just a reference to a third party owned site is usually not enough (because it might go away or be modified; you are required to provide the version that was actually used to build the binary); also see http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites and surrounding entries. For LGPL you are additionally required to allow the user to replace the LGPLed portion of your project by a different version (without any warranty), but just using dynamic linking should take care of that (if your project isn't open source anyway).

 

[JDTAY]

Okay, so make DLL file and include source code used to make DLL file. Seems simple enough.

I don't see myself having to modify the source, so that should keep things simple too.

Edit: Wait, that's just for the Windows version. I'll have to look up how dynamically linked libraries work on Linux when I finally get a Pyra.

Edit 2: Apparently, they're called SO files. That satisfies my thirst for knowledge for now.

 

[_jr_]

Dynamic linking is the default in Debian, too, so depending on your build system it will probably be mostly automatic.

 

[Letalis Sonus]

IANAL, but basically it comes down to this: when distributing binaries of a (L)GPLed work you have to distribute the corresponding source code, too. Not neccessarily in the same archive or location, but by the same means (e.g. http) used to distribute the binary.

A written offer to provide it on request is enough, you simply need to have it on hand for at least 3 years and while providing "customer support" (GPL3: section 6, subsection b and c; GPL2: section 3, subsection b and c)

 

[Exophase]

IANAL, but basically it comes down to this: when distributing binaries of a (L)GPLed work you have to distribute the corresponding source code, too. Not neccessarily in the same archive or location, but by the same means (e.g. http) used to distribute the binary. Just a reference to a third party owned site is usually not enough (because it might go away or be modified; you are required to provide the version that was actually used to build the binary); also see http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites and surrounding entries. For LGPL you are additionally required to allow the user to replace the LGPLed portion of your project by a different version (without any warranty), but just using dynamic linking should take care of that (if your project isn't open source anyway).

Just so this is totally clear, if you use an LGPL library you don't have to distribute the source of your program (that links to the library), just the library itself - and that's only if you actually distribute its shared object files. You could skip the concern entirely by making the user install the library and I think you are allowed to have your program try to install it from some known repo.

And while a link to upstream source of the library may not satisfy the requirements of the LGPL you can still provide one to supplement the offer to provide source by request. Normally I think the "written offer" clause is out of date and goes against the spirit of the (L)GPL, but in cases where there's already some reliable location to get the exact same code I think it's pretty reasonable.

Then again, you could just include the library source code with your binary and not worry about any of this.