10.2 Preview r3659-r3715 - Lots of stuff

Archived development update discussion from past versions
Archived development updates.
Nicholas
Posts: 12035

Post by Nicholas » 07-18-15 5:05 am

PREVIEW r3659
Download from the pink box above.

NEW FEATURES
  • Added several help buttons throughout that launch how-to guides on the Synthesia website.
  • Note labels have been improved: they smoothly scale again and now show with much greater contrast than ever before.
  • Enabled seven more songs in demo mode: one in each category.
  • Added "Song Paused" label while song is paused. If the song was paused while also stopped at a note in melody practice, it could be confusing or frustrating when attempting to play the next note didn't resume the song.
  • Added "Toggle Loop" shortcut (default: /) to enable or disable the current loop. Instead of removing it completely, now you can just turn it off for a while.
  • Added "Custom" option to the zoom menu: remembered between songs (and Free Play) automatically. This is useful when trying to align the keys on your physical keyboard with Synthesia's on-screen keyboard. Custom zoom also disables snapping to whole keys, so you can fine-tune your zoom level.
  • Improved sharpness of falling note graphics when drawn very large.
  • Unlock keys can now be used in Synthesia for Android. Traditionally they were only usable in the desktop versions.
  • Song names now appear in the title bar of the window during play.
  • Interface language choice is now saved for each user profile.
  • The included set of songs are now packaged directly inside the Windows version of Synthesia, to match all our other supported platforms. This should make initial setup easier for users that prefer to download the stand-alone zip Synthesia releases.
  • The included songs are now shown in the song list much more quickly.
  • The Synthesia Configuration tool has been merged into Synthesia. Hold Shift while starting to open the configuration window.
  • The metronome now continues to run during a loop delay.
  • The readme can now be opened from SettingsAdvancedAbout & Legal.
  • You are returned to the same screen used to load a song: if you clicked an entry in the Recent Songs list on the title screen, leaving that song will return you directly to the title screen. Launching a song directly via right-click shortcut or using a synthesia:/ URL will also return you directly to the title screen.
  • Added an asterisk icon to the key and note label popup menu to indicate the recommended/default setting for each.
  • Windows-only Graphics.ScaleOverride advanced option to force a particular DPI scale. Valid ranges are between 1.0 and 2.0.
  • The old Gameplay.AutoShiftToBestOctave option has been promoted and can now be changed inside Synthesia. See: SettingsGameplayKeyboard Octave.
  • The System.SoftwareKeyboardMapping advanced setting now supports Unicode virtual piano mappings.
THINGS THAT HAVE CHANGED
  • Output devices that are enabled but not used for anything are no longer shown on the title screen.
  • The loop delay slider now snaps to beats.
  • Folders are now scanned recursively by default.
  • Synthesia no longer prevents loading MIDI type-2 files.
  • Increased the contrast of song location highlight in sheet music display.
  • Flattened out a few UI elements to follow the modern trend.
  • A few improvements to menu navigation: Show Game Help (default: F1) will also exit the help screen, and Menu Back (default: Esc) will now close any open menus and exit any pause modes (loop, bookmark, finger hints, etc.) the first time, before attempting to exit play the second time.
  • Key lights are now only shown for the entire duration of each note when you're in "Watch and Listen Only" mode. They behave the same as they once did in Synthesia 9 whenever you are playing.
