appiah4 wrote:

Hello Falcosoft.. Thanks again for this fantastic software. I am using version 5.3 and I noticed a strange behavior: Whenever I use the Stop function during MIDI Playback my Roland SoundCanvas SD-35 spits out a bFL (Buffer Full) error and locks up. This occasionally also happens when one MIDI song ends and the next begins, but not always. I am using an M-Audio Uno 1x1 USB MIDI Interface for playback. Is there a compatibility setting I should be using here?

Hi,
It's not so strange in the sense that the same things happen when you press stop and before a new song starts to play. Namely the player sends Reset messages to set the synth to default state.
It's because of this:
Ways to make your MT-32 MIDIs sound right (last paragraph of the post)
By default the player sends GS Reset but also resets Controllers/Programs on each channel to default in case the Device does not understand GS. This way some kind of default state can be reached on any device without any user intervention. But of course it can be redundant. So if you know exactly what you want to send you can do it.
You can configure what kind of resets are sent by right clicking the first aid like 'Reset' button on the right hand side of the player.
You can try 3 things:

1. Select 'No SysEx'. In this state the player only sets the default Controllers/Programs on each channel but does not send any GM/GS/XG Reset SysEx messages. It can help if your problem is with SysEx messages.

2. Select 'Custom SysEx' and choose e.g. GM_ON or GS_ON.syx from the list, and then make sure this 'GM_ON' or 'GS_ON' custom SysEx is selected in the right click context menu of the Reset button.
In this state the player sends only the selected SysEx and no other Controller/Program defaults. It's because if you select a custom SysEx (even created by yourself) you know what you want and the player does not want to interfere any way with your intention. You can also select none (meaning no reset is sent at all ) by selecting 'Use Hex String' and setting the text field to 'F0 F7'.

3. You can also try to increase the 'Delay between SysEx chunks' value in the SysEx selection Dialog box.

If none of the above helps you should try another cable/driver. It's suspicious anyway since even the default settings should not cause freezing and buffer problems with any sane hardware.

Important! Before starting your experiment download the newest version since many things have changed since version 5.3 that guarantee the above written behavior:
http://falcosoft.hu/softwares.html#midiplayer

Many many thabks, will do tonight. The Roland SD-35 is based on the SC-50 which is in turn based on the GM parts of SC-55MkI; AFAIK the MkI has bugs with GM_On/Off and particularly GM_Off commands - I am thinking something related to this is going on. I will try everything advised above and let you know what, if anything, works 😀 Cheers

Hey I have a crazy Idea for a feature request. It's totally unnecessary so I would understand if you wouldn't be interested but I'd figure I'd ask anyways.

Would it be possible for you to add a jack option for output? (kind of like how you have directsound and wasapi)
If you added this I'd like there to be a option to specify a jack server on the network. The goal of this would be to have a arm based linux system to send midi to your program using midi via net and have MidiPlayer send the audio back over to that arm system via the jack protocol. (pulseaudio would also work for this)

I'm asking for this for my WavePi project... WavePi: Use Raspberry pi (2/3/4) as a AIO MIDI synth
I can fairly easily script linux and wine to stream directaudio over instead for this so I don't need it personally, but that would only work on Linux and it's also kind of a kludgey solution.

Also, what protocol does the Midi via Net use? Is it based off anything pre-existing or is it something custom just for midiplayer? Because I'm gonna need to figure out a way to get my raspberry pi to run it.

Would it be possible for you to add a jack option for output? (kind of like how you have directsound and wasapi)

Unfortunately it's not so simple. You can select DirectSound and WASAPI output since Bass supports both as audio output option on Windows. But Bass has no built-in Jack support (or even a separate Jack extension). Since I do not know much about Jack, it's not likely I could implement a Jack output by hand. Also I do not clearly understand what would be the benefit of sending the rendered audio samples back to a more constrained device. The rendered samples could be sent directly to speaker on the device that hosts FSMP with much better latency. But it's not a problem that I do not understand it clearly since I could not help even if I could understand it. 😀

