VOGONS


Reply 820 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
Roland User wrote:

By the way , Instrument list in SoundFont banks very good thing ) I always wanted known what have in SoundFont bank )
Thank you Zoltan )

You're welcome 😀

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 821 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

Hi Zoltan)
Please , Improve work MUNT :
https://yadi.sk/d/7D-bf6iMScrxtg
https://yadi.sk/i/mqeOO7frtC3zuw
this freeze will be if use 32 bit float point )
My PC Core i7-6800K @ 3.4 GHz / 32 GB RAM 4 channel )
I think what this can improve ) If I use output without float point - freeze more.

Reply 822 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Please, be serious... 😀
This freeze-2.mid is a quasi black midi file. At it's peak it occupies more than 600 simultaneous voices (tested with Bassmidi). Even on your video it can be seen that all partials are used all the time. Munt is not for such artificial test files. It's an MT-32 emulator after all.
As I have said before even your i7 (especially in floating point mode) can be a bottleneck since Munt only uses 1 core/thread for emulation. Floating point emulation mode in Munt is much more demanding than integer mode.
For testing set your SAVIHost's processor affinity to 1 core (select only CPU 0 in task manager) and you will see that the 1st core's CPU occupation will be 100% when you hear the distortion.
You should decrease the maximum active partials from 64 to Munt/MT-32 default 32 partials (or turn off floating point mode) to get better results with this midi file.
Munt VSTi is only a plugin interface for the Munt core so if you have problem with the current performance characteristic of Munt you can report it here (but I really do not think Serg will consider this a real problem):
Munt Reloaded - Development

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 823 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

Falcosoft

As I have said before even your i7 (especially in floating point mode) can be a bottleneck since Munt only uses 1 core/thread for emulation. Floating point emulation mode in Munt is much more demanding than integer mode.

On the contrary , If I disable float point freeze becomes only more )

Reply 824 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

On the contrary , If I disable float point freeze becomes only more )

Then your PC must be very unique 😀
I have made a video about playing back your midi on my system. It's much slower than yours (it's a 10 years old Phenom II). As you can see in integer mode your midi can be played back without distortion at the critical part (when both synths are active because of your midi using channels 9/11 so partial usage peaks at 128). In floating point mode at the same part you can hear the same distortion than on your video at the same part. And as you can also see processor occupation is higher all the time in floating point mode:
https://youtu.be/SUxKPfNQBto

Ps: I used SAVIHost in my video just that our cases can be more comparable.
If it's true that on your system integer mode is more problematic than floating point then try another midi player (maybe FSMP). The player can also be the source of your problem.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 825 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

And yes and no )
I'm can not understand why in MUNT delayed sound even after stop playback ) in MUNT still playback sended notes to synth ) as if buffer is small)
Increase values for audiobuffer this problem not fix.

Reply 826 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

1. I cannot do anything with your cryptic words like :

And yes and no )

. If I have time to write whole sentences for you then you (the one who always has problems) should have also... So please, be more specific in your answers. I think I can expect meaningful reactions from you the same way you expect reactions to your marginal problems...

I'm can not understand why in MUNT delayed sound even after stop playback ) in MUNT still playback sended notes to synth ) as if buffer is small)

2. Since Munt has to process the excessive amount of events your midi file contains. This processing requires time and seemingly Munt cannot do the processing real time with such amount of messages. Also the default emulation mode of Munt's 'Midi Delay mode' is 'Delay Short messages' to emulate the restrictions of real Midi hardware. In your case you should set Midi Delay mode to 'Process events immediately' since it results in faster processing of excessive amount of Note On/Off messages.

But once and for all you should understand one thing: The main goal of Munt is to emulate real hardware. And the real hardware would process your special midi files also very badly.
This goal is seemingly very different from yours but for the majority of us it's more beneficial.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 827 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

Falcosoft
I'm so sayd and yes and no because if be honest I not known where bottleneck , but you answered to me )
I wanted discover as improve work in dual synth mode and GM mode )
I understand what MUNT it MT-32 Emulator and this mode preferred ) , but I thinked , what if use for playback MIDI as synth , can make work synth faster if this possible )
Thank you