BUGS FIXED
  • Notes at the very beginning of the song now play in subsequent loops.
  • While previewing an individual part in a song with many parts, instruments were sometimes incorrect.
  • In songs with many parts, instruments should be correct more often. Otherwise when a song has more parts than the 16 available MIDI channels, often the only solution to hearing the correct instrument is to mute some of the other parts.
  • Song preview audio no longer hangs when you click the recycle/delete button.
  • Added a workaround for a bug in the Windows 10 MIDI synth that prevents it from being opened within the first few seconds of application launch.
  • The song list now correctly sorts numbers in song titles using natural order. For example, instead of songs being ordered like 1, 10, 100, 11, 2, they will show as 1, 2, 10, 11, 100 now.
  • The icon shown for "Fiddle" is now actually a fiddle instead of the generic synth icon.
  • Free play now shows notes from triple-sensor keyboards (where more Note On events arrive before all the Note Offs) correctly.
  • Dramatically increased the speed of key spark effect calculations. Particles should now have a much smaller impact on frame rate.
  • Songs can no longer be shown more than once in the song list, regardless of which combination of folders are being watched.
  • Interacting with the falling notes (e.g., creating bookmarks, setting finger hints, adjusting loops) now tracks the mouse cursor correctly while paused during a loop delay.
  • The sheet music resize bar now always extends to the right side of the screen.
  • Synthesia now recovers gracefully from reading corrupt/locked settings.
  • Walk Entire Loop Forward (default: >) and Walk Entire Loop Backward (default: <) now work when there isn't already a loop, in a song that contains a bookmark at the very beginning.
  • The Windows version of Synthesia is now more responsive while running in the background when drawing using DirectX.
  • Prevent crash while loading songs with extremely "wide" measures. (Or: Synthesia can now handle 82/4 time signatures.)
  • Instruments can now be changed more reliably while previewing a part.
  • Removed the button that launched a browser to view recital scores. Recitals are no longer tracked on the Synthesia website for technical reasons. (Look forward to an improved system coming in Synthesia 12.)
  • OS X should no longer show "Folder Missing!" for the built-in song list.