Also, what protocol does the Midi via Net use? Is it based off anything pre-existing or is it something custom just for midiplayer? Because I'm gonna need to figure out a way to get my raspberry pi to run it.

It's a custom protocol used only by FSMP. But AFAIK there are already standardized protocols to achieve what you want. E.g. the network protocol rtpMIDI uses is supported by Windows and OS-X/iOS (I'm not sure about Linux).
https://www.tobias-erichsen.de/software/rtpmidi.html

Hi,

Phil has made another nice video featuring FSMP:
https://youtu.be/zRyPjvbDkvg

A new test version of FSMP 5.7 (together with Munt VSTi 2.5) is uploaded.
http://falcosoft.hu/midiplayer_57_test.zip

New testable features:
1. Added support for Midi files using SMPTE format for delta-times. This format is defined in Standard Midi File specification from the beginning yet files using it are very rare:
http://www.music.mcgill.ca/~ich/classes/mumt3 … format.html#BM2_
The majority of Midi software do not handle them properly. Windows Media Player recognizes the correct length of these files but plays them at wrong speed, other software (Van Basco, GNMidi, Foobar2K, XM_Play etc.) usually can not handle them at all. The only software I have found (and also used as a reference) that can handle them correctly is Sekaiju. Here's an example file for testing:

2. Added 'Export Selected Midis to Folder' option to right click context menu of playlist. It can be used to transfer midi files at different locations to one place. But it can also be used as a batch converter since formats such as XMI, MUS, MDS, RMI are saved as MID format files at the new location. By default the location and name/extension of the original file is added as a new Sequence Name Meta event to the new file. There is also an option to export only files that contain solos (meaning files that use only 1 patch/instrument). Don't ask why, it was a request on a Hungarian forum 😀 .

3. After some tinkering I have found workarounds for the initialization problem of the multi-threaded version of Munt VSTi so in this test package there is a new version with an option to enable this new multi-threaded code path. By default it's not enabled since it's mainly useful only in case of dual synth full GM mode and also has a 5-10% overhead in case of operating systems like Win9x that can only handle 1 CPU core and has inferior threading support. On NT based Windows overhead is minimal even in case of 1 CPU core.

I would like to use Phils method but run it on a Pi3 using Wine.. you reckon this would work? Or should I just go with munt on Pi3 and limit myself to MT32 emulation? (no native linux/arm port planned right?)

appiah4 wrote:

I would like to use Phils method but eun it on a Pi3 using Wine.. you reckon this would work? Or should I just go with munt on Pi3 and limit muself to MT32 emulation? (no native linux/arm port planned right?)

1. Unfortunately I do not know since I have never tried it. But I have doubts that the performance of Pi3 would be enough for Munt Vsti through x86 emulation. Also I'm not sure Wine on ARM can even run x86 apps by itself:
https://wiki.winehq.org/Emulation
2. No, Linux/ARM port is currently not possible.

By the way, what happened with your SoundCanvas SD-35 problem?

Thanks I will just compile and run munt natively.

I havent had time to test the SD-35 with the compatibility settings just yet. I will let you know tonight hopefully.

You can use my image:
Emulating MT-32 on an RPi2

It could use some updating, though.

Falcosoft wrote:

Unfortunately it's not so simple. You can select DirectSound and WASAPI output since Bass supports both as audio output option on Windows. But Bass has no built-in Jack support (or even a separate Jack extension). Since I do not know much about Jack, it's not likely I could implement a Jack output by hand. Also I do not clearly understand what would be the benefit of sending the rendered audio samples back to a more constrained device.

I didn't see any code in BASS for jack either, that's part of why I said I didn't expect you to implement it.

The purpose is to get a ras pi 3 to listen to the midi signals of a old dos computer, send it over wifi to a windows/linux machine running midiplayer, then have that windows/linux machine send the audio back over using netJack2 to the ras pi 3. Then the ras pi 3 decodes the audio and sends it to the line in on the dos machine's sound card.

End result is a ms dos machine that can wirelessly connect to a faster machine to use your program to play videogame music.
I can still do this though, apparently netJack2 also has a windows build with some features that should work for this, it just means I'll have to come up with a script or a wrapper or something to make this process simple enough for more than just me to use.

