Falcosoft wrote on 2024-08-05, 21:02:

1. Thanks! 2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are nec […]
Show full quote

Spesek wrote on 2024-08-05, 20:12:

Hi Falco, Alright, I've changed it to "must not be taken into account". Also, I have an idea for new chunks (similar to WAV): IP […]
Show full quote

Falcosoft wrote on 2024-08-05, 19:44:

Hi, Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'dat […]
Show full quote

Hi,
Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'data' and 'INFO' -> 'ICOP' chunks.
I still do not think that the right size calculation of a chunk should be 'optional'.

The attachment bachsb.zip is no longer available

Hi Falco,
Alright, I've changed it to "must not be taken into account".
Also, I have an idea for new chunks (similar to WAV):
IPRD: Album title
IART: Artist (IENG could be the creator of the soundfont and IART could be the creator of the midi)
IGNR: Song's genre
IPIC: Album cover image (or any image). Only PNG or JPEG allowed and the chunk's data is the binary of the image

All of these are optional, of course.
What do you think?

1. Thanks!
2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are necessary but of course they cannot hurt anything either.
Most likey FSMP will not support these extended chunks 😀

Hi,
That's fine. But if you change your mind, have this for testing:

It has name, artist, album, copyright, creation date and an album cover. Spessa should read these fine (click the "toggle music mode" button to see)

I think that for now, these tags are enough. And also i've added that a RMI-compliant synth can ignore all INFO chunks except DBNK as it's necessary to play files correctly.
Let me know what you think!

@Edit:
Github wikis (which the RMID spec is hosted on) are not indexed by Google. For example googling "about RMIDI" or 'SpessaSynth RMIDI' doesn't lead to the page.
This greatly limits their reach. That's why it would be great if you hosted a copy (or a link) on falcosoft.hu, as your website shows up in google search. It would greatly help popularizing this format.
No pressure of course 😀

Spesek wrote on 2024-08-06, 00:41:

Hi, That's fine. But if you change your mind, have this for testing: […]
Show full quote

Falcosoft wrote on 2024-08-05, 21:02:

1. Thanks! 2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are nec […]
Show full quote

Spesek wrote on 2024-08-05, 20:12:

Hi Falco, Alright, I've changed it to "must not be taken into account". Also, I have an idea for new chunks (similar to WAV): IP […]
Show full quote

Hi Falco,
Alright, I've changed it to "must not be taken into account".
Also, I have an idea for new chunks (similar to WAV):
IPRD: Album title
IART: Artist (IENG could be the creator of the soundfont and IART could be the creator of the midi)
IGNR: Song's genre
IPIC: Album cover image (or any image). Only PNG or JPEG allowed and the chunk's data is the binary of the image

All of these are optional, of course.
What do you think?

1. Thanks!
2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are necessary but of course they cannot hurt anything either.
Most likey FSMP will not support these extended chunks 😀

Hi,
That's fine. But if you change your mind, have this for testing:

The attachment Bad Apple!!.zip is no longer available

It has name, artist, album, copyright, creation date and an album cover. Spessa should read these fine (click the "toggle music mode" button to see)

I think that for now, these tags are enough. And also i've added that a RMI-compliant synth can ignore all INFO chunks except DBNK as it's necessary to play files correctly.
Let me know what you think!

@Edit:
Github wikis (which the RMID spec is hosted on) are not indexed by Google. For example googling "about RMIDI" or 'SpessaSynth RMIDI' doesn't lead to the page.
This greatly limits their reach. That's why it would be great if you hosted a copy (or a link) on falcosoft.hu, as your website shows up in google search. It would greatly help popularizing this format.
No pressure of course 😀

Hi,
1. Most of the extended chunks are displayed now in Midi Text/Lyrics dialog as 'Riff MIDI Info'. The 'IPIC' and 'IENC' chunks are ignored by FSMP. But in the x64 version you can change the actual code page manually (it has been working this way for many years).
https://falcosoft.hu/midiplayer_65_test.zip

2. Maybe later. I have never been great at popularizing anything 😀

Falcosoft wrote on 2024-08-06, 13:08:

