New test version

[Elven Spellmaker]

Hi Kenneth,

Is there any reason why opening a MIDI file forces Tab 4 Plug & Play to become the active tab? This has been the case since I started using SynthFont, but is annoying for when I want to open a new file and be on the Piano Roll straight away!

[Admin]

Originally it wasn't so. I will turn back the time. Soon.

[TheTrustedComputer]

If you are prepared to do some more testing, I will happily provide you with a registration code. Send me an email.

Well, I don't know your email btw. You can send to me it at rtm518443@gmail.com nonetheless. This email is my primary email I use everyday. All other emails are my backup emails. That means I will not reply to those emails regardless.

I will probably NEVER have support for all 100+ MIDI controller events partly because many of them lacks a clear specification, for example, what would you expect Breath (#2 for coarse level) or Effect #1 (#12, coarse) to do? I am all ears.

There is a full list of MIDI CC (Continuous Controller) events online. Only a handful of them are never used nor defined in such way, like CC event 3 and CC event 9. The flip side of this is that there are plenty of them which are straightforward CC events. For example, CC 70 through 79 has very good explanations/descriptions on what it does to the sound. Only CC 70-74 are specifically defined. The rest can be anything a company could do. Another straightforward CC event is CC 65, which controls portamento (pitch sliding of disconnected notes); CC 84 controls how long the portamento will slide to the new note. So yeah, there is SOMETHING you can do and code at least some straightforward events. There are some requiring Googling as some terms may look unfamiliar to you.

Here's some memory refreshers:
http://nickfever.com/music/midi-cc-list
http://electronicmusic.wikia.com/wiki/C ... controller
http://www.ccarh.org/courses/253/handout/controllers/

[ray890]

9 bugs down, 10 new bugs discovered, here they are, starting with the ones introduced in 2.0.2.0E:

• Audio artifacts are heard inside of Virtual Keys and MIDI Input modes
• Initiating MIDI Input mode while selected MIDI Input device is already playing notes can cause program to crash
• Reading of foreign MIDI Events in MIDI Input can cause "Access Violation" errors (Eg. Beginning of MIDI files, click+dragging Piano From Above's seek bar)
• Producing notes rapidly in Virtual Keys can cause notes to stop producing and the program to hang
• "Auto" voice limit takes the role of "No Limit" and is selected by default every time a MIDI file is loaded
• Voice limit option "No limit" produces no voices at all
• Tracks containing tempo changes are being deleted even when selecting "No" or "x" in the warning window (Since 2.0.1.1)
• MIDI Input channels defaults to MIDI-Program specified by the MIDI file loaded in SynthFont (Since 2.0.1.1)
• MIDI Program Change messages sent through MIDI Input mode changes Program settings in the SynthFont arrangement (Since 2.0.1.2P)
• Piano From Above's "MIDI Panic" messages aren't being honored in MIDI Input mode, causing buildup of infinitely sustained notes when seeking (Since 2.0.1.2S)

Now, expanding on the part about the MIDI Input, this version has gone backwards in terms of polling frequency in both the MIDI Input and virtual keys (Reverted to <=2.0.2.0C's), I for example thought the polling frequency was very well good enough for Virtual Keys. For MIDI Input however, I expect a polling frequency of about 300 even though even higher would be better (600-1200?), but I don't think SynFonOne even had any or at least such a low polling frequency in the first place.

There is still infinitely sustained notes with MIDI Input on 2.0.2.0E, but again the reason why that happens is the same as why notes are not picked up/produced when playing more than 25 notes per second; MIDI Data is skipped if the poller is unable to catch it within it's frequency. This is why my current idea is to queue all MIDI Data that cannot be processed in time within the polling frequency limits to all executed as soon as possible, if that makes sense to you. SynFonOne didn't have a noticeably low polling polling frequency if any at all, therefore I got no infinitely sustained nor missing notes. I don't see the SynFonOne engine separating MIDI Input from Virtual Keys' as being a requirement anymore as long as polling issues are fixed.


Actually, the "Clicking virtual keys twice cause notes to start releasing while being held down" issue hasn't been fixed yet, but I should make it clear that notes should be double clicked and then held down on the same note to get the notes to release early when held down.

And lastly the external MIDI device hanging issue, it occurs during moments when I attempt to initiate a MIDI Output port while the specific output port is already in use, in this case it should say "Could not open MIDI port" like it does in 2.0.1.2U and older.

[Admin]

I am very well aware of the standard definitions of all CC events, but how I ought to implement them is another question. Take Breath as an example : "Often times associated with aftertouch messages. It was originally intended for use with a breath MIDI controller in which blowing harder produced higher MIDI control values. It can be used for modulation as well." So what would YOU expect Breath to do?

A quick correction to my comment about midi in polling frequency: midi-in events are sent to SynthFont using a callback function and immediately stored in a buffer. So, nothing is lost. However, this buffer is only analyzed for its contents each time the audio output (playback) buffer has been filled up and sent to the audio output. Thus, the frequency of polling the midi buffer depends on the size of the playback buffer, which you can set in Setup. The smaller values will be better, of course. Usually ASIO will let you use a buffer of 1000 samples or less, which lets the engine empty the midi buffer 44 times per second (at 44100 Hz). I can easily double this rate, but in previous tests for SyFonOne nothing was gained. But maybe I should look again?

[Admin]

Here's the next version:
https://dl.dropboxusercontent.com/u/173 ... t2020F.rar

- Audio artifacts are heard inside of Virtual Keys and MIDI Input modes. - Hmm. I'm not sure about this one.
- Initiating MIDI Input mode while selected MIDI Input device is already playing notes can cause program to crash - fixed
- Reading of foreign MIDI Events in MIDI Input can cause "Access Violation" errors - ??
- Producing notes rapidly in Virtual Keys can cause notes to stop producing and the program to hang - cannot reproduce.
- "Auto" voice limit takes the role of "No Limit" and is selected by default every time a MIDI file is loaded - OK, Auto wasn't even supposed to be there, it was for my own testing only (I didn't mention it in my post). Removed. It's a feature for later.
- Tracks containing tempo changes are being deleted even when selecting "No" or "x" in the warning window - fixed. Cancel button added.
- MIDI Input channels defaults to MIDI-Program specified by the MIDI file loaded in SynthFont - (?) I think I've got that one.
- MIDI Program Change messages sent through MIDI Input mode changes Program settings in the SynthFont arrangement - (?) I think I've got that one also.
- Piano From Above's "MIDI Panic" messages aren't being honored in MIDI Input mode - I guess it is the All Notes Off message that wasn't honored. it is now. Please try again.
- Clicking virtual keys twice cause notes to start releasing while being held down - fixed (again)

- I cannot make SynthFont2 crash when opening MIDI input or output that seems to be in use. I'll leave that for later.

- There is a new checkbox in the toolbar above tracks list. It's called Poll512. If you check it, the internal MIDI input array will be perused each and ever time 512 samples have been created. if not, the array will be analyzed only every time the whole playback buffer has been filled up. Do yo hear any difference between these two methods?

[ray890]

Thus, the frequency of polling the midi buffer depends on the size of the playback buffer, which you can set in Setup.

WOW, I totally missed the bottom section of the I/O page in the setup and options panel after all this time of testing! The Samples/Buffer option, I've reduced it from 3072 to 1024, and it made a pretty big difference in midi-input pickup rate, even though I still don't think it's enough. Even SyFonOne has a better "pickup rate" than even synthfont's current 1024 samples/buffer results. I'm assuming syfonone may still have the limited pickup rate effect, but I cannot measure this due to the polyphony limiter and the lack of being able to route output through another MIDI OUT device.

On the other hand, MIDITrail's (open source) MIDI Input engine seems to have zero pickup-rate limiting (only limited by the input device itself) at all as well as no (noticeable at least?) input latency. This is starting to make me think the solution is to internally separate MIDI Input from the synth itself to accomplish this.

Here's the next version

In 2.0.2.0F, MIDI Input has been greatly improved it seems, other than "pickup rate". Not only am I seeing "All Notes Off" working again, but now it seems to be no longer discarding (I think) and infinitely sustaining higher volumes of notes randomly. Also, the "access violation" bug has been fixed in this version too (probably thanks to the error reports I sent with 'E')

As for the MIDI IN program changes, these bugs are not fixed yet, but heres a situation you can try to reproduce them:

In SynthFont, open up a MIDI file that has multiple tracks and instruments, as well as opening a multi-track MIDI file with a different set of instruments in another MIDI player where program change messages are only executed at the beginning of the file. Cue playback in the MIDI player being output with a Loopback port, and while the song is playing (after program messages were already sent), enter MIDI In mode, and you will hear the MIDI file play with the instruments used in the file loaded in Synthfont (rather than all program 000 as I'm assuming that's the expected result).
Now, cue the playback in the MIDI file to the beginning of the MIDI in the MIDI player so the Program Change message will execute, and you'll hear the proper instruments of that MIDI file heard within the synthfont-midi-in synth. Now, exit MIDI In mode, and you will notice that the instrument sets changed by the MIDI Player has carried over and changed the instrument settings in your synthfont arrangement.


As for the producing notes with virtual keys rapidly bug, I found that this same thing happens with MIDI Input, so in that case I'd say experiment with keeping MIDI Input mode active for a while, while sending notes to it, perhaps at a higher volume and with program changes, then doing things in between, eventually the sound should stop working, the interface will stop reacting other than the exit midi in mode which will keep several buttons grayed out, and synthfont will refuse to close. This seems to happen at random, there seems to be no exact trick to getting this to happen.
On the other hand, with Virtual Keys this should happen after dragging your mouse back and forth rapidly for long enough of a while to produce lots of notes at once, preferably with an instument other than the standard grand piano, and eventually the audio will stop and hang.

Audio artifacts are still heard with both the MIDI IN mode and Virtual Keys, as well as a custom non-44khz sample rate is not applying itself at program launch-time (despite being shown as selected in the list) until re-selected.

Now, for the "Attempting to initialize external MIDI OUT device that doesn't work causes the program's interface to turn white and hang" bug, I've done the following to re-produce this bug:
1. Have VirtualMIDISynth 2 Alpha installed and set up and tested to ensure working state from the official forum topic:
2. Open another MIDI Player and tell it to play a MIDI, outputting to "VirtualMIDISynth #1" to cause the port to be in-use/busy
3. With SynthFont, play a midi, telling it to output to MIDI Out device "VirtualMIDISynth #1"
4. After the coolsoft-produced "Device VirtualMIDISynth #1 is already in use by process [...]" message comes up press OK
5. SynthFont's interface will turn white and hang, instead of producing a "Could not open MIDI port" message like 2.0.1.2U and earlier did

[Admin]

Well, I have VirtualMIDISynth 1.13.2 installed and it doesn't behave as you describe. I can have two programs (maybe even more) playing to the same single port at the same time. Maybe there is a bug in "2 Alpha"?

Have you had a chance to test the Poll512 function?

SyFonOne doesn't poll the buffer more than once every playback buffer fill. So, in theory, version 2.0.2.0E should do better with Poll512 checked.
I could easily make it check the input buffer even more often, say every 256th sample or so.

It is possible to make the MIDI input engine respond virtually immediately to any input, but this would require a rather drastic change of the code structure. I will at a suitable moment look into it for SyFonOne. For now, I will not make any major changes to the current structure in SynthFont2, except from possibly increasing the poll rate as mentioned above.

[ray890]

Right.. I knew I was missing SOMETHING from my previous post. Yes, I've tried the Poll512 function, and it does nothing to the "pickup rate", it's still the same, the only difference I get with Poll512 enabled is that it introduces constant static noise to the audio, nothing else.


VirtualMIDISynth1 has a workaround to the "Only one application can use one port" issue, as you can see represented by more than one coolsoft icon on the taskbar if you have multiple programs requesting the VMS1 port. However, VMS2 has yet to implement such functionality and I was already aware of that.

To put this in to more practical terms, this also means when I put my USB piano's synth into use by another MIDI program and I tell synthfont to initialize the port synthfont also turns white and hangs. This only happens with 2.0.1.2V and newer. Basically, the problem here is that synthfont turns white and hangs instead of producing the "Could not open MIDI Port" error message like it's supposed to.


While I'm here, I also found 3 more bugs:
- MIDI OUT devices do not work at all with MIDI IN mode
- Soundfonts cannot be changed while in MIDI IN mode (Since 2.0.2.0E)
- Synth volume activity bar does not update in real time in MIDI IN mode (Since 2.0.2.0E)

Also, is it possible for you to get your Voice Limiter engine to favor eliminating voices by lowest velocity, un-held, and/or simply the oldest of voices, without adding much of a CPU overhead? Also, I think it'd be nice to have a checkbox in the "Play to file" dialog to "Ignore voice limit setting" and have it checked by default (aka. an option to force no voice limit).

[mike]

I also got another bug:
So since a few versions changing the MIDI channel at the "MIDI events" tab doesn't work (greyed out) anymore.
I don't actually use it very frequently but it would nice to fix it again so I don't need to fall back to SF1.