Support for "black" midi file
Support for "black" midi file
This is where all discussion related to the playback of "impossible" or "black" midi files should go.
Re: Support for "black" midi file
New test version:
https://dl.dropboxusercontent.com/u/173 ... t2012R.rar
I have been testing various schemes for handling very large files lately. I haven't yet come up with a satisfying solution, but I think I am close to a fairly good compromise in this test version.
It is still limited to no more than 256 tracks, but apart from that, it is much less memory conservative than before. I have too little memory on my computer for a real acid test, but I think the 4 GB that this version can access ought to be enough for a large number of files. Someday soon I need to purchase some more RAM, but not now. I don't want to touch the inside of my development PC right now. (When Windows 10 becomes standard I anyway need to by a new one).
I've tried to fix a number of reported flaws as well, but probably introduced a set of new ones. I guess I will learn more soon. One very big change I've made in order to accommodate larger files is to discard the "NOTE OFF" events. This saves a lot of memory as every NOTE ON comes with a NOTE OFF event. I don't keep them in memory but convert the pair into a single value for the length of the note. Hence, in the Events list you will not see any NOTE OFF events. I plan to "artificially" reproduce them though in the list, mainly because I think it is useful in order to see what else happens between the start of the note and the end of it.
This is not best I can do, but I may need to fix an approach in order to have something to release in the near future.
https://dl.dropboxusercontent.com/u/173 ... t2012R.rar
I have been testing various schemes for handling very large files lately. I haven't yet come up with a satisfying solution, but I think I am close to a fairly good compromise in this test version.
It is still limited to no more than 256 tracks, but apart from that, it is much less memory conservative than before. I have too little memory on my computer for a real acid test, but I think the 4 GB that this version can access ought to be enough for a large number of files. Someday soon I need to purchase some more RAM, but not now. I don't want to touch the inside of my development PC right now. (When Windows 10 becomes standard I anyway need to by a new one).
I've tried to fix a number of reported flaws as well, but probably introduced a set of new ones. I guess I will learn more soon. One very big change I've made in order to accommodate larger files is to discard the "NOTE OFF" events. This saves a lot of memory as every NOTE ON comes with a NOTE OFF event. I don't keep them in memory but convert the pair into a single value for the length of the note. Hence, in the Events list you will not see any NOTE OFF events. I plan to "artificially" reproduce them though in the list, mainly because I think it is useful in order to see what else happens between the start of the note and the end of it.
This is not best I can do, but I may need to fix an approach in order to have something to release in the near future.
Re: Support for "black" midi file
I used this new test version R to work a big band arrangement of Doin' Basie's Thing. Nope lol not a "black" midi file by any means... but i did do a number of midi event edits and track layering along with using sound fonts and a couple of VSTI instruments and VST effects.
My focus was to get the midi file into an arrangement and then render to an MP3 all within Synthfont 2... there was no attempt to run the test version R through all its functionality, new technicalities or anything like that..... Sooooo I just went through my usual workflow stuff as i would any arrangement.
Except for one tiny cosmetic thing.... I had no problems or glitches of any kind..... whatever was done for note off events seems to have worked just fine ... the MP3 using high quality VBR and Max audio leveling also worked just fine and in fact sounds so very close to playing the song via the applications Track List... ( which is not always the case.... sometimes i hear things in the MP3 not apparent when playing via the application).
So for a Vanilla base test.... with a lot of tracks and tweaks and balancing and sound sources.... I am pleased... ( LOl... whatever thats worth!)
ohhhhhhhhh nearly forgot... the tiny cosmetic thing.....
In the Track List.... the values shown in the midi channel column aren't centered in the column and appear all left justified ! Seems the values should be centered in the column.
Thanks for the test version Kenneth.....![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Cheers to all on the forum.... except the spammers of course!
Chasp
My focus was to get the midi file into an arrangement and then render to an MP3 all within Synthfont 2... there was no attempt to run the test version R through all its functionality, new technicalities or anything like that..... Sooooo I just went through my usual workflow stuff as i would any arrangement.
Except for one tiny cosmetic thing.... I had no problems or glitches of any kind..... whatever was done for note off events seems to have worked just fine ... the MP3 using high quality VBR and Max audio leveling also worked just fine and in fact sounds so very close to playing the song via the applications Track List... ( which is not always the case.... sometimes i hear things in the MP3 not apparent when playing via the application).
So for a Vanilla base test.... with a lot of tracks and tweaks and balancing and sound sources.... I am pleased... ( LOl... whatever thats worth!)
ohhhhhhhhh nearly forgot... the tiny cosmetic thing.....
In the Track List.... the values shown in the midi channel column aren't centered in the column and appear all left justified ! Seems the values should be centered in the column.
Thanks for the test version Kenneth.....
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Cheers to all on the forum.... except the spammers of course!
Chasp
Re: Support for "black" midi file
Thanks Chasp!
As you may have guessed already, removing the NOTE OFF entries from the event streams had a number of side effects - mostly positive, when correctly handled in the code. For example, moving notes around is code-wise a lot easier now when I only need to move one event around in the stream.
Version R may seem slow to start up at times. This is one of the two things I need to fix before finalizing the release version. (The other thing is the display of the "virtual" note off events in the Midi Events list).
As you may have guessed already, removing the NOTE OFF entries from the event streams had a number of side effects - mostly positive, when correctly handled in the code. For example, moving notes around is code-wise a lot easier now when I only need to move one event around in the stream.
Version R may seem slow to start up at times. This is one of the two things I need to fix before finalizing the release version. (The other thing is the display of the "virtual" note off events in the Midi Events list).
Re: Support for "black" midi file
Interesting thing I noticed in the Piano Roll...
I don't know if this is a new thing.. but i never noticed it before and it seems pretty useful !
If one highlights an event in the Midi Event list.... then switches to the Piano Roll..... the highlighted note event is also highlighted in the Piano Roll.
I'm not so sure about controller events.... my new arrangement has Expression controller events... for which there is nothing that shows for that event ( or any EXPRESSION controller event) in the Piano Roll. (Wouldn't mind seeing Expression values in the Track List however since it an often searched for entry to try to find out where volume changes on notes or groups of notes are coming from)!
chasp
I don't know if this is a new thing.. but i never noticed it before and it seems pretty useful !
If one highlights an event in the Midi Event list.... then switches to the Piano Roll..... the highlighted note event is also highlighted in the Piano Roll.
I'm not so sure about controller events.... my new arrangement has Expression controller events... for which there is nothing that shows for that event ( or any EXPRESSION controller event) in the Piano Roll. (Wouldn't mind seeing Expression values in the Track List however since it an often searched for entry to try to find out where volume changes on notes or groups of notes are coming from)!
chasp
Re: 2.0.1.2 "R"
Thanks for the update Kenneth.
What has changed in this build is very nice, and memory usage has indeed dropped by about half. However this release did bring along a lot of deal-breaking bugs too in which I have found very easily.
I actually didn't end up transferring my SynthFont licence information into this secondary laptop yet and the trial expired when I had the chance to test version R. I have found another situation where the "Error" occurs again; when I have the "Trial expired" message and I go to input licence information, I close the window to "cancel" and just as it closes, I see the "Error - Send error report" window pop up for half a second then closes along with synthfont itself. You need to implement a way to prevent that error window from closing on it's own so the user has a chance to intervene and send hit "Send error report" and the report makes it to you. I have since activated my licence on this laptop so I can use and test version R out.
Anyway, here's my list of bugs that I have just discovered while testing 2012R, all of which appear to be new to "R" except for the first two:
To be honest, I doubt I will see myself upgrading to windows 10 over Windows 7 any time soon. I don't see any appeal in Windows 8, but I don't see any appeal in 10 either. One of the main reasons being, it looks like Microsoft is not planning on fixing the MIDI lag problem very time soon.
Basically in Windows 8, MIDI performance got much worse performance than what XP and 7 has, especially when playing back Black MIDI files, just google "Black MIDI Windows 7 vs 8" and you will see what I mean. I haven't had the time to test whether SynthFont was affected by this or not but I sorta doubt it because I don't think SynthFont relys on the Windows MIDI Mapper system or whatever causes this issue. As far as your development PC goes, I don't know its specs but assuming you only have 4GB on it now, why don't you just consider just upgrading it to 6GB instead of going higher? That should still make a difference and not cost too much.
Lastly, I have noticed you have fixed the Player Piano mode's update rate limit. While in many ways it's nice to see this fixed, I sort of liked the old behavior too, so perhaps you could add a flag/option to use the old player piano limiting, but this is low priority (I could always use the older version whenever I want to take advantage of it). Basically, the update rate emulated how it would look/sound if I were to play the MIDI on my old keyboard without exceeding polyphony, which I found useful along with another bug ** which I didn't bother to report yet.
**: When using MIDI Output mode combined with the older Player Piano, and things that cause thread takeover such as piano roll and continuously scrolling "MIDI Events" during playback, the MIDI output also delays the sending of MIDI Data. I didn't report this earlier because I found the impact to be very trivial and I in fact found it as an enhancement rather than an inconvenience in this following special/odd situation: In combination of old player piano's "limiting bug" and this bug, I found that this has allowed me to output MIDIs to my keyboard/piano without exceeding polyphony and causing the piano to glitch.
What has changed in this build is very nice, and memory usage has indeed dropped by about half. However this release did bring along a lot of deal-breaking bugs too in which I have found very easily.
I actually didn't end up transferring my SynthFont licence information into this secondary laptop yet and the trial expired when I had the chance to test version R. I have found another situation where the "Error" occurs again; when I have the "Trial expired" message and I go to input licence information, I close the window to "cancel" and just as it closes, I see the "Error - Send error report" window pop up for half a second then closes along with synthfont itself. You need to implement a way to prevent that error window from closing on it's own so the user has a chance to intervene and send hit "Send error report" and the report makes it to you. I have since activated my licence on this laptop so I can use and test version R out.
Anyway, here's my list of bugs that I have just discovered while testing 2012R, all of which appear to be new to "R" except for the first two:
- 2011 - Attempting to hit close while song is preparing data for playback will cause program to hang (Since 2.0.1.1)
- 2012Q - MIDI Input mode does not recieve any notes (Since 2.0.1.2Q)
- 2012R - Songs take twice as long to "prepare data for playback"
- 2012R - When using the Z-Doc Grand Piano soundfont, playing to file with "Max peak" selected causes the file to not be saved properly: instead as a loud/distorted file with .raw on it
- 2012R - Switching between large soundfonts during speaker playback causes wait cursor to remain until playback is stopped
- 2012R - Switching between voice limit settings during speaker playback can cause program to hang, especially with long decaying soundfonts
- 2012R - Certain stereo soundfonts do not render properly (Eg. SGM_V2.01, ZDoc Grand Piano.sf2)
- 2012R - Memory leak, each time a song is stopped and re-played, memory usage keeps going up. For example with that 32 million note MIDI I've tested before and now can play in full, there is an additional 200MB of memory usage every time the song is stopped and played
To be honest, I doubt I will see myself upgrading to windows 10 over Windows 7 any time soon. I don't see any appeal in Windows 8, but I don't see any appeal in 10 either. One of the main reasons being, it looks like Microsoft is not planning on fixing the MIDI lag problem very time soon.
Basically in Windows 8, MIDI performance got much worse performance than what XP and 7 has, especially when playing back Black MIDI files, just google "Black MIDI Windows 7 vs 8" and you will see what I mean. I haven't had the time to test whether SynthFont was affected by this or not but I sorta doubt it because I don't think SynthFont relys on the Windows MIDI Mapper system or whatever causes this issue. As far as your development PC goes, I don't know its specs but assuming you only have 4GB on it now, why don't you just consider just upgrading it to 6GB instead of going higher? That should still make a difference and not cost too much.
Lastly, I have noticed you have fixed the Player Piano mode's update rate limit. While in many ways it's nice to see this fixed, I sort of liked the old behavior too, so perhaps you could add a flag/option to use the old player piano limiting, but this is low priority (I could always use the older version whenever I want to take advantage of it). Basically, the update rate emulated how it would look/sound if I were to play the MIDI on my old keyboard without exceeding polyphony, which I found useful along with another bug ** which I didn't bother to report yet.
**: When using MIDI Output mode combined with the older Player Piano, and things that cause thread takeover such as piano roll and continuously scrolling "MIDI Events" during playback, the MIDI output also delays the sending of MIDI Data. I didn't report this earlier because I found the impact to be very trivial and I in fact found it as an enhancement rather than an inconvenience in this following special/odd situation: In combination of old player piano's "limiting bug" and this bug, I found that this has allowed me to output MIDIs to my keyboard/piano without exceeding polyphony and causing the piano to glitch.
Re: Support for "black" midi file
Here's the next iteration:
https://dl.dropboxusercontent.com/u/173 ... t2012S.rar
This has been fixed:
1) The Events list now shows Note Off events (virtual, that is) also.
2) TRIED to address the issue "Attempting to hit close while song is preparing data for playback...". OK, pressing "Exit" does still not work, but you can at least stop preparing for playback by hitting the "Stop playing" button.
3) Fixed "MIDI Input mode does not recieve any notes".
4) Fixed "Songs take twice as long to "prepare data for playback"". Still takes somewhat longer than before, but not twice the amount.
5) TRIED to fix the "When using the Z-Doc Grand Piano soundfont..." problem.
6) "Switching between voice limit settings during speaker playback ..." - not allowed right now. On hold.
7) "Certain stereo soundfonts do not render properly" - fixed
8) At least one Memory leak found and fixed.
I think I will have to leave the "Player Piano mode's update rate limit" question until a later version.
Right now I must focus on the most serious issues.
Thanks for any comments!
https://dl.dropboxusercontent.com/u/173 ... t2012S.rar
This has been fixed:
1) The Events list now shows Note Off events (virtual, that is) also.
2) TRIED to address the issue "Attempting to hit close while song is preparing data for playback...". OK, pressing "Exit" does still not work, but you can at least stop preparing for playback by hitting the "Stop playing" button.
3) Fixed "MIDI Input mode does not recieve any notes".
4) Fixed "Songs take twice as long to "prepare data for playback"". Still takes somewhat longer than before, but not twice the amount.
5) TRIED to fix the "When using the Z-Doc Grand Piano soundfont..." problem.
6) "Switching between voice limit settings during speaker playback ..." - not allowed right now. On hold.
7) "Certain stereo soundfonts do not render properly" - fixed
8) At least one Memory leak found and fixed.
I think I will have to leave the "Player Piano mode's update rate limit" question until a later version.
Right now I must focus on the most serious issues.
Thanks for any comments!
Re: 2.0.1.2 "S"
Pretty good, however I've discovered two new bugs in this new build right off the bat:
Lastly, I've created a topic on the Un4Seen forums to see if developers behind the bassmidi.dll backend could improve it to further improve performance with VirtualMIDISynth, and it turns out they've more than doubled MIDI performance by re-organizing (velocity?) zones for faster access (reduce the time required to find samples to play) and therefore reducing raw event processing overhead. Could something like this be done to SynthFont to improve rendering speed?
- Stereo soundfonts may have an oddly long and inconsistent decay time, specifically with SGM_V2.01.sf2
- Stereo soundfonts can cause odd stereo imaging in note decay. I've composed a simple test MIDI file that seems to really showoff this bug, especially with soundfonts like JV1080_Nice_Piano_m.sf2 and SGM_V2.01.sf2:
Lastly, I've created a topic on the Un4Seen forums to see if developers behind the bassmidi.dll backend could improve it to further improve performance with VirtualMIDISynth, and it turns out they've more than doubled MIDI performance by re-organizing (velocity?) zones for faster access (reduce the time required to find samples to play) and therefore reducing raw event processing overhead. Could something like this be done to SynthFont to improve rendering speed?
Last edited by ray890 on Fri Apr 24, 2015 3:49 pm, edited 1 time in total.
Re: Support for "black" midi file
Thanks Ray
Reorganizing velocity zones (or any other zones for that matter) will not have much of an impact on the rendering speed in SynthFont as all zones are simply scanned and added to the voice pool when the note is initiated. After that everything is only equal to pointers to records in memory space. However, there are SoundFonts with up to 500 zones, and scanning these to find the right one(s) may take some time, but not much.
The only real challenge to undertake next is to convert the rendering engine into assembler code. That will certainly give a edge to it. It is a project for later on.
The live input mode will not be much improved in the near future. I will continue to refer people to SyFonOne if this is a critical subject (I might consider building SyFonOne into SynthFont2, actually). Anyway, this feature is not very high up on my list of to-do items.
Reorganizing velocity zones (or any other zones for that matter) will not have much of an impact on the rendering speed in SynthFont as all zones are simply scanned and added to the voice pool when the note is initiated. After that everything is only equal to pointers to records in memory space. However, there are SoundFonts with up to 500 zones, and scanning these to find the right one(s) may take some time, but not much.
The only real challenge to undertake next is to convert the rendering engine into assembler code. That will certainly give a edge to it. It is a project for later on.
The live input mode will not be much improved in the near future. I will continue to refer people to SyFonOne if this is a critical subject (I might consider building SyFonOne into SynthFont2, actually). Anyway, this feature is not very high up on my list of to-do items.
Re: Support for "black" midi file
Next version:
https://dl.dropboxusercontent.com/u/173 ... t2012T.rar
- You can now exit the program while in preparation for playback
- Fixed that stereo sound glitch during note decay (this was one really silly bug)
- Removed some redundant code and tests which probably slowed down playback somewhat.
All in all, I think (like to -) that this is now very fast approaching a release (will be called 2.0.2.0).
https://dl.dropboxusercontent.com/u/173 ... t2012T.rar
- You can now exit the program while in preparation for playback
- Fixed that stereo sound glitch during note decay (this was one really silly bug)
- Removed some redundant code and tests which probably slowed down playback somewhat.
All in all, I think (like to -) that this is now very fast approaching a release (will be called 2.0.2.0).