KNOWN ISSUES
  • Microsoft broke their MIDI synth in Windows 10. Once disabled, it will never re-enable until you close and re-open Synthesia. If you make device changes (unplugging/replugging, changing settings, etc.) this bug will cause your Microsoft synth to stop. Just restart Synthesia.
  • I'd love to hear from any Mac OS X 10.7 users that are still out there. All 0.4% of you. I've already heard a report that this crashes at startup for at least one 10.7 user (while I've seen it work on 10.6 and 10.10). Without going to eBay and buying an old Mac that still has 10.7 on it, there isn't a great way to test Apple's older OSes.
  • Slowing the song down to 0% speed causes a crash.
  • The new recursive-by-default folder scanning can (more readily) find the internal MIDI files inside Synthesia.app on Mac. This has always been possible, but now it's more likely.
  • When trying to move files to Trash in the Mac version, all files are incorrectly detected as read-only.
All of that (except the known issues) is straight out of the readme, where it's actually formatted a little more nicely.

For a "small feature-polish" release, this one certainly accumulated a lot of changes! The only real coherent theme in that list is tackling all those little inconveniences that have been bugging users for years. Lots more happened under the hood, too. Some major code quality strides that prepare Synthesia for better things. Hopefully everything feels pretty good.

This is feature complete. After a bit more wrap-up and testing (from you guys and on the tablet side of things), 10.2 will be ready to go out the door and the largest of the Few Small Projects will be complete. Combine that with my having found a bit of help for both the website and the guide work, and things are moving right along! You guys might actually see MusicXML support some day! :lol:

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-18-15 1:43 pm

Is there a TestFlight for iPad?
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

Nicholas
Posts: 12035

Post by Nicholas » 07-18-15 3:15 pm

Not yet. One of Apple's new rules this year is that you must now submit your iOS apps compiled in both 32-bit and 64-bit mode. Rebuilding all our libraries in 64-bit mode (and fixing any hiccups) is part of the "wrap-up and testing [...] on the tablet side of things" that I still have to do. They won't even let you push it to beta without meeting that requirement.

rumpole
Posts: 24

Post by rumpole » 07-19-15 5:38 am

Hello Nicholas,

1:A small problem: Under r3659 the falling black keys do not stand out under one or more of the colours available. Green is particularly poor, and the two letters (e.g.:Ab) are too small for the space provided. The main and large letters (notes) are visually and splendidly improved. The quicker the mind registers/interprets the falling note, the faster and more consistent the speed of play;

2: How do I reduce/make smaller the big blue bar (above the green bar). It takes up soooooooooooo much screen space considering the buttons (back help, etc.) of the blue bar are not constantly used. I would rather have the extra screen space.

Many thanks,

Frank

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-19-15 12:17 pm

Windows version.

When sending the Music Output to the keyboard there is some MIDI control message sent right at the moment the first note is played. On my keyboard it sounded like a volume change but I think it is an instrument change because it was not affected by the Note Loudness setting. On my keyboard that can cause a burst of noise depending on the relative timing of playing the first note to when it should be played. It can be startling just at a moment when you don't want to be startled. My guess is that whatever setup is being done at about the time of the first note needs to be backed up to happen earlier.
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-19-15 1:41 pm

I have confirmed that there is a Program Change that coincides with the first note. I see that there is also a Program Change at the very start of the song. My keyboard seems to ignore it. I am guessing because it is too soon after the Reset Control. If I remember correctly, there is no standard for how quickly a MIDI instrument responds to the resets and it can be some meaningful amount of time.

It looks like you are fighting issues of trying to support a lot of possibilities for how the MIDI Output device handles initialization. Even if I let Synthesia play the first note so that it is after the Program Change by a very brief time, my keyboard mangles the initial attack of the note. I think you have to put some time between a Program Change and a following note. I think you also should avoid a Program Change while a note is playing.

Should a Program Change be sent on the My Notes channel if it is Off? I would say no.
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

onewingedmoogle
Posts: 3

Post by onewingedmoogle » 07-21-15 3:27 am

So does this mean we won't have to pay again on android devices now if we already have a desktop key?

Nicholas
Posts: 12035

Post by Nicholas » 07-21-15 12:56 pm

rumpole wrote:Under r3659 the falling black keys do not stand out under one or more of the colours available.
Hmm, the higher-resolution note graphics probably had a small effect on the colors. Sorry! I'll try to get those matching a little more closely. (I vaguely remember raising the brightness a bit to increase the contrast with the all-black labels.)
rumpole wrote:The two letters (e.g.:Ab) are too small for the space provided.
This gets even worse with three letter labels (Sol). You can mitigate it a bit by zooming in to fewer keys horizontally.
rumpole wrote:How do I reduce/make smaller the big blue bar...
Open the configuration window (hold Shift when starting Synthesia) and turn off the "Gameplay.PinMenuDrawerOpen" setting. That should improve things a lot!
jimhenry wrote:I see that there is also a Program Change at the very start of the song. My keyboard seems to ignore it.
Is this a regression from a previous version? Or is this something that may have existed before? As far back as I can remember, Synthesia has always sent the beginning-of-song controller messages immediately after the reset. From the very first 0.4.0 release back in 2006. If you use the same diagnostics to check an older version (say, 10.1) does it also cause the problem?
onewingedmoogle wrote:So does this mean we won't have to pay again on android devices now if we already have a desktop key?
Correct. :D

(I'm hoping to get the Android beta up soon, so you'll be able to try it out.)

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-21-15 2:46 pm

Nicholas wrote:
jimhenry wrote:I see that there is also a Program Change at the very start of the song. My keyboard seems to ignore it.
Is this a regression from a previous version? Or is this something that may have existed before? As far back as I can remember, Synthesia has always sent the beginning-of-song controller messages immediately after the reset. From the very first 0.4.0 release back in 2006. If you use the same diagnostics to check an older version (say, 10.1) does it also cause the problem?
Ignoring the first group of PCs at the beginning of the song is not a problem because of the second group of PCs that coincide with the first note. I think the real question is why are the PCs sent twice? For my keyboard, the first group is too early to do anything and the second group creates a sound artifact because of being late. However, my guess is the arrangement of the PCs is an ad hoc solution to past problem reports. I'd want to remember why they are the way they are before making any changes.
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

qazxsw21000
Posts: 39
Location: London, KY

Post by qazxsw21000 » 07-21-15 3:36 pm

Uppercase letters get priority over lowercase letters and it throws me off. Some of my MIDI files start with uppercase letters and the other most of them start with lower case. I don't know if it has to do with this:
The song list now correctly sorts numbers in song titles using natural order. For example, instead of songs being ordered like 1, 10, 100, 11, 2, they will show as 1, 2, 10, 11, 100 now.
But "Z" gets listed before "a" and it feels very unnatural.

Nicholas
Posts: 12035

Post by Nicholas » 07-21-15 3:41 pm

Ha! That isn't very "natural" at all. I apologize. What a startling omission on my part. That should definitely be case-insensitive still. I'll get that fixed in the next preview.

rumpole
Posts: 24

Post by rumpole » 07-22-15 12:29 am

Hi, Nicholas,

Thank you for the tip to minimize the "blue bar". It works.

As to the issue of the reduced legibility of the black key notes (r3659), your suggestion to use the zoom to enlarge the black keys, to my mind, does not really address the problem, for many pieces require the entire 88note board.

If you stand r3293 next to a window of r3659 you will see that the black notes of r3293 actually expand beyond the perimeter/confines of the colour, and thereby make the black, say #A,bB, easier to identify, BECAUSE THEY ARE LARGER. The smaller lettering of the black key notes may be the real culprit here.

Many thanks. Keep up the good work. Your "invention of Sythesia" gives much pleasure.

Frank Kullenberg

Birdman87
Posts: 60

Post by Birdman87 » 07-22-15 8:59 am

I agree with rumpole, the fact that the letters on the black notes is smaller makes it significantly more difficult to read. And i'm not sure about the black color of the letters either, when the notes move very fast i still find it a bit difficult to focus my eyes, that black or whatever color needs to be contrasted by a letter border or something.

Nicholas
Posts: 12035

Post by Nicholas » 07-23-15 5:58 am

jimhenry wrote:However, my guess is the arrangement of the PCs is an ad hoc solution to past problem reports. I'd want to remember why they are the way they are before making any changes.
This was a fun bit of investigation.

Commit message from Dec-2007: "Fixed first note of 'You Play' track sometimes not using correct instrument."

Commit message from Oct-2012: "Include events from the same pulse as the next note when updating to first note. (bugid#401)"

Code comment from same Oct commit: "Important messages are often sent during the same pulse as the first note (though still ahead of it). So we peek right up to the note, but then only update until right before it. This can lead one pulses' worth of duplicated state changes. Not a big deal."

Bug ID #401 (1009 days ago): "Instrument change was getting sent after NoteOn (because melody stops just before the note pulse that was sharing a Program Change, and changing the instrument from not-defined to 0 on AUSampler cuts off audio)."

The "AUSampler" bit at the end is what the iPad's synth is called internally. So there is the answer. It was definitely to fix a device-specific bug. What's happening is any non-note events get sent right at song start (without "consuming" them), so then the song still plays the usual way (repeating that first batch of events).

Now the question is how do we fix your case? If the right-after-reset events don't do anything, and sending them when they're supposed to be sent causes trouble... when is the right time to send them? Force an artificial delay after device reset before events are allowed to be sent? How long a delay?
rumpole wrote:The smaller lettering of the black key notes may be the real culprit here...
Birdman87 wrote:... the fact that the letters on the black notes is smaller makes it significantly more difficult to read.
This is just a mock-up, but how does this strike you two?
LargerAndMoreContrast.png
LargerAndMoreContrast.png (13.63 KiB) Viewed 18324 times
Perhaps the best answer of all is that you should both get larger monitors! :lol:
Birdman87 wrote:... when the notes move very fast i still find it a bit difficult to focus my eyes...
This is actually a problem with LCD screens. Dramatic color changes take much longer than subtle ones. This is where you hear terms like "ghosting" or "smearing". So whenever you've got something high-contrast that is moving, you end up with that hard-to-focus effect. The falling note labels in Synthesia are essentially the worst possible case for LCD monitors. :?

Birdman87
Posts: 60

Post by Birdman87 » 07-23-15 11:41 am

Lol, i have a 27 inch monitor but it's wayy harder to read on that since it's huge and the note seem to move a lot faster so i have to either make synthesia small or i just use my laptop screen :P

And to answer your question, even though the second picture is significantly uglier, it looks easier to read, think you could include that in the synthesia config?

Nicholas
Posts: 12035

Post by Nicholas » 07-23-15 1:07 pm

Birdman87 wrote:... even though the second picture is significantly uglier...
Agreed! :lol:

Though, really, I am more interested in usability than looking fancy. Synthesia is a serious learning tool; not just eye candy. (I'll leave the eye candy to the upcoming video creator.)

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-23-15 3:02 pm

Nicholas wrote:
jimhenry wrote:However, my guess is the arrangement of the PCs is an ad hoc solution to past problem reports. I'd want to remember why they are the way they are before making any changes.
This was a fun bit of investigation.

Commit message from Dec-2007: "Fixed first note of 'You Play' track sometimes not using correct instrument."

Commit message from Oct-2012: "Include events from the same pulse as the next note when updating to first note. (bugid#401)"

Code comment from same Oct commit: "Important messages are often sent during the same pulse as the first note (though still ahead of it). So we peek right up to the note, but then only update until right before it. This can lead one pulses' worth of duplicated state changes. Not a big deal."

Bug ID #401 (1009 days ago): "Instrument change was getting sent after NoteOn (because melody stops just before the note pulse that was sharing a Program Change, and changing the instrument from not-defined to 0 on AUSampler cuts off audio)."

The "AUSampler" bit at the end is what the iPad's synth is called internally. So there is the answer. It was definitely to fix a device-specific bug. What's happening is any non-note events get sent right at song start (without "consuming" them), so then the song still plays the usual way (repeating that first batch of events).

Now the question is how do we fix your case? If the right-after-reset events don't do anything, and sending them when they're supposed to be sent causes trouble... when is the right time to send them? Force an artificial delay after device reset before events are allowed to be sent? How long a delay?
Now that I see more clearly what is going on, which is we have a MIDI file that has Program Changes and Notes On all at time 0, I'd like to say that is just a poorly formed MIDI file. But this is part of the library that is included with Synthesia and it is probably a common practice as well.

I gather from the above that Synthesia "collects" the non-note events that occur up to the time of the first note and sends duplicates of those events during the initialization prior to playing the song.

I think it is important to recognize that this whole initialization is an artificial Synthesia created preface to the MIDI file. I think this shows the possibilities for this preface:

[resets] ... [non-note events from MIDI file] [metronome setup] ... [metronome count-in] [MIDI file]

It also important to recognize that it takes a non-trivial amount of time for things to happen in a MIDI device and to send a MIDI message, especially over a legacy MIDI cable. That's why a Program Change and a Note On at essentially the same time in a MIDI file is dicey.

There probably needs to be a delay at each point where there is ellipsis in the above layout of the Synthesia preface. My guess would be 500 mSec. after the resets and 100 mSec. after the other setup events. But these are good things to put in the advanced configuration in case those guesses are wrong.
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

Nicholas
Posts: 12035

Post by Nicholas » 07-23-15 3:27 pm

Looking at the platform-specific implementations for Synthesia's MIDI library, it looks like OS X gets about a 300ms delay after reset and Windows is between 50 to 150ms depending on which of the "Midi.Reset*" advanced settings are enabled.

Those waits are done on a separate thread that will happily queue incoming MIDI events until the wait is finished. So, it should be safe to bump the Windows delay up to 350ms or so (to keep it a little conservative). That should at least let the first collected set of events execute on your device a little more reliably.

The real trouble comes when that first set of events also contains a SysEx "GM Reset" message at the beginning of the song. Then you're in for another device re-initialization. (Even better are the poor songs where the overzealous MIDI editing software inserts something like 20 of those resets right at time=0.)

User avatar
jimhenry
Posts: 1758
Location: Southern California

Post by jimhenry » 07-23-15 7:12 pm

I didn't actually look at what non-note events were in the Fur Elise (Easy) MIDI file. Are you saying that all of the preface represents non-note events that Synthesia is duplicating before starting the song to try to ameliorate bad MIDI files that put non-note events at the same point in time as the first note event?

I am starting to think that the right solution is to read and consume all the non-note MIDI events that precede the first note event and play those non-note events "out of time" with delays added after reset events and a final delay added after the last non-note event to allow the MIDI synthesizer to settle before playing the first Note event in time.

If you don't consume the reset events, then they will still bollix up many MIDI synths if they are received immediately followed by a Note event, even if there was an identical reset shortly before, because the synth may not recognize anything while it is resetting.

If you don't consume the program change events, I think they can still produce a sound artifact by restarting the ADSR envelope even if the instrument stays the same.

An issue that we seem to have lost sight of is whether a Program Change or any other non-note event should be sent on the My Notes channel if it is Off? While it could be cool to have the MIDI file change instruments for you, if those PCs are right at the start of a note then the result isn't going to be nice if you play the note a bit early.
Jim Henry
Author of the Miditzer, a free virtual theatre pipe organ
http://www.VirtualOrgan.com/

rumpole
Posts: 24

Post by rumpole » 07-23-15 8:19 pm

Hello Nicholas,

Further to the conundrum of the black keys' lack of legibility, the picture to the right of your arrow is easier for the brain to identify, because the "Ab" letters are larger because they expand beyond the parameters of the space allocated.

The larger "Ab" is thus about the same size as the full note lettering. Hence the easier readability at speed.

Perhaps we should go back to r3293. It seems perfect by comparison.

Birdman uses a large monitor. Ditto here (23"). Too large a monitor (42") causes other problems. Not recommended.

Apologies for wasting so much of your time on this issue.

Regards,

Frank

Locked