Looking for a MIDI solution

[SagaraS]

Welcome to consequences with using MIDI and Soundfonts. The Soundfont will become part of the EXE file to ensure playback of any MIDI file that could possibly use that Soundfont. The system cannot assume which patch will be used, so it could include a few and throw away the others. This malady happens anywhere else that a Soundfont has to be packed along with other data and the execution of music related to it.

This solution is stupid and bears no relation to the actual use.

I think that if you use the API MCIsendStringA via Winmm, it's 10 times more optimal than if everything is shot into the EXE.

As I said: The sound font is 1 to 3MB in size. The midi only few bytes. And that becomes a 200MB file in the EXE? This is absolutely unacceptable. For a midi probably noted. Who programmed that?


This solution is already better. But I can't send the MIDI from a buffer to the MCI. Anyway, don't know exactly how.

Code: (Select All)

DECLARE DYNAMIC LIBRARY "WINMM"

  FUNCTION mciSendStringA% (lpstrCommand AS STRING, lpstrReturnString AS STRING, BYVAL uReturnLength AS INTEGER, BYVAL hwndCallback AS INTEGER)

  FUNCTION mciGetErrorStringA% (BYVAL dwError AS INTEGER, lpstrBuffer AS STRING, BYVAL uLength AS INTEGER)

END DECLARE



DIM filedata AS STRING



SCREEN 13



filedata = "game-over.mid"



StartMID (filedata)



DO

  _LIMIT 30

LOOP UNTIL INKEY$ <> ""



StopMID (filedata)



END





'==================================================================



SUB StartMID (filename AS STRING)

  ' Loading File in a Buffer

  ' ----------------------------------------

  'DIM SIZE AS _UNSIGNED LONG

  'DIM BUFFER AS STRING

  '

  'OPEN filename FOR BINARY ACCESS READ AS #1

  'SIZE = LOF(1)

  'BUFFER = SPACE$(SIZE)

  'GET #1, , BUFFER

  'CLOSE #1

  ' ----------------------------------------



  ReturnString$ = SPACE$(255): ErrorString$ = SPACE$(255)

  a% = mciSendStringA%("open " + filename + " type sequencer ", ReturnString$, LEN(ReturnString$), 0)

  IF a% THEN

    x% = mciGetErrorStringA%(a%, ErrorString$, LEN(ErrorString$))

    PRINT ErrorString$

    END

  END IF



  b% = mciSendStringA%("play " + filename, "", 0, 0)

END SUB



SUB StopMID (filename$)

  x% = mciSendStringA%("stop " + filename$, "", 0, 0)

  x% = mciSendStringA%("close " + filename$, "", 0, 0)

END SUB

[SMcNeill]

Can you share the gameover.mid file as well, so we can test and troubleshoot?

[SMcNeill]

Here's a working version which plays a mid song for you; as you can see, this doesn't produce any 200MB EXE filesize.

Code: (Select All)

$Unstable:Midi

$MidiSoundFontefault



Option _Explicit



Dim buffer As String

Dim h As Long



buffer = LoadData



h = _SndOpen(buffer, "memory")



_SndLoop h



Function LoadData$

    Dim Size As _Unsigned Long

    Dim MEM As String



    Open "Under-the-sea.mid" For Binary Access Read As #1

    Size = LOF(1)

    MEM = Space$(Size)

    Get #1, , MEM

    Close #1



    LoadData$ = MEM

End Function

The bas file is 1KB, the MID file is 61 KB, and the compiled EXE is 3.8KB.  All files are in the attachment below for ease of extraction and testing.

[SagaraS]

Can you share the gameover.mid file as well, so we can test and troubleshoot?

Found the problem.
You have to delete the two files soundfont.sf2 and soundfont.o from the subfolder qb64pe\internal\temp\

It doesn't do this automatically when the program starts
As soon as you use a smaller sf2 file, the soundfont.sf2 and soundfont.o file will remain.

