Likeaguest has had thoughts about the thread priorities -
I do not use MFC but Delphi (Object Pascal) has the same capabilities.
Now, in version "N" (and earlier), when activating live input mode, the thread priority for the main thread was elevated:

In version "P" I had already changed it so that it stays at "normal":

Ray890 had found a file that was correctly interpreted. This is fixed now, I think.

Ray has also some comments about the build up of notes in live playback mode. This was indeed true: I have not had any voice limiter implemented in the latest versions. In version "N" you find a new selection box here:
I guess I would make sense to always turn it off ("No limit") automatically when rendering to a file?
And turn it on (at e.g. 200?) when rendering from live input.
Ray also asked if the Voice level display could be updated more frequently. Done in version Q.

Chasp had found a problem with the VST programs list displayed in the editor. Fixed - I hope!

This version makes use of less memory for playback, but it is not yet good enough for example for the file "Fujiwara no Mokou's Theme act.5.0 32 million ICEwiimaker". I have still some aces in my sleeve, but I might choose to leave them until later - I definitely need to get this version out for public use soon!

Kenneth,
No need to hope on the VST effect preset list display..... it is working again for version Q. Well at least for the percussion strip where i found the problem...
Congratulations on this new more modern looking forum board.......
Cheers !!!!!!
chasp

Don't spend too much time with version "Q". There's something wrong with the volume levels, the right channel is too high, for some odd reason.
Also, other files than SoundFonts will not work.
Too bad.

Admin wrote:
Ray has also some comments about the build up of notes in live playback mode. This was indeed true: I have not had any voice limiter implemented in the latest versions. In version "N" you find a new selection box here:
I guess I would make sense to always turn it off ("No limit") automatically when rendering to a file?
And turn it on (at e.g. 200?) when rendering from live input.

While it nice to see that the voice limit is back, I think you mis-interpreted what I was saying about the MIDI Input bug.

What the bug actually is, is that not only does the note receiving only seem to update so many times per second, but it seems to ignore a lot of MIDI messages when there is a significant amount being received at once, such as NoteOn, NoteOff.etc Meaning there can be many dropped notes and potentially infinitely sustained notes. This seems to be the same problem that Likeaguest reported earlier.
Here's a video comparing how another MIDI Player picks up MIDI Input and what's happening on SynthFont: https://drive.google.com/open?id=0B2mBT ... 1dmNFR6WFE

The voice limit algorithm doesn't seem very intelligent at the moment and seems to drop the wrong kinds of notes at the wrong times. Check out this version of TiMidity++ to see a good implementation of a voice limiter that seems to sound pretty unnoticeable-ish, for reference.

I disagree with your idea of automatically changing the voice limit setting depending on what mode you're on. However what I think should be added is a checkmark in the play to file dialog to "Ignore max voice limit", to be checked on default. If the checkbox is unchecked and the file is rendering, include a "warning" in the status bar indicating it is rendering to a voice limit (if not on "no limit").

Admin wrote:
This version makes use of less memory for playback,

I don't see any difference in memory usage between 2012P and 2012Q. It seems to even run into the 4gb crash at the same threshold (25 million).

Now, seeing as 2012Q is infested with a bunch of obvious bugs, I won't report on that version, however I have found 4 more bugs as of 2012P:

- Cuing song with "Use Multiple Cores for playback" disabled causes program to hang (Since 2012C)
- Changing song tempo during playback causes playback progress indication to become inaccurate
- Wait times due to loading MIDI files, Preparing data for Playback (on larger tracks), and Saving MIDI Files have the potential of bringing up "Not Responding" status, therefore hiding status bar updates
- Reaction to Pitch Bend events are a little too strong, as can be easily heard in this MIDI when comparing with other MIDI players

One more thing, it may be nice to see the progress of loading/preparing/saving that's in the status bar duplicated in the output area of the mini play control window which is usually blank at those stages anyway.

PS: Congrats on the new forum, it's looking pretty good

Last edited by ray890 on Sun May 24, 2015 4:39 am, edited 1 time in total.

Thanks ray890,
Version Q is indeed not worth the trouble.
I have a new one in the baking, but it will take a few more days.
The voice limiter algorithm is definitely NOT clever at all. I originally had a better one, but it took too much CPU time.

Now, to the important message. You say:

- Cuing song with "Use Multiple Cores for playback" disabled causes program to hang (Since 2012C)

Sounds somewhat obscure to me - can you please elaborate? How do I test it?