Synthesia Talk

They do by default. A little logo in the bottom corner and a little bumper at the end to tell about it. Example. (Man, that old, 2000's-era cell phone ringtone DLS synth sounds terrible...)

I never like forcing that kind of stuff on people, so it's easy to disable in the UI. I'm not sure I've ever seen either of those elements in a video in the wild. So, who can say how useful it has been?

Still, after 14 years there isn't much mystery as to which app is used to create that style of video. I've seen comments in those YouTube videos along the lines of "hey, can you make a Synthesia of 'song-name-here'?" which is pretty cool as far as brand recognition is concerned, but a little eerie as far as trademark distinctiveness goes.

Nicholas wrote: ↑08-07-20 12:12 am there isn't much mystery as to which app is used to create that style of video.

There isn't much mystery for a Synthesia user. But don't underestimate the mystery for viewers at large.

A few years ago it took me some time to find out about Synthesia, I always watched Peter Plutax's videos and I didn't know they were made using Synthesia...

jimhenry wrote: ↑08-05-20 12:10 amI would now say what happened is that starting with Synthesia 10 you decided that numbering major releases with integers, a practice that only started with Synthesia 9, consumed numbers too quickly. I would characterize each "point one-tenth" release starting with 10.2 as a major release. And you have been releasing those annually toward the end of the year. So I am not telling you anything you aren't already doing, although maybe unconsciously.

I think you do yourself a disservice every time you use the phrase "the upcoming Synthesia 11 release." It makes it sound like that is the next major milestone. I think it would be better to have the mindset that 10.7 is the upcoming release that is the next major milestone.

When you want to talk about features that will arrive with the use of MusicXML files in Synthesia 11, perhaps you should omit "upcoming" which has a whiff of sometime not too far off.

I'd answered the follow-up email fifty times before unifying on "upcoming".

Me: "That will be in Synthesia 11."
Them: "Oh, where can I download Synthesia 11?"

The future tense "will be" never seemed to matter. Whiffs or not, "upcoming" is the technically correct expression for the sake of auto-translator software and all the language barriers the official communication has to surmount, so it makes the most sense.

Point taken.

This doesn't look like much, but there are some important differences vs. the last six months. Those little bumps weren't there before! I was able to squeeze in more actual-development work in October than every month since the start of the pandemic combined. About half of it was new impositions: Apple broke MIDI in iOS 14, Kurzweil thinks sending more Note Ons than Note Offs is a good idea, Apple deprecates half their APIs every time they release something and then demands that you update to the latest before you are allowed to submit app updates, etc.

The other half of the bumps are useful work:

1. The translations hadn't been brought up to date since 10.5... except for a manual correction here-and-there submitted by a user, or a whole new language contributed by a user (at some along the evolving state of the app). Figuring out which strings were missing in which languages, sorting out how the App Store listings need to be updated after 8 years with new features, and getting the raw, rough files from the translation service ($1,200 later ) integrated correctly into the app took more time than I expected. But it's done now and everything is caught up the way it should be.

2. Down stems are close. The renderer knows how to draw them just as pixel perfect as up stems now. It can beam them. The flags (or tails) are interesting because they tuck under the note, which means the stems on chords can get really long and kind of unsightly. The music font we're using has "short" flag variations for those cases and I'm thinking about using them when the stem gets ridiculous. Finally, when up- and down-stemmed notes happen on the same beat, they need to be pushed apart a little so they don't look like some yin/yang or figure eight thing. Lots of little details!

So we've got a combination of "new forced work" coming in and the phenomenon I described in the top post about this not being a perfect metric: a task list line that says "make sure X still works [after change Y]" might take 5 minutes. But a task list line like "Down stems" might take 50 hours. Progress on the graph is not linear. It looks flat for October, but the gears were turning again.

With any luck, 10.7 might go out the door in November. Hopefully.

If you need help with Italian I can help with that, I contributed to a lot of open source projects with localization during the years for free.

I have been developing software for over 40 years on various platforms, mostly Windows, but tinkered with mobile devices and did firmware in my early days. I think estimates are fine as long as no one takes them seriously. My current job, which I have been at for several years, requires releases at specific intervals. We start out "feature boxed" meaning that we are going to stay in development mode with some potential instability until the features are done or we get too close and then we switch to being "time boxed". Certain features have to make it because of regulation changes. But lists never really seem to get smaller, just prioritized and some stuff gets put off until next time and some stuff stays on the list "for consideration" or "when we have some free time", meaning we just aren't telling whoever asked for it that it will never get done.

I did a little side project for someone in Java that was for a small specialized MIDI controller. The front end ran on Windows, Apple and Linux with no changes. I used an Arduino and C++ on the Arduino for the controller end of things. But it was just messing around with the serial data; nothing to do with the sonic end of things or notation. Since you have been on Apple products so long, I am guessing Objective C and some kind of UI layer that makes things look really similar everywhere. I have had your Android product a few years and only recently got it on Windows also. I was surprised to find it is almost identical. Very nice app; I hope it is rewarding for you.

reachdabeach wrote: ↑01-19-21 10:22 pmSince you have been on Apple products so long, I am guessing Objective C and some kind of UI layer that makes things look really similar everywhere.

That's a good guess, but Synthesia was on Windows first by about a year before Mac. Even then, the old Carbon APIs were less scary at the time than all that new-fangled Cocoa stuff. So, historically I've treated Obj-C as a platform-specific language (the way Java is for Android) and slowly built my homebrew cross-platform framework by avoiding anything that wasn't explicitly shareable.

Here are the GitHub language statistics:


Java was above 5% a couple weeks ago and it was a victory to shave a few hundred lines off (replacing it with ~20 lines in C++). Now if only I could do that for the rest of the Java code!

I miss C++ sometimes. I tinker in Arduino and one of my kids had to use C++ in college a few years ago. He joked that it was the first time since 3rd grade that I could help him with his homework. But professionally I have been immersed in c# and SQL the last several years. I wrote C/C++ for a number of years before that. I cut my teeth on bits and bytes in assembly and liked being able to drop into disassembled code and see what the processor was actually doing when weird things were happening. You get objects and inheritance but still control memory management. Objects went away when you wanted them to and the destructors were always called when they did. I have never trusted garbage control in the newer languages.

I would say I don't know beans about Java, but that's actually all I know. I did all my Java in NetBeans and don't know the ins and outs of all the files and folders required to do the simplest thing. I actually wrote a pretty complex app, but it's just Googling for what calls to make and writing logic in syntax that is still mostly the same old C style, operators and keywords. The Android stuff I did was in an app called AIDE that actually runs on the phone and you log into it from a terminal session on your desktop. It was a similar IDE that took care of details for you.

The one major redeeming value for Java was that a MIDI based app was 100% portable between Windows, Linux and Mac. I had to jump through hoops packaging it for Mac but the pain was mostly about getting the right JVM and libraries there. Even the MIDI library was exactly the same. But it was CC and Sysex messages. I was working on a little device that cached banks of presets so it could be mapped to controls in different environments and make settings portable. It worked and the guy who hired me used it but never found the market he thought he would.

I may tinker with making another device one of these days. Or I may choose not to look at another line of code after another 3 years or so and just become a freelance music producer with no clients instead of retiring.

Are there any hopes for a boomwhacker labeling in version 11? Even if the Do Re Mi labels could change colors to match the boomwhacker system. This would be amazing and I believe it would really attract a lot of users.

Yes, actually. I've got "Pitch-based color!" on line 660 of the Synthesia 11 task list at the moment. The plan was to include a few different color schemes including something along the lines of the Boomwhackers Full Spectrum set.

For a few months now things have been going smoothly and I've been quietly knocking the number down, reasonably steadily.

This little bump is one of those rare occasions where the number increased. It's not actually an increase in workload. This is another one of those "this isn't the perfect metric... but it's a metric" situations. All I did was break the single "Load MusicXML in the simplest possible way" line down into ~14 separate steps ("Parse key signatures", "Detect tempo changes", etc.)

And I was even starting to whittle them down. I've got a "Frere Jacques.musicxml" file that loads and plays correctly in Synthesia!

But then my wife was suddenly hospitalized for a week. She's home now but there is some aftercare that I help with and she isn't allowed to lift over 8 lbs for the next six weeks, so I'm on 100% childcare duties with a 5- and 2-year old. It's been a dramatic schedule (and priority) shift, but we're starting to figure it out. (I was getting ~3 hours of sleep and losing a pound a day while she was in the hospital.)

Still, if things are a little slower--just as they were starting to pick back up --that is the explanation.

Best wishes to your wife for a speedy and complete recovery!

And congratulations on getting "Frere Jacques.musicxml" to load and play. I'm sure that was a real "Come here Watson" moment for you.

It's been baby steps, for sure. That song happens to be monophonic with every note playing directly after one another with no rests, which makes it a particularly easy case. A few minutes ago I just saw one of my test files load correctly with chords and silent time between notes, which was almost as exciting again.

Because this is a classic computer science data transformation task (nothing subjective, no UI, no nonsense), I get to be delightfully meticulous. I'm using red/green testing for every step, which should lead to a robust test suite if nothing else.

In the first decade it was pretty routine to accidentally break the MIDI loading code without realizing it for a release or two. Now, with every MusicXML loading situation covered by a separate test case, that almost shouldn't be possible. And this method will extend to the sheet music nicely once the extra information starts getting pulled all the way through to that layer, too.

The only trouble is the seemingly infinite variability to be found inside MusicXML files. With MIDI, once you cover all 16 possible event types, there's literally no other possible combinations of bits available to express anything else. With MusicXML, the documentation has exception after exception for the dozens of ways any particular thing might be represented. And every few years they add more with the next release. (MusicXML 4.0 was released last month with ~30 new elements/attributes!)

With MIDI, once you cover all 16 possible event types, there's literally no other possible combinations of bits available to express anything else.

The MMA will probably manage to trash that concept with MIDI 2.0.

Nicholas wrote: ↑07-28-21 12:32 pm
In the first decade it was pretty routine to accidentally break the MIDI loading code without realizing it for a release or two. Now, with every MusicXML loading situation covered by a separate test case, that almost shouldn't be possible. And this method will extend to the sheet music nicely once the extra information starts getting pulled all the way through to that layer, too.

The only trouble is the seemingly infinite variability to be found inside MusicXML files. With MIDI, once you cover all 16 possible event types, there's literally no other possible combinations of bits available to express anything else. With MusicXML, the documentation has exception after exception for the dozens of ways any particular thing might be represented. And every few years they add more with the next release. (MusicXML 4.0 was released last month with ~30 new elements/attributes!)

Based on this, there may be a place for hybrid MIDI/MusicXML importing, like Piano Marvel is doing (as mentioned in the MusicXML thread). If MusicXML's primary role is better sheet music but it's hard to parse for playing, then it might be a shortcut to leave the playing part as is with MIDI and just parse MusicXML for notation. It's not a burden (at least initially) to export 2 versions of the song from the same source in notation software.

JimNYC wrote: ↑08-08-21 10:37 amIf [...] it's hard to parse for playing, then it might be a shortcut to leave the playing part as is with MIDI and just parse MusicXML for notation.

I was mostly bellyaching. The documentation is surprisingly good/usable and the amount that doesn't overlap between parsing for playing vs. parsing for sheet music is small.

There are a lot of corner cases, but I knew there would be going in. The most recent example: Most MusicXML files appear to use the "partwise" layout, which means there is a "part-list" that has some metadata (name, instrument, midi-channel, overall volume multiplier, etc.) for each part. Then the rest of the file is a series of "part" elements with an ID that corresponds to an entry from that first list. Each "part" contains a list of "measure", which in turn contains the rest.

Because a "part" seemed to be distinguished by instrument and MIDI channel, it falls very naturally into the same slot as a "track" in a MIDI file. And I have been happily treating it like a MIDI track this entire time, until I got to the "parse multiple parts" test on my list. In MuseScore, I told it to give me like seven piano staffs, plunked some random notes down, exported as MusicXML, and tried to read it in Synthesia.

The file only contains one part.

Instead, (inside score-partwise > part > measure) each "note" has a new child element included like "<staff>4</staff>".

So now Synthesia has to contend with two ways to get something like a MIDI track: multiple parts or a single part that refers to multiple (arbitrarily numbered) staffs. I wouldn't be surprised to find a third eventually. There are subtleties beyond that, too: how do you treat a grand staff? Is that just one "track"? (Given piano music's propensity to use a separate staff for each hand, it should probably still be considered two for Synthesia's sake... but that doesn't mean I haven't had to spend time thinking about it!)

And "partwise" isn't the only layout. There is a "timewise" layout that re-organizes everything so the list of "measure" elements are at the top level, where each contains a complete list of what each part does during that measure. (I still haven't seen one of those in the wild yet.) So that's another variation the code will need to handle.

All of the above impacts both playing and rendering sheet music, so there wouldn't be any savings in this case to try to only do one or the other, unfortunately. This is just one of those things I have to slog my way through.

OK, that's interesting to hear. I don't know enough about the structural intricacies to comment specifically, but having dealt with similar data complexities, I would prioritize "theoretical" from "best-practice". I think many users (myself included) would be thrilled with initial support for standard grand staff (LH & RH) piano music as a starting point. In that sense, if there was an expectation on how those need to be setup in various notation software apps, then it shifts some of the burden to the file prep rather than getting bogged down with the daunting task of trying to support every possibility.