Hi, 1. Most of the extended chunks are displayed now in Midi Text/Lyrics dialog as 'Riff MIDI Info'. The 'IPIC' and 'IENC' chunk […]
Show full quote

Spesek wrote on 2024-08-06, 00:41:

Hi, That's fine. But if you change your mind, have this for testing: […]
Show full quote

Falcosoft wrote on 2024-08-05, 21:02:

1. Thanks!
2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are necessary but of course they cannot hurt anything either.
Most likey FSMP will not support these extended chunks 😀

Hi,
That's fine. But if you change your mind, have this for testing:

The attachment Bad Apple!!.zip is no longer available

It has name, artist, album, copyright, creation date and an album cover. Spessa should read these fine (click the "toggle music mode" button to see)

I think that for now, these tags are enough. And also i've added that a RMI-compliant synth can ignore all INFO chunks except DBNK as it's necessary to play files correctly.
Let me know what you think!

@Edit:
Github wikis (which the RMID spec is hosted on) are not indexed by Google. For example googling "about RMIDI" or 'SpessaSynth RMIDI' doesn't lead to the page.
This greatly limits their reach. That's why it would be great if you hosted a copy (or a link) on falcosoft.hu, as your website shows up in google search. It would greatly help popularizing this format.
No pressure of course 😀

Hi,
1. Most of the extended chunks are displayed now in Midi Text/Lyrics dialog as 'Riff MIDI Info'. The 'IPIC' and 'IENC' chunks are ignored by FSMP. But in the x64 version you can change the actual code page manually (it has been working this way for many years).
https://falcosoft.hu/midiplayer_65_test.zip

The attachment Rmidi_Info.png is no longer available

2. Maybe later. I have never been great at popularizing anything 😀

Hi,
Thanks for implementing the chunks! It works great.

Though, it seems to reject files with utf-8 encoded characters. It doesn't want to play them at all:

As you can see, riffpad reads the chunks fine, and so does spessa. But FSMP6 rejects the file completely (the main display still shows bad apple and not the new title.)

The file is too large to upload here, so I uploaded it on filetransfer (it stripped the name. The original name is "フラワリングナイト.rmi"):
https://filetransfer.io/data-package/JuhwpJLq#link

EDIT: The file works fine with a normal name (i renamed it to "issue"). Still, I think it should work fine even with strange name (on the 64-bit version).
EDIT 2: The utf-8 option doesn't seem to read the INFO chunks correctly.

It shoud be:
Album: 全人類ノ天楽録 東方緋想天 ORIGINAL SOUND TRACK
Artist: あきやまうに & ZUN

Am I doing something wrong? If so, let me know.

PS:
Here are all theoretically supported encodings. I've only found midis with utf-8. shift_jis and windows-1250. Though, I could limit it to only the encodings FSMP6 supports. (I'd clarify in the spec which encodings are allowed) That way maybe it could automatically switch the encoding on 64-bit version via the IENC chunk?

Hi,
As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file names.
But there is a workaround (at least on Windows) that the x86 version implemented. Namely it can use the 8.3 DOS name of the file/folder when characters outside of the current code page is detected. But in order this to work you have to enable the 8.3. file name generation on the volumes. In Windows you can do this with the
fsutil 8dot3name set x: 0 command where 'x' is your volume.
Also make sure you re-copy the3 affected files to the volume again after you have executed the command.
The reason is the existing files do not have 8.3 file names after the command executed, only new ones will get it.

BTW, the x64 version of FSMP fully supports unicode so if you insist on using file names with unicode characters you should use the x64 version instead.

Falcosoft wrote on 2024-08-06, 13:55:

Hi, As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file na […]
Show full quote

Hi,
As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file names.
But there is a workaround (at least on Windows) that the x86 version implemented. Namely it can use the 8.3 DOS name of the file/folder when characters outside of the current code page is detected. But in order this to work you have to enable the 8.3. file name generation on the volumes. In Windows you can do this with the
fsutil 8dot3name set x: 0 command where 'x' is your volume.
Also make sure you re-copy the3 affected files to the volume again after you have executed the command.
The reason is the existing files do not have 8.3 file names after the command executed, only new ones will get it.

BTW, the x64 version of FSMP fully supports unicode so if you insist on using file names with unicode characters you should use the x64 version instead.