Reply 829 of 1251, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Though, to serious, I don't really see a performance problem with the mt32emu engine. I played it with mt32emu-qt/64 partials/float mode - CPU load doesn't rise above 25% (G4400 @ 3.30GHz). Indeed, that's a cheat since mt32emu-qt outputs integer audio to the system.

Another thought, increasing the audio buffer size is always a good idea to overcome such issues. But in that complex setup, I'm not sure where exactly the buffer needs to be increased (SAVIHost maybe?). Ultimately, one may convert the MIDI to a WAV/Flac and play it back further without any CPU overload 😀

Reply 830 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

My fix to the Roland User's problem: reduce tempo down to the standard 120 BPM 😀

Hi Serg,
It seems Roland user has found the root of his last delayed notes problem. It was the 'Midi Delay mode' that was set to 'Delay Short messages'.

Though, to serious, I don't really see a performance problem with the mt32emu engine. I played it with mt32emu-qt/64 partials/float mode - CPU load doesn't rise above 25% (G4400 @ 3.30GHz). Indeed, that's a cheat since mt32emu-qt outputs integer audio to the system.

Me neither, but for the sake of fairness it should be noted that 25% CPU usage on a multi-core CPU does not mean much in case of Munt since e.g. as can be seen on my video on a 4 core CPU overall 25% CPU usage can still mean that the 1 rendering thread of Munt uses 1 thread/core at 100% fully so it can still be a bottleneck.

Also you may have missed but it can also be seen on the video that in floating point mode the stuttering started when 128 partials were activated. So your test with 64 max partials is not so conclusive. It's because contrary to regular Munt driver/QT app, Munt VSTi uses 2 synth instances to achieve full 16 channel GM compatibility. So when channel 9/11 is activated (on the 2nd synth) by the midi the active partials raise to 128 immediately since the 64 maximum is a per synth settings. So for a more fair comparison you should set maximum partials to 128 in mt32emu-qt app.
So the cheat on your side was not using integer audio output but using only half the maximum partials used by Munt VSTi 😀 .

Another thought, increasing the audio buffer size is always a good idea to overcome such issues. But in that complex setup, I'm not sure where exactly the buffer needs to be increased (SAVIHost maybe?).

Unfortunately raising the audio buffer cannot help here much (especially not in floating point mode) since on some (even 3GHz+) processors 128 active partials fully overload 1 thread of the CPU. So while on dual core you will only see 50% CPU usage, on quad core 25% CPU usage (and so on) the bottleneck is still on the rendering side itself (actually constantly).

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 831 of 1251, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I just re-tested it with 128 partials, as you suggested - still 30% is the peak load. Note, my system is dual core, so it's still much room to fill up 😉

But I guess, the comparison can't be adequate anyway because of those additional MIDI channels. On the other hand, I don't fully understand why you limited both synths to a single core. This is the cheapest way to implement multi-threading for mt32emu 😀 I'd expect each synth to run in it's own thread if the system offers more than just 1 core. To be fair, we've investigated the possibility to split rendering into several threads as soon as the rendering speed became an issue initially. Independently, KingGuppy and me became to a conclusion that the synchronisation overhead makes that nearly pointless, though I tested it with dual core CPUs only those times. Maybe now, when 8 cores is a usual thing, it is time to reconsider that and to provide a way for the consumer application to utilize multi-threading. What do you think?

Reply 832 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi,
Yeah, I support the idea of multi-threaded rendering.
Actually I have already implemented a multi-threaded version of the plugin long time ago that runs the 2 synths on 2 different threads but I have met some rare threading issues. So since I have found the single threaded version is somewhat more stable (and met not so serious demand for 128+ active partials that never occur with contemporary midi files used by the retro community) I decided not to release it until I find the root of the problems. But maybe the time has come. I have just compiled a test version of it (that is somewhat inconsistent since does not contain the latest changes) but can be used for testing:
http://falcosoft.hu/muntvsti_mt_test.zip
I do not remember exactly how to reproduce the threading issues but I remember for normal playing it usually works without problems.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 833 of 1251, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Falcosoft wrote:

Hi,
Actually I have already implemented a multi-threaded version of the plugin long time ago that runs the 2 synths on 2 different threads but I have met some rare threading issues.

Hi Zoltan,

Yes, threading issues can be very nasty. In order to make the code reliable, we introduce locking that may happily annihilate the advantages we expect from multi-threading, that's true. Though, running two independent synth doesn't look to me that problematic, especially if there is a possibility to direct each synth output to a dedicated audio channel. So, I'm bit surprised 😀 Another matter is splitting the work of the rendering engine - it is much more of a headache. But provided that the user desires a lot of partials and has a lot of cores for spare, that sounds rather plausible.

Reply 834 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

Falcosoft
Thank You ) in multithread workin very good for standard use as MIDI Synth with more polyphony )
If you want make all best in one , I offert create checkbox work as multithread or checkbox work as singlethread ) somehow so )

Reply 835 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

Yes, threading issues can be very nasty. In order to make the code reliable, we introduce locking that may happily annihilate the advantages we expect from multi-threading, that's true. Though, running two independent synth doesn't look to me that problematic, especially if there is a possibility to direct each synth output to a dedicated audio channel. So, I'm bit surprised 😀 Another matter is splitting the work of the rendering engine - it is much more of a headache. But provided that the user desires a lot of partials and has a lot of cores for spare, that sounds rather plausible.

Hi Serg,
I have experimented with the multi-threaded version of the plugin a little and under Win10 x64 I could not reproduce threading problems (but it could be just a coincidence). But under WinXP x86 I could with a few tries. I have made a video about it.
https://youtu.be/TUf3QiC0NoU
The point is once the plugin runs everything works perfectly. The problem can only be reproduced when the plugin is re-initialized (because of sample rate changes). As you can see it took 1 min 24 sec to achieve this (so it's hard to reproduce). When the problem happens:
1. There is no deadlock on the plugin's side. The plugin itself works perfectly and gets no errors whatsoever from the Munt engine. But the 2nd synth is clearly frozen and no audio samples are produced by either synths. But they both seem to react to e.g. mt32emu_get_part_states() and it seems the 2nd synth reports that 4 partials are actually stuck. Also the 1st synth seems to still react to any other Midi messages (even SysEx ones). But the 2nd synth remains in a stuck state and does not react to Midi messages at all.
In this state mt32emu_close_synth() -> mt32emu_open_synth() sequences (that are used by the config dialog) cannot repair the engine. Only a full reload of the plugin can help.
But the point is no deadlocks or errors are shown on the plugin's side so it's hard to determine what happened and how to correct it.
Also it's important that this never happens with the single threaded version.
Do you have any idea?

Ps: It's not possible to direct each synth's output to a dedicated audio channel. The rendered samples of both synths have to be mixed and sent to the VST Host through its rendering thread in the processReplacing() VST callback (that is called continuously by the VST Host while the plugin is alive).

@Roland User:
Maybe later when all problems are solved.
But I have transported all the changes of the newer versions to the multi-threaded test version so you should download it again.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 837 of 1251, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

@Roland User:
AFAIK Munt VSTi in GM mode already satisfies the requirements of GM Lite and with some rare exceptions (such as Channel pressure, GM coarse and fine tuning that are not used widely in regular Midi files) also the full GM:
https://www.midi.org/specifications/item/general-midi-lite
https://www.midi.org/specifications/item/general-midi
So please specify more clearly what you mean by 'also work as standard GM device '.

By the way Serg responded in a private message. The point is there does not seem to be an immediate solution for the problems of the multi-threaded version of the plugin, so I will not release it in its current state.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 838 of 1251, by Roland User

User metadata
Rank Member
Rank
Member

Falcosoft

I have in view of what can make MUNT VST which will be procesin MT-32 mode with any delay values , and will be ignore all delay valuses if send to synth GM reset ) also in GM mode not need delay messages )

Reply 839 of 1251, by appiah4

User metadata
Rank l33t++
Rank
l33t++

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?

Retronautics: A digital gallery of my retro computers, hardware and projects.