Notes are not cut short - if you not explicitly ask to have them (overlapping ones). I played it in my development environment with a breakpoint in the cut-short function. It never got there. What you may have experienced is that the latest version has the faster SoundBlaster-type of note release decay function. Version "G" has still to original, long one.
I'm considering putting that original one back, but keeping the SoundBlaster one as the default.
New test version
Re: New test version
- Inconsistent sample rate pitch issue, I tried changing the Pitch Shifting method, first I tried changing from STD to PPS, no difference, then I tried PPX mode and it still has the same pitch issue
- MIDI Input stall, Hmm, it could be a matter of that you didn't scrub/hold the seek bar backwards enough or something, and I'm assuming you already made sure its being looped back to SF. This issue seems to be very MIDI specific, some MIDIs produce no "GetSFOverride not found" errors, some produce a few, then there are those (specially like RED_ZONE_Portamento.mid) that produce so many of those errors that the entire audio thread can freeze when cuing/seeking the file rapidly. This bug only started to occur starting with 2.0.2.0E and newer, since you introduced the synfonone engine which introduced 5 other midi-in bugs you've already fixed. Here's another video of this occurring in a slightly different view: https://drive.google.com/open?id=0B2mBT ... nRTMkdId0k
- Overlapping behavior, Yeah, I admit I rushed with the overlapping video, I had a bunch of recorded footage that I actually cut out to make it shorter, without thinking about the soundfont change. Here's a much better video which actually shows what I mean and what I used to test with: Video, and midi used. SynthFont reproduces the equivalent of "overlapped same voce" checked regardless of whether "Do Nothing", "Previous note turns off", or "Previous note cut short". However, MIDI Input mode seems to reproduce the "Previous note turns off" behavior that I was imagining and seems to be the MIDI Standard I think (PS. Coolsoft also uses that form of "previous note turns off" behavior by default). However, if this is not the behavior you intended in the first place, then it's fine.
- MIDI Input stall, Hmm, it could be a matter of that you didn't scrub/hold the seek bar backwards enough or something, and I'm assuming you already made sure its being looped back to SF. This issue seems to be very MIDI specific, some MIDIs produce no "GetSFOverride not found" errors, some produce a few, then there are those (specially like RED_ZONE_Portamento.mid) that produce so many of those errors that the entire audio thread can freeze when cuing/seeking the file rapidly. This bug only started to occur starting with 2.0.2.0E and newer, since you introduced the synfonone engine which introduced 5 other midi-in bugs you've already fixed. Here's another video of this occurring in a slightly different view: https://drive.google.com/open?id=0B2mBT ... nRTMkdId0k
- Overlapping behavior, Yeah, I admit I rushed with the overlapping video, I had a bunch of recorded footage that I actually cut out to make it shorter, without thinking about the soundfont change. Here's a much better video which actually shows what I mean and what I used to test with: Video, and midi used. SynthFont reproduces the equivalent of "overlapped same voce" checked regardless of whether "Do Nothing", "Previous note turns off", or "Previous note cut short". However, MIDI Input mode seems to reproduce the "Previous note turns off" behavior that I was imagining and seems to be the MIDI Standard I think (PS. Coolsoft also uses that form of "previous note turns off" behavior by default). However, if this is not the behavior you intended in the first place, then it's fine.
-
KaleidonKep99
- Posts: 14
- Joined: Tue Mar 17, 2015 7:42 pm
Re: New test version
I tried version "G", and the problem still appears.Admin wrote:Notes are not cut short - if you not explicitly ask to have them (overlapping ones). I played it in my development environment with a breakpoint in the cut-short function. It never got there. What you may have experienced is that the latest version has the faster SoundBlaster-type of note release decay function. Version "G" has still to original, long one.
I'm considering putting that original one back, but keeping the SoundBlaster one as the default.
The soundfont used is my new release, the Keppy's Steinway Piano 2.9. (This problem happens with the default GM soundfont too)
Demo: https://mega.nz/#!INNQRDRT!LtLe6PYLxM4S ... bUYu-Hvc7o
Re: New test version
Here is version "K": https://dl.dropboxusercontent.com/u/173 ... t2020K.rar
@KaleidonKepp99: I think that what you have heard is a flaw in how Pedal Hold was implemented. I have fixed that now.
@Ray890:
- Inconsistent sample rate pitch issue. Hmm, I do not totally agree. Have a listen to the files in this archive. https://dl.dropboxusercontent.com/u/173 ... _tests.rar There are three files there, 1) ...(8000) which is created by SynthFont2 at 8000 Hz using the standard pitch shift method, 2) ... (8000 PP) is created using the Perfect Pitch method, and 3) which is created from a 41000Hz version (done in SynthFont2) and resampled down to 8000Hz in my audio editor. There is clearly a difference between 1) and 2) while the difference between 2) and 3) is very small.
- MIDI Input stall. Yes, of course I was playing to SynthFont2! Would I cheat?
- Overlapping behavior. I think you are wrong. Look at this image:
At the bottom is the audio output for the first few beats of track #3 (I muted track #4) with "do nothing" for overlaps. At the top is the output for "cut short" overlaps. In the middle is the difference between these two. Here you can see the tails which are cut away by the "cut short" method. Hence, the method works, It is great if you cannot actually hear the difference! Then I can say that the method works perfectly. Here are the audio files.
@KaleidonKepp99: I think that what you have heard is a flaw in how Pedal Hold was implemented. I have fixed that now.
@Ray890:
- Inconsistent sample rate pitch issue. Hmm, I do not totally agree. Have a listen to the files in this archive. https://dl.dropboxusercontent.com/u/173 ... _tests.rar There are three files there, 1) ...(8000) which is created by SynthFont2 at 8000 Hz using the standard pitch shift method, 2) ... (8000 PP) is created using the Perfect Pitch method, and 3) which is created from a 41000Hz version (done in SynthFont2) and resampled down to 8000Hz in my audio editor. There is clearly a difference between 1) and 2) while the difference between 2) and 3) is very small.
- MIDI Input stall. Yes, of course I was playing to SynthFont2! Would I cheat?
- Overlapping behavior. I think you are wrong. Look at this image:
At the bottom is the audio output for the first few beats of track #3 (I muted track #4) with "do nothing" for overlaps. At the top is the output for "cut short" overlaps. In the middle is the difference between these two. Here you can see the tails which are cut away by the "cut short" method. Hence, the method works, It is great if you cannot actually hear the difference! Then I can say that the method works perfectly. Here are the audio files.
Re: New test version
- While Original SynthFont volume curve was re-added to 2.0.2.0K, I noticed that this option is selected by default instead of the Soundblaster curve
- Pitch issue: Right, (8000) has the harsh sound to the audio as expected compared to the two wavs, but I am still hearing the pitch issue when comparing the two other files. Listen again, and you should notice while "(44100 to 8000)" sounds proper and musical, but in "(8000 PP)" the pitch is not normal and rather sounds like the instrument is dying.
- MIDI Input stall: Hmm, I'm still getting that bug in 2.0.2.0K. I use LoopMIDI as my loopback cable software, I have found that this same bug happens with LoopBe30 (trial) too. I will try and see if I can reproduce this with another PC tomorrow when I have the chance.
- Pitch issue: Right, (8000) has the harsh sound to the audio as expected compared to the two wavs, but I am still hearing the pitch issue when comparing the two other files. Listen again, and you should notice while "(44100 to 8000)" sounds proper and musical, but in "(8000 PP)" the pitch is not normal and rather sounds like the instrument is dying.
- MIDI Input stall: Hmm, I'm still getting that bug in 2.0.2.0K. I use LoopMIDI as my loopback cable software, I have found that this same bug happens with LoopBe30 (trial) too. I will try and see if I can reproduce this with another PC tomorrow when I have the chance.
Re: New test version
I use loopmidi too. It better than any of the others.
The pitch issue at 8000hz is not that obvious. It is also of minor importance so I will not focus on it right now. I need to get version 2.0.2.0 out next week as I will be on a longer vacation after that with only sporadic opportunities to do any serious work.
The pitch issue at 8000hz is not that obvious. It is also of minor importance so I will not focus on it right now. I need to get version 2.0.2.0 out next week as I will be on a longer vacation after that with only sporadic opportunities to do any serious work.
Re: New test version
Ray890, let's focus a little bit on that MIDI IN stall problem you have.
Here is a version that writes out some additional info to DBWIN32:
https://dl.dropboxusercontent.com/u/173 ... t2020L.rar
It spells out the time it takes to find a preset for each channel. This is the process that seems to stall on your PC. But we will see.
Additionally, when you have ended the MIDI IN session it will write out the longest time the MIDI_IN function has taken to process the received messages. (">> RenderLiveStop MaxMidiInTime=XX ms").
This version also remembers the release decay curve setting, but please note that he value stored in the SynthFont.ini file or the Arrangement is not valid any longer and needs to be updated, for example, by saving the Arrangement.
This version is compiled in my latest Delphi environment, XE7 (I will not upgrade to XE8 soon). XE7 has a number of bug fixes and other changes so I wouldn't exactly be too surprised if you find that "K" behaves differently in some aspect.
Here is a version that writes out some additional info to DBWIN32:
https://dl.dropboxusercontent.com/u/173 ... t2020L.rar
It spells out the time it takes to find a preset for each channel. This is the process that seems to stall on your PC. But we will see.
Additionally, when you have ended the MIDI IN session it will write out the longest time the MIDI_IN function has taken to process the received messages. (">> RenderLiveStop MaxMidiInTime=XX ms").
This version also remembers the release decay curve setting, but please note that he value stored in the SynthFont.ini file or the Arrangement is not valid any longer and needs to be updated, for example, by saving the Arrangement.
This version is compiled in my latest Delphi environment, XE7 (I will not upgrade to XE8 soon). XE7 has a number of bug fixes and other changes so I wouldn't exactly be too surprised if you find that "K" behaves differently in some aspect.
Re: New test version
I've been able to reproduce the audio stalling issue on the 2 other PCs I tested this morning now that I had the time; another Windows 7, and a Windows 8 machine. All I needed to do was grab the PFA seek bar and quickly drag it backwards from end to beginning (or even rapidly back and forth) with that MIDI loaded, and lots of GetSFOverride messages appears,
Upon further testing I found out that the first version I was able to reproduce this issue is with 2.0.1.2P and not 2020E.
- 2.0.1.1 up until 2.0.1.2N seems to still spam GetSFOverride messages in the debugger (at a slightly faster rate I think), but notes remained playable and CPU usage remained low.
- With 2.0.1.2P and newer, the same GetSFOverride messages are being spammed, but CPU usage becomes high and the audio is stalled until the time when the messages are finished being generated in the debugger.
Anyway, here's my output from 2.0.2.0L: http://pastebin.com/B6VzSxgV
Also Version L has brought in three new issues, and I have found four more older bugs:
- The voice and cpu statistic bars do not display their current reading
- Default input/output port list options are highlighted upon entry of the I/O Ports tab of Setup and Options
- The list items on the context menu for selecting MIDI OUT device do not line up properly and doesn't allow the user to re-select none
- Perfect Pitch shifting method only causes one channel to be rendered with stereo soundfonts [older issue, since 2.0.1.2Q]
- The metronome does not work [older issue, since 2.0.1.2Y]
- Producing lots of GetSFOverride errors at once may cause some instruments to become out of tune [such as the guitar in red_zone, older issue]
- Changing sample rate in between ASIO enabled MIDI Input sessions causes change in pitch output [older issue]
Upon further testing I found out that the first version I was able to reproduce this issue is with 2.0.1.2P and not 2020E.
- 2.0.1.1 up until 2.0.1.2N seems to still spam GetSFOverride messages in the debugger (at a slightly faster rate I think), but notes remained playable and CPU usage remained low.
- With 2.0.1.2P and newer, the same GetSFOverride messages are being spammed, but CPU usage becomes high and the audio is stalled until the time when the messages are finished being generated in the debugger.
Anyway, here's my output from 2.0.2.0L: http://pastebin.com/B6VzSxgV
Also Version L has brought in three new issues, and I have found four more older bugs:
- The voice and cpu statistic bars do not display their current reading
- Default input/output port list options are highlighted upon entry of the I/O Ports tab of Setup and Options
- The list items on the context menu for selecting MIDI OUT device do not line up properly and doesn't allow the user to re-select none
- Perfect Pitch shifting method only causes one channel to be rendered with stereo soundfonts [older issue, since 2.0.1.2Q]
- The metronome does not work [older issue, since 2.0.1.2Y]
- Producing lots of GetSFOverride errors at once may cause some instruments to become out of tune [such as the guitar in red_zone, older issue]
- Changing sample rate in between ASIO enabled MIDI Input sessions causes change in pitch output [older issue]
Re: New test version
Version M
The stalling issue: I tested it on another PC today (Windows 8.1). No problems. No hiccups. No delays. So I am pretty lost.
Anyway, version M has streamlined the process of finding a suitable preset. The GetSFOverride function is called only once, for example.
So please run M again with DBWIN32 open and show me the output.
Other issues
- The voice and cpu statistic bars do not display their current reading - Yeah, that's a problem with the default progress bar. I had to resort to a non-standard one to get the readings displayed.
- Default input/output port list options are highlighted upon entry of the I/O Ports tab of Setup and Options. - You are fast to pickup new features without me mentioning them! Now, I have recently made rather large changes to how ports are handled. Previously ports were listed only once, at program startup, so any changes you made while SynthFont was running were not reflected in the ports lists. For example, when using the excellent MIDI loopback by Tobias Erichsen. I find myself adding and deleting ports on the fly quite often:
I can highly recommend this free tool!
- The list items on the context menu for selecting MIDI OUT device do not line up properly and doesn't allow the user to re-select none -Fixed. Reason described above.
- Perfect Pitch shifting method only causes one channel to be rendered with stereo soundfonts - fixed.
- The metronome does not work - fixed.
- Producing lots of GetSFOverride errors at once may cause some instruments to become out of tune [such as the guitar in red_zone, older issue] - What? Which guitar? Which track? I've never noticed any problem with the guitars. please tell me more.
- Changing sample rate in between ASIO enabled MIDI Input sessions causes change in pitch output - Partly fixed. The MIDI IN rendering engine did not pick up the sample rate used by ASIO when initialized. It does so no. What more, it is not allowed to change the sample rate while in MIDI IN mode. I have added some code that checks the ASIO sample rate and sets it back to the original while in MIDI IN mode. I don't know if it works, I couldn't find a way to change the sample rate for ASI04ALL. It must be there. I'm just blind, sometimes. Ideally one should be able to disable this capability in ASIO's control panel (if you can find it).
The stalling issue: I tested it on another PC today (Windows 8.1). No problems. No hiccups. No delays. So I am pretty lost.
Anyway, version M has streamlined the process of finding a suitable preset. The GetSFOverride function is called only once, for example.
So please run M again with DBWIN32 open and show me the output.
Other issues
- The voice and cpu statistic bars do not display their current reading - Yeah, that's a problem with the default progress bar. I had to resort to a non-standard one to get the readings displayed.
- Default input/output port list options are highlighted upon entry of the I/O Ports tab of Setup and Options. - You are fast to pickup new features without me mentioning them! Now, I have recently made rather large changes to how ports are handled. Previously ports were listed only once, at program startup, so any changes you made while SynthFont was running were not reflected in the ports lists. For example, when using the excellent MIDI loopback by Tobias Erichsen. I find myself adding and deleting ports on the fly quite often:
I can highly recommend this free tool!
- The list items on the context menu for selecting MIDI OUT device do not line up properly and doesn't allow the user to re-select none -Fixed. Reason described above.
- Perfect Pitch shifting method only causes one channel to be rendered with stereo soundfonts - fixed.
- The metronome does not work - fixed.
- Producing lots of GetSFOverride errors at once may cause some instruments to become out of tune [such as the guitar in red_zone, older issue] - What? Which guitar? Which track? I've never noticed any problem with the guitars. please tell me more.
- Changing sample rate in between ASIO enabled MIDI Input sessions causes change in pitch output - Partly fixed. The MIDI IN rendering engine did not pick up the sample rate used by ASIO when initialized. It does so no. What more, it is not allowed to change the sample rate while in MIDI IN mode. I have added some code that checks the ASIO sample rate and sets it back to the original while in MIDI IN mode. I don't know if it works, I couldn't find a way to change the sample rate for ASI04ALL. It must be there. I'm just blind, sometimes. Ideally one should be able to disable this capability in ASIO's control panel (if you can find it).
Re: New test version
The stalling issue still seems to be in existence, but now the audio resumes before the debugger messages are finished being generated, but I blame that on the fact that DBWIN is slow at processing/scrolling through console messages.
Here, I've done two output capture runs: One where I grabbed and released the seek bar while in the midi is in playback mode: http://pastebin.com/THN5ERTS , and one while I grabbed the seek bar then pressed play once I released the seek bar near the beginning of the track: http://pastebin.com/Ktg18WHz . For example, with the second example I dragged the seek bar back and forth through beginning and the end three times, and I got 30 seconds of audio stalling, while it still took several minutes to finish writing to the DBWIN log.
And for the out of tune instrument thing, with older versions I just dragged the seekbar backwards to produce a lot of internal GetSFOverride errors in a certain way/pattern, then eventually I get a slightly out of tune electric-guitar or bass-guitar; it may require multiple attempts in order to get this, because it seems like its a specific pattern that does this.
HOWEVER, I found myself unable to reproduce it with the new version so far so I wouldn't have my main focus on this one right now, I'll report back with more information if I can get it to occur again though.
Here, I've done two output capture runs: One where I grabbed and released the seek bar while in the midi is in playback mode: http://pastebin.com/THN5ERTS , and one while I grabbed the seek bar then pressed play once I released the seek bar near the beginning of the track: http://pastebin.com/Ktg18WHz . For example, with the second example I dragged the seek bar back and forth through beginning and the end three times, and I got 30 seconds of audio stalling, while it still took several minutes to finish writing to the DBWIN log.
And for the out of tune instrument thing, with older versions I just dragged the seekbar backwards to produce a lot of internal GetSFOverride errors in a certain way/pattern, then eventually I get a slightly out of tune electric-guitar or bass-guitar; it may require multiple attempts in order to get this, because it seems like its a specific pattern that does this.
HOWEVER, I found myself unable to reproduce it with the new version so far so I wouldn't have my main focus on this one right now, I'll report back with more information if I can get it to occur again though.