Falcosoft wrote:

It's a custom protocol used only by FSMP. But AFAIK there are already standardized protocols to achieve what you want. E.g. the network protocol rtpMIDI uses is supported by Windows and OS-X/iOS (I'm not sure about Linux).

I'm using rtpMIDI already, I was just wondering if it was compatible with something else cause then I could send it directly to MidiPlayer. Thanks for the suggestion though.

appiah4 wrote:

I would like to use Phils method but run it on a Pi3 using Wine.. you reckon this would work? Or should I just go with munt on Pi3 and limit myself to MT32 emulation? (no native linux/arm port planned right?)

x86 wine on a ras pi 3 IS possible and DOES work.... But it's REALLLLLLLLY slow. Far too slow to use for MidiPlayer, and definitely too slow for the SCVA vst.

The purpose is to get a ras pi 3 to listen to the midi signals of a old dos computer, send it over wifi to a windows/linux machine running midiplayer, then have that windows/linux machine send the audio back over using netJack2 to the ras pi 3. Then the ras pi 3 decodes the audio and sends it to the line in on the dos machine's sound card.

Ok. I still do not understand this fully. What is the purpose of a RPi 3 in this chain? What you have described can be all done easily without the RPi 3 with only a DOS PC and a stronger Windows PC. So instead of 3 separate devices you actually only need 2 as can bee seen in Phil's video referenced above. I could understand the situation better if you wanted to leave out a Windows PC and use only a DOS PC and a RPi 3. But if you already have a DOS PC and a more modern Windows PC adding another device to the chain is seemingly unnecessary (what's more most likely results in worse outcome).

Falcosoft wrote:

I could understand the situation better if you wanted to leave out a Windows PC and use only a DOS PC and a RPi 3. But if you already have a DOS PC and a more modern Windows PC adding another device to the chain is seemingly unnecessary (what's more most likely results in worse outcome).

That is exactly main main goal of the project, to be used as a standalone synth hidden in the computer itself. I just wanted to add a remote stream function as a optional feature to it.
The idea being that instead of wiring cables between the windows 10 pc and the dos pc, the dos pc connects to the windows pc over wifi using the ras pi hidden inside of it. This also means that the two systems don't even have to be in the same room, or even in the same house!

It would also be useful with windows 98 because you could run the stream stuff on the same machine instead of on a pi and remove the need for cables altogether. Although the amount of windows native games that used MIDI is fairly small.

But yeah, it's a small audience of a small audience that would ever use this feature, so if it requires implementing an entirely new api for audio output than I would probably suggest not implementing it. As it can be done with scripts instead, it just would be more cumbersome.

Falcosoft wrote:

Hi, It's not so strange in the sense that the same things happen when you press stop and before a new song starts to play. Namel […]
Show full quote

appiah4 wrote:

Hello Falcosoft.. Thanks again for this fantastic software. I am using version 5.3 and I noticed a strange behavior: Whenever I use the Stop function during MIDI Playback my Roland SoundCanvas SD-35 spits out a bFL (Buffer Full) error and locks up. This occasionally also happens when one MIDI song ends and the next begins, but not always. I am using an M-Audio Uno 1x1 USB MIDI Interface for playback. Is there a compatibility setting I should be using here?

Hi,
It's not so strange in the sense that the same things happen when you press stop and before a new song starts to play. Namely the player sends Reset messages to set the synth to default state.
It's because of this:
Ways to make your MT-32 MIDIs sound right (last paragraph of the post)
By default the player sends GS Reset but also resets Controllers/Programs on each channel to default in case the Device does not understand GS. This way some kind of default state can be reached on any device without any user intervention. But of course it can be redundant. So if you know exactly what you want to send you can do it.
You can configure what kind of resets are sent by right clicking the first aid like 'Reset' button on the right hand side of the player.
You can try 3 things:

1. Select 'No SysEx'. In this state the player only sets the default Controllers/Programs on each channel but does not send any GM/GS/XG Reset SysEx messages. It can help if your problem is with SysEx messages.

2. Select 'Custom SysEx' and choose e.g. GM_ON or GS_ON.syx from the list, and then make sure this 'GM_ON' or 'GS_ON' custom SysEx is selected in the right click context menu of the Reset button.
In this state the player sends only the selected SysEx and no other Controller/Program defaults. It's because if you select a custom SysEx (even created by yourself) you know what you want and the player does not want to interfere any way with your intention. You can also select none (meaning no reset is sent at all ) by selecting 'Use Hex String' and setting the text field to 'F0 F7'.

3. You can also try to increase the 'Delay between SysEx chunks' value in the SysEx selection Dialog box.

If none of the above helps you should try another cable/driver. It's suspicious anyway since even the default settings should not cause freezing and buffer problems with any sane hardware.

Important! Before starting your experiment download the newest version since many things have changed since version 5.3 that guarantee the above written behavior:
http://falcosoft.hu/softwares.html#midiplayer

I just wanted to confirm that setting Reset to GS_ON solved my problem beautifully! SD-35 recordings coming in 3.. 2.. 1..

https://soundcloud.com/user-470084971/sets/ro … nvas-sd-35-midi

appiah4 wrote:

I just wanted to confirm that setting Reset to GS_ON solved my problem beautifully! SD-35 recordings coming in 3.. 2.. 1..

I have also found something that can be useful to resolve the buffer full problem (since this can also happen during playback depending on the amount of incoming Midi messages):

Roland SD-35 ‘bFL’ (Buffer Full) Message […]
Show full quote

Roland SD-35 ‘bFL’ (Buffer Full) Message

Article #1705861 Added on Mar 20, 2012 at 3:11 PM

In order to record any MIDI information quickly, and/or in massive quantity,
you should turn Soft Thru off. This prevents the SB-55 or SD-35 from trying to
pass the incoming data ‘thru’ to the MIDI Out port which requires the processor
overload in some cases – depending on the speed and quantity of the data.

1) While holding the SET button, press the left SONG button.
2) Use the REW and FF buttons to change the display to ‘oFF.’
3) Press the SET button to finish the operation.