Say always the larger file remains there. Since only the initial buffer is replaced in these files.

Totally stupid. You really have to delete it manually every time you want to use a different soundfont.

I still don't think that's a good solution.

Can't you get a Winmm API solution that does the same thing in the end?

[DSMan195276]

Currently the built-in Midi support doesn't have an option to use the Windows-provided support (which doesn't require providing a soundfont), we may add that in a later release. The current solution utilizing a provided soundfont file is cross-platform with no extra dependencies, so we implemented that first. The default provided soundfont is about 1MB in size, so not super small but also not ridiculously large (QB64-PE programs can already get larger than that anyway). Additionally, with the Windows-provided support we wouldn't be able to implement all of the `_SND*` functionality, so it would be a bit more limited compared to the current support we provide (which allows the MIDI sounds to work like any other sound).

Found the problem.
You have to delete the two files soundfont.sf2 and soundfont.o from the subfolder qb64pe\internal\temp\

I'm looking into it, it should be doing that automatically but I think I see an error in the logic to copy the `soundfont.sf2` into place (I think it copies over it without resizing the file).

[mnrvovrfc]

Now you could imagine months has passed that it has been $UNSTABLE?

I was talking from experience with another product, but QB64 might not work the same way. (shrugs)

[MasterGy]

Hello ! Maybe I don't understand the question correctly. I suffered a lot with the midi before I could issue commands with it. The management of the soundfont is the work of windows, and this qb program makes the midi driver sound. qwert piano

https://drive.google.com/file/d/1-AeTYqV...drive_link

[SagaraS]

Ok, I'll explain it again in more detail.

1. I don't want to have an additional sound font in the EXE file

2. I would like to have an external solution that uses an existing soundfont. (*.DLS, *.SF2)
Such as the standard Windows sound font under "C:\Windows\System32\drivers\gm.dls"
Or my own external sound font.

3. The MIDI file should be loaded via a BUFFER.

The MIDI should later be in an archive. So it is at a certain offset address. The MIDI should then be loaded at the position and played back in the program.

There must be a solution how to use Windows' own MIDI system in such a way that it is used as I have described. But not that a sound font is integrated into the EXE.
That's not a good solution.


I mean... 2023 and you can't address the Windows MIDI system in a way that you can use it like that?
It would be sad, because many old Win95 games can do that.
So there has to be a solution somehow.

[a740g]

There must be a solution how to use Windows' own MIDI system in such a way that it is used as I have described. But not that a sound font is integrated into the EXE.
That's not a good solution.

I disagree. Using a custom soundfont is a better cross-platform solution. It gives you complete control over how your MIDI music sounds on Windows, Linux and macOS. Now, if you do not care about Linux and macOS (that QB64-PE supports), then that's another story.

@DSMan195276 and I have had detailed discussion on supporting OS specific MIDI APIs that do not use soundfont here Add MIDI support to _SNDOPEN() · Issue #115 · QB64-Phoenix-Edition/QB64pe (github.com). We may add a cross-platform version of this using an abstraction library like RtMidi (https://github.com/thestk/rtmidi) in the future. Unfortunately, stuff like this takes time.

Having said that, I did put together a Windows-only QB64-PE library that does exactly what you need at the moment. I.e., it loads a MIDI file from a buffer and plays it using the Win32 WinMM MIDI streaming output APIs. You can find the example here: a740g/WinMIDI-Player-64: Win32 WinMM MIDI player & library for QB64-PE (github.com). The API section has a terse API doc. and the NOTES section has my notes. The library itself can be found here: a740g/Toolbox64: A740g's collection of libraries for QB64-PE (github.com).

Cheers!

[grymmjack]

Hello ! Maybe I don't understand the question correctly. I suffered a lot with the midi before I could issue commands with it. The management of the soundfont is the work of windows, and this qb program makes the midi driver sound. qwert piano

https://drive.google.com/file/d/1-AeTYqV...drive_link

@MasterGy that is a fantastic piece of work! Well done!!!