I am using the 64bit version here.

Spesek wrote on 2024-08-06, 14:02:

Falcosoft wrote on 2024-08-06, 13:55:

Hi, As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file na […]
Show full quote

Hi,
As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file names.
But there is a workaround (at least on Windows) that the x86 version implemented. Namely it can use the 8.3 DOS name of the file/folder when characters outside of the current code page is detected. But in order this to work you have to enable the 8.3. file name generation on the volumes. In Windows you can do this with the
fsutil 8dot3name set x: 0 command where 'x' is your volume.
Also make sure you re-copy the3 affected files to the volume again after you have executed the command.
The reason is the existing files do not have 8.3 file names after the command executed, only new ones will get it.

BTW, the x64 version of FSMP fully supports unicode so if you insist on using file names with unicode characters you should use the x64 version instead.

I am using the 64bit version here.

The attachment it_is_64.png is no longer available

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine.
On real Windows with the x64 version everything works perfectly (including UTF-8 texts):

What if make detect version Windows and if FSMP will be detect Windows from version NT 5.1 and later , use same algorithm what use in x64 version ? If version Windows 9x , so FSMP will use old algorithm ) , this possible ?

Roland User wrote on 2024-08-06, 14:06:

What if make detect version Windows and if FSMP will be detect Windows from version NT 5.1 and later , use same algorithm what use in x64 version ? If version Windows 9x , so FSMP will use old algorithm ) , this possible ?

No, the decision is made at compile time.

Falcosoft wrote on 2024-08-06, 14:05:

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine. On real Windows with the x64 version e […]
Show full quote

Spesek wrote on 2024-08-06, 14:02:

Falcosoft wrote on 2024-08-06, 13:55:

Hi, As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file na […]
Show full quote

Hi,
As I have said already the x86 version of FSMP is not unicode aware (ANSI only). This is true for anything including file names.
But there is a workaround (at least on Windows) that the x86 version implemented. Namely it can use the 8.3 DOS name of the file/folder when characters outside of the current code page is detected. But in order this to work you have to enable the 8.3. file name generation on the volumes. In Windows you can do this with the
fsutil 8dot3name set x: 0 command where 'x' is your volume.
Also make sure you re-copy the3 affected files to the volume again after you have executed the command.
The reason is the existing files do not have 8.3 file names after the command executed, only new ones will get it.

BTW, the x64 version of FSMP fully supports unicode so if you insist on using file names with unicode characters you should use the x64 version instead.

I am using the 64bit version here.

The attachment it_is_64.png is no longer available

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine.
On real Windows with the x64 version everything works perfectly (including UTF-8 texts):

The attachment unicode1.png is no longer available

Alright, so it's the wine's fault. I didn't know that.
You got me there. Sorry!

But what do you think of the IENC chunk setting the encoding on the 64-bit version? Maybe only the windows-125X encodings, utf-8 and shift-jis (called 932 in FSMP6)? I could also clarify in the spec that only these are allowed.

Hi again,
I've added some specifications on the required features of the RMIDI (the DBNK chunk) and other levels of compability.
If something is wrong in the spec, let me know and I'll try to fix it ASAP.

Also, the maintainer for fluidsynth said that he'll accept a PR for RMIDI support, so I will work on that!

PS: Also I've added your way of using RMIDI to spessa: the ability to use it with a full GM soundfont. Works with the Rock_test.rmi!

Spesek wrote on 2024-08-06, 14:12:

Alright, so it's the wine's fault. I didn't know that. You got me there. Sorry! […]
Show full quote

Falcosoft wrote on 2024-08-06, 14:05:

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine. On real Windows with the x64 version e […]
Show full quote

Spesek wrote on 2024-08-06, 14:02:

I am using the 64bit version here.

The attachment it_is_64.png is no longer available

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine.
On real Windows with the x64 version everything works perfectly (including UTF-8 texts):

The attachment unicode1.png is no longer available

Alright, so it's the wine's fault. I didn't know that.
You got me there. Sorry!

But what do you think of the IENC chunk setting the encoding on the 64-bit version? Maybe only the windows-125X encodings, utf-8 and shift-jis (called 932 in FSMP6)? I could also clarify in the spec that only these are allowed.