I have already tried this and it has done absolutely nothing good for me (disabling soft thru actually kills audio out for the disabled midi interface on my device - other people have also had this issue, but why the device exhibits this behavior I do not know..) The device works 100% fine with retro PC anyways, and now on modern systems I can set your MidiPlayer Reset to GS_ON and that has fixed all my issues 😀

Would you try Roland User's 'nice' test file to determine this kind of problem can affect the device during playback?

Falcosoft wrote:

Would you try Roland User's 'nice' test file to determine this kind of problem can affect the device during playback?

freeze-2.zip

The module gets a Buffer Overflow at the 5 seconds mark 😀 What does this mean?

The module gets a Buffer Overflow at the 5 seconds mark 😀 What does this mean?

According to Midi specification the transfer speed of ~3 KB/sec (31.25 kbit/s) should be handled by all devices. So it seems either your device or your cable/driver can not handle even this standard speed. If your device freezes at about 5 seconds mark then it seems something could not handle transfer speed even at ~1KB/sec. So it might be that your cable's driver does some buffering that results in unwanted spikes in transfer speed or your device is weak in this respect (too small internal buffers).

@Edit:
This problem most likely does not affect classic games and old school Midi files, but more modern Midi files with more note/controller/pitch bend messages can cause problems.

Hi.

I would like to ask for an info. I'm trying to use a yamaha synth: motif rack es, which has drum kit on MSB 127. There's a compatibility list to set Midi channle 10 to MSB 127 by default?

Thank you.

Aldo

RetroGC wrote:

Hi. […]
Show full quote

Hi.

I would like to ask for an info. I'm trying to use a yamaha synth: motif rack es, which has drum kit on MSB 127. There's a compatibility list to set Midi channle 10 to MSB 127 by default?

Thank you.

Aldo

Yes. You can find it in 'Main menu -> Compatibility Settings -> Fix Sfz Drum Bug (Force XG Drums)'