Hi,
OK, I have added support for the 'IENC' chunk. So FSMP x64 supports all the listed code pages from the specification moreover
'cp-874' - Thai
'cp-936' - Simplified Chinese
'cp-949' - Korean
'cp-950'- Traditional Chinese

If no explicit code page definition (no 'IENC' chunk) is found then FSMP's behavior somewhat differs from the 'reference' implementation. Namely it does not assume UTF-8 but the actual code page and allows the user to select the correct one from the dropdown list.
It's because chunks like 'INAM', 'ICOP', 'ICMT' etc. are also used in classic/old rmi files and you can be 100% sure that the encoding is never UTF-8 in case of old rmi files.
https://falcosoft.hu/midiplayer_65_test.zip

Best MIDI player on the internet - thank you.

The volume slider doesn't work when outputting to a MIDI keyboard. You can change the individual channels, but not the overall volume. A bit of a pain when I want to have a jam together with the track on the same keyboard because I can barely hear my own playing over the MIDI and the keyboard volume controls the track volume and the keyboard volume together. Any chance this could be fixed?

Thanks

Sye wrote on 2024-08-07, 01:43:

Best MIDI player on the internet - thank you.

The volume slider doesn't work when outputting to a MIDI keyboard. You can change the individual channels, but not the overall volume. A bit of a pain when I want to have a jam together with the track on the same keyboard because I can barely hear my own playing over the MIDI and the keyboard volume controls the track volume and the keyboard volume together. Any chance this could be fixed?

Thanks

Hi,
You should enable Device Settings dialog -> Mixer section -> Use SysEx for Volume/Balance option.
If your keyboard supports either GS or GM master volume SysEx messages then the Volume slider should work.

Apologies if I am missing something here, but how do I configure multiple MIDI ports for 32 channel playback? I have a KORG NX5R with an Arduino MIDI interface, and I'd like to configure ports 1-16 to go to Port A of the device, and 17-32 to Port B.

I can only the option to choose a single MIDI device from the preferences.

Thanks,
Rich

RichB93 wrote on 2024-08-07, 06:37:

Apologies if I am missing something here, but how do I configure multiple MIDI ports for 32 channel playback? I have a KORG NX5R […]
Show full quote

Apologies if I am missing something here, but how do I configure multiple MIDI ports for 32 channel playback? I have a KORG NX5R with an Arduino MIDI interface, and I'd like to configure ports 1-16 to go to Port A of the device, and 17-32 to Port B.

I can only the option to choose a single MIDI device from the preferences.

Thanks,
Rich

1. First you should enable 'Use Bass (Soundfonts/VSTi)' in Device settings dialog and press OK (you do not have to configure soundfonts).
Then Main menu -> Bass VST(i) Plugins -> VST Instruments, and browse to WinMM_MultiPortVsti folder in MidiPlayer's folder and select WinMM_MultiPortVsti.dll.
Press the Play buttton to start the plugin. Here you can configure 4 different ports and associate the required channel domain to them.
If 32-channel (+) Midi files are detected by Midi Player (you can see this info on the last column of the playlist) then different channel domains are routed automatically to selected ports.

(Make sure you save the plugin settings to an .fxb file and tick both 'Autoload at Startup' and 'Autoload Last Used Settings File' if you always want to use FSMP this way. If you are ready you can also save the whole setup in 'Main menu ->Configuration Presets' so you can have multiple full configurations.)

2. Another method that can be more simple if you only need 2 ports for 32-channel files and you do not want to use hardware ports but only VSTi plugins is to use the last version of VST MIDI driver together with FSMP. Newer VST Midi driver versions knows the special routing commands used by FSMP and activates needed ports automatically. So you can open VST Midi Driver port A or Port B (it does not matter) in Device Settings dialog of FSMP and the other port of the driver is activated automatically when it is needed.
https://github.com/Falcosoft/vstdriver/releases

Falcosoft wrote on 2024-08-06, 23:57:

Hi, OK, I have added support for the 'IENC' chunk. So FSMP x64 supports all the listed code pages from the specification moreove […]
Show full quote

Spesek wrote on 2024-08-06, 14:12:

Alright, so it's the wine's fault. I didn't know that. You got me there. Sorry! […]
Show full quote

Falcosoft wrote on 2024-08-06, 14:05:

If you REALLY use the x64 version then you are doing only one thing wrong: you use Wine.
On real Windows with the x64 version everything works perfectly (including UTF-8 texts):

The attachment unicode1.png is no longer available

Alright, so it's the wine's fault. I didn't know that.
You got me there. Sorry!

But what do you think of the IENC chunk setting the encoding on the 64-bit version? Maybe only the windows-125X encodings, utf-8 and shift-jis (called 932 in FSMP6)? I could also clarify in the spec that only these are allowed.

Hi,
OK, I have added support for the 'IENC' chunk. So FSMP x64 supports all the listed code pages from the specification moreover
'cp-874' - Thai
'cp-936' - Simplified Chinese
'cp-949' - Korean
'cp-950'- Traditional Chinese

If no explicit code page definition (no 'IENC' chunk) is found then FSMP's behavior somewhat differs from the 'reference' implementation. Namely it does not assume UTF-8 but the actual code page and allows the user to select the correct one from the dropdown list.
It's because chunks like 'INAM', 'ICOP', 'ICMT' etc. are also used in classic/old rmi files and you can be 100% sure that the encoding is never UTF-8 in case of old rmi files.
https://falcosoft.hu/midiplayer_65_test.zip

Hi,
about the utf-8, that's fine. spessa also allows the user to select one from the list. I've added a clarification that the software may attempt to use a different encoding than utf-8 if not specified
and I've moved FSMP6 into level 3 since it now supports IENC.

PS: Can i change the"unofficial" to "official" specification in my wiki page? 😉

Spesek wrote on 2024-08-07, 09:42:

PS: Can i change the"unofficial" to "official" specification in my wiki page? 😉

Yes, of course 😀

Falcosoft wrote on 2024-08-07, 10:09:

Spesek wrote on 2024-08-07, 09:42:

PS: Can i change the"unofficial" to "official" specification in my wiki page? 😉

Yes, of course 😀

Thanks!
Since this is now the official specification of this format, I cleaned it up (added a preable, table of contents, described behavior for incorrect file format)

Now, I know that you didn't like the fact that there are a lot of metadata chunks, but I have one last chunk idea:
MENC: the same format as IENC, but it's a hint for the MIDI file encoding (for example I export the RMIDI in a modern utf-8 encoding while the inner MIDI file uses the old shift-jis code page)

Can I add it? Pretty please 😀

Hi,
Of course, but I think it should be strictly optional at all levels. Most users would like to pack existing Midi files with even unknown encodings. You should not put the burden on the users of the format to find out everything about the source Midi file.

@Edit:
I have contacted Ian about the support of the format in Bassmidi:
https://www.un4seen.com/forum/?topic=20475.ms … 43457#msg143457

Falcosoft wrote on 2024-08-08, 03:33:

Hi, Of course, but I think it should be strictly optional at all levels. Most users would like to pack existing Midi files with […]
Show full quote

Hi,
Of course, but I think it should be strictly optional at all levels. Most users would like to pack existing Midi files with even unknown encodings. You should not put the burden on the users of the format to find out everything about the source Midi file.

@Edit:
I have contacted Ian about the support of the format in Bassmidi:
https://www.un4seen.com/forum/?topic=20475.ms … 43457#msg143457

Sure thing! It's only a hint for the software too (for example to default the encoding to suggested one, but change it if user wants t0). For example in the bad apple file i sent, the inner midi is encoded in shift-jis while the info chunk is encoded in utf-8. That's one of the use cases for this chunk.

Also thanks for reaching out to Ian! Native RMIDI support by BASS will automatically make all apps that use it work with the standard!

PS: I have moved the specification to its own repo (https://github.com/spessasus/sf2-rmidi-specification). I've added a redirect on the original wiki page as well.
A separate repo will allow for discussions, github issues (typos, enchancements, etc.) and I've even added 3 example RMIDIs for reference. And Github Repos are indexable by google so it solves the wiki problem!

@Edit:
I saw the topic on un4seen, thanks for asking about the sf2pack too! 😀