The end of Finale

[Bach5G]

An email from the makers of Finale:

Today, we have important news to share with you regarding the future of Finale. Effective immediately, we are announcing these changes to the Finale software:

There will be no further development on Finale, or any of its associated tools (PrintMusic, Notepad, Songwriter)
It is no longer possible to purchase or upgrade Finale in the MakeMusic eStore

Finale will continue to work on devices where it is currently installed (barring OS changes)

[hyperbolica]

I moved from Finale to Musescore. You don't have to use the site to use the software, and the software is free. I like it well enough. It works for what I do.

[Dennis]

An email from the makers of Finale:

Today, we have important news to share with you regarding the future of Finale. Effective immediately, we are announcing these changes to the Finale software:

There will be no further development on Finale, or any of its associated tools (PrintMusic, Notepad, Songwriter)
It is no longer possible to purchase or upgrade Finale in the MakeMusic eStore

Finale will continue to work on devices where it is currently installed (barring OS changes)

If this was April 1 I'd be suspicious, but as far as I know there is no August Fool's Day.

This will make a lot of music publishers very unhappy if they had no advance warning. It will be interesting to see what they move to--MusicXML, maybe?

[Bach5G]

An email from the makers of Finale:

Today, we have important news to share with you regarding the future of Finale. Effective immediately, we are announcing these changes to the Finale software:

There will be no further development on Finale, or any of its associated tools (PrintMusic, Notepad, Songwriter)
It is no longer possible to purchase or upgrade Finale in the MakeMusic eStore

Finale will continue to work on devices where it is currently installed (barring OS changes)

This will make a lot of music publishers very unhappy if they had no advance warning. It will be interesting to see what they move to--MusicXML, maybe?

Dorico.

[Digidog]

WTF!!

This is devastating news for me, since my entire body of work is edited and formatted in Finale. I have been a Finale user for almost 30 years, and though this termination from a business perspective probably has a logic, I deem it a reprehensive letdown and treachery - almost on a personal level.

This goes to show that practical operation, use and needs means nothing to financial accounts and greedy profiteers. It wouldn't have taken much investment to keep the software up to date as a useful tool for a small group of users, in a waning market and business segment.

Now I can only hope for some other software to be retro compatible and as versatile. For a while I have been wondering when the next updates would come....

D@mn it! Dam^ it! )amn it!

(Insert complementary four letter words of choice here: ;as an illustration of how pi$$ed I am.)

[Matt K]

Really disapppintimg they aren’t open sourcing it. It wouldn’t necessarily cost them anything to do that and others would be happy to pick up the torch unburdened by legal repercussions for doing so

[Bach5G]

I suppose it would cut into their Dorico sales.

I glanced at the Dorico offerings. They look fine.

[Matt K]

Is Dorico related? I thought they were completely different companies, even accounting for the assortment of parent companies involved

[dbwhitaker]

If you take the company's announcement at face value it seems unlikely that open sourcing it would lead to useful support or enhancements. If the company that originally developed it finds it too unwieldy to maintain I don't think volunteers are going to have the resources to do it.

Screenshot 2024-08-27 at 7.06.17 AM.png

[cmcslide]

Best thing to do right now is to create PDF's of all of your Finale files to preserve the formatting. Finale files can also be exported to MusicXML, which can be opened in other notation software, though there will be formatting issues. Obviously MakeMusic (makers of Finale) have a business arrangement with Steinberg, makers of Dorico, since they have a pretty competitive cross grade price.

[JohnL]

Hopefully MakeMusic will work with Steinberg (Dorico) to add an import filter to allow Dorico to open Finale files. Not holding my breath.

[Matt K]

It wouldn't have to be "volunteers" per se. There are a lot of instances of much more complicated software stacks being made available, such as to the Apache foundation, which pays developers to maintain software or other models where there are open licenses (which includes MuseScore). Millions of lines of code isn't necessarily indicative of complexity, nor is it the ultimate measure of its utility as even if there was never sufficient interest to compile and take-over the project, it would allow contributors to make, for example, a converter from Finale files to existing formats like MuseXML.

[mwpfoot]

There's a "limited time" teaser price on Dorico for Finale users, $150 I think? I'll be doing that.

Loooong time Finale user but man am I tired of all the nudging bumping fixing fitting. It took as long to format GOOD parts as it did to arrange!

I'm cautiously optimistic to be forced to be done with it, if that makes sense.

[Digidog]

Hopefully MakeMusic will work with Steinberg (Dorica) to add an import filter to allow Dorica to open Finale files. Not holding my breath.

I'd very surprised if they spent as much as a dime and a second on backwards compatability. To make for compatability is often complicated and adding a lot of code to the already existing programming, opening up for many glitches and bugs.

Fortunately I have all my notation work in PDF:s but that is a meagre solace, since I often use the Finale files as templates for new scores. To create new global chord adaptations, new articulation measurement settings, new note spacing settings, new typefont positionings and new sound maps for the various ensembles - is not what I look forward to.

Well: It was to be expected; software has a lifespan and for Finale this was it. I still think they could have prepared and treated us users much, much better!

The question is now: Which has the best viability, the longest life expectancy, Dorico or Sibelius?

[JohnL]

I'd very surprised if they spent as much as a dime and a second on backwards compatability. To make for compatability is often complicated and adding a lot of code to the already existing programming, opening up for many glitches and bugs.

If it was a matter of MakeMusic providing a service/feature for the benefit of the users that they're in the process of abandoning, I'd agree. There'd nothing in it for them. But there is something in it for Steinberg/Dorico, in the form of many thousands of soon-to-be abandoned Finale customers who will be having to choose between Dorico and Sibelius.

[Matt K]

Dorico would be expected to support it as well, potentially for a long time, and may not have exact feature parity with everything Finale has done over the last 30 years. If it was a separate organization (something like this would likely not be a huge stretch if the code were available), writing even a simple command line converter to take a final file and convert it to, say, music XML automatically shouldn't be hard if there isn't an expectation of support.

[SteveM]

Doesn't Finale already export to MusicXML?

[Matt K]

You have to have a running version of Finale, and they’re going to turn off the activation server next year. So yes; but it’s not a permanent solution.

[harrisonreed]

Finale kind of ... Wasn't that good, though, right? They finally realized there was no further development that could be done on something that hasn't changed since the 1700s. Dorico and Sibelius 100%

[JohnL]

The latest:

Dear valued Finale customer,

Earlier this week, we announced the end of development on Finale. Based on your feedback, we have these important updates to our original announcement:

Finale authorization will remain available indefinitely

We've heard your concerns. They are valid. We originally announced that it would no longer be possible to reauthorize Finale after August 26th, 2025. But as a result of our community’s feedback, Finale authorization will remain active for the foreseeable future. Please note that future OS changes can still impact your ability to use Finale on new devices.

Finale v27 to be included with Dorico Pro Crossgrades

We are currently working on a solution for all customers who have purchased or intend to purchase a Dorico Pro crossgrade to be able to download Finale v27. This will ensure that you can export your Finale files using MusicXML 4.0, the most robust version of MusicXML available. Thank you for your patience, we will provide more information soon.

We hope these updates will help make your transition to Dorico even easier. We will continue to provide updates about the Finale sunset as more information becomes available.

I see on some message boards that the Dolet plug-in for Finale will allow you to batch convert entire folders of Finale files to MusicXML. Might be useful for people with large libraries of music in Finale format.

[Digidog]

If it was a matter of MakeMusic providing a service/feature for the benefit of the users that they're in the process of abandoning, I'd agree. There'd nothing in it for them. But there is something in it for Steinberg/Dorico, in the form of many thousands of soon-to-be abandoned Finale customers who will be having to choose between Dorico and Sibelius.

The million dollar question is now: Which is most viable, Dorico or Sibelius? I have, myself, a hunch that Dorico is the more modern coding, and thus with a longer life expectancy, but right now it feels like tossing the dice.....

Dorico would be expected to support it as well, potentially for a long time, and may not have exact feature parity with everything Finale has done over the last 30 years. If it was a separate organization (something like this would likely not be a huge stretch if the code were available), writing even a simple command line converter to take a final file and convert it to, say, music XML automatically shouldn't be hard if there isn't an expectation of support.

I just saw the two following-up emails where they admit to let the authorisations be indefinitely open, and they half-promise compatability and hint at the possibilities of bulk converting files to compatible formats. I don't know..... I have seen this developer BS before and I'm not yet convinced they will go to any lengths to ensure uncorrupted transfer of formats.

Finale kind of ... Wasn't that good, though, right? They finally realized there was no further development that could be done on something that hasn't changed since the 1700s. Dorico and Sibelius 100%

Layout-wise, nothing could beat Finale. For over thirty years Finale was the only notation software that gave you total control of, and option to tweak, all useful details of layout and sheet display. It is only the last one or two years, that Sibelius and Dorico were beginning to catch up.

As a working musician you surely know how great pieces and arrangements can be utterly ruined by poor layout, writing and disposition of the music, by making rehearsals unwieldy and performances confused - just from visual deficits. Though I over the years, as I'm sure you have, have developed a strong sense of note-deciphering skills that let me read thirtyfifth-generation copies of hundred and fifty years old scribbles, I have little patience nowdays for spending rehearsal time with unnecessary interpretation of what's written, rather than the music itself. Finale was, until only about one or two years or so ago, the only notation program that let me make as legible as possible layouts - as to the standards I have for making music legible and layouts easily understood.

The only real setback with Finale, was that it was kind of obvious that the coding was getting old. Some program functions had glitches and - if not bugs then serious mishaps - faults that made the program work in old-fashioned manners; like zooming tools not doing correct zooming, tools for handling mass instructions not processing very quickly and accurately (missing the whole of the mass marked) and a substandard hardware handling - like MIDI, sound boards or graphics.

To me, I could live with all those flaws as long as the layout options and global settings for disposition and layout were better than any other there was, but though I was pi$$ed at how Make Music at first treated me as a user, I find some solace with their promises of leaving the authorisations indefinitely open, making a smooth compatability to Dorico possible, and sweetening me up with a transition discount on Dorico.

The discount deal is a reality, and I implore them to make the other two promises real too......

[Matt K]

Yeah when I wrote that they were still saying the registration servers would be shut down next year. Muse score actually has a CLI that lets you use a lot of the features for exporting. I have an automated script that whenever something is dropped in git repo (which is where I store my MuseScore files), it automatically detects the changes and creates a full set of PDF exports and XML files, since the default is also a binary format now.

I’m actually a little surprised at the lack of automation in the industry generally. There’s AI chord symbol generation (you start typing the chord and it guesses what you’re doing so you can nominally do it faster) but then basic things like formatting, exporting, versioning, and putting parts in front of musicians is still embarrassingly manual and tedious, as far as I can tell.

I’ve thought about coding a browser based engraving tool since it seems like virtually all of the problems people run into are either 1) licensing issues or 2) os problems. Making it browser based would basically solve all of those problems and enable a lot of cloud based advantages like automatically pushing changes to receiving devices.

There are two commonly used business intelligence tools: PowerBI and Tableau. Both have a free version that allows you to read files generated from their paid applications. Having something like that would decouple the paid version of a product but avoid situations like what just happened. It’s unlikely to actually be built that way, though that’s how I would build it if I were to do it.

Maybe I should dust off the cobwebs of my JavaScript knowledge….

[bitbckt]

After Avid off-shored development of Sibelius and canned nearly every working engineer with domain knowledge of music engraving, Yamaha-Steinberg picked up the pieces and Dorico was born. Choosing to newly adopt Sibelius at this point seems unwise.

[harrisonreed]

Sibelius has always had the ability to do any layout you wanted -- it just has different controls to do so. On either program you will get poorly engraved charts that scream "made on Finale" (huge engraving font with too much space and a second page with only one staff on it) or "made in Sibelius" where you get some weird margins and choice of font.

Anyways, I think Sibelius had an easier learning curve (I only used version 6), and I've seen far more terrible finale scores than Sibelius ones. That may be because way more people use Finale overall.

They're both good, I just think it's hilarious that they are still saying they are "innovating" in a field that has not really changed in hundreds of years.

[Cmillar]

After being a longtime Sibelius user, I switched to Dorico and am totally happy with it in every way.

Slight adaptation period, but no big deal. It's probably even easier for a Finale user to get used to it.

One reason I love Dorico is because their parent company is Yamaha.

Yamaha won't be bought out and sold by some investment company looking for a turn over and profit. Yamaha is never going to just disappear. Plus, they've done wonderful things for the music world in general.

Compared to the competition now:
- Sibelius; days are probably numbered and people are probably still amazed that they're around seeing as Avid is owned by a bunch of investors in the first place. Very shaky.
- MuseScore: also owned by a group of investors. And, really, people are going to put there trust in Open Source software and trust it to remain useful? That's crazy. Plus, the parent company of MuseScore has ulterior motives that are pretty shady, like trying to 'own' the music publishing business. They bought out Hal Leonard. Will Hal Leonard just become fodder for another investment buyout?

I can't conscientiously support music software owned by any investment companies when the source of that funding is pretty shady to begin with, and then you keep seeing brilliant people just being bought out and assimilated.

Dorico is the best option, and the best notation software for now and the future. I don't mind supporting Yamaha and Steinberg. Their support system is unmatched.

[hyperbolica]

Doesn't Finale already export to MusicXML?

Yes, Finale writes to musicxml. If you want to preserve the live data, not just the print pdf data, musicxml is the way to go. I moved away from Finale a few years ago, and my old stuff I bring forward to Musescore via xml. The only real problem I have with the transition is that all ties it converts to slurs. This is not a visual problem, but playback gives an articulation on a slur, not on a tie. I haven't used Sibelius or Dorico, but I found the Musescore software to be better than Finale, and it's actively being developed.

Yes, the Musescore site is shady, as I've pointed out a few times here. But you don't have to use the site to use the software. The software is free, and honestly, I'm not making a living or making any money at all writing music anyway, so why would I pay for software.

[Matt K]

And, really, people are going to put there trust in Open Source software and trust it to remain useful?

Absolutely. Bear in mind that this site is founded exclusively on open source software. Sure there are some things that I'd do differently, but phpBB, MySQL, Ubuntu, Apache, and at least dozens of components are all open source. I work at a company that uses almost exclusively open source software, as have the last several that I worked at. It's absolutely possible for open source software to be sustainable.

That doesn't mean one shouldn't use Dorico or Sibelius, but I wouldn't use any software solely because it isn't open source.

[AtomicClock]

I’ve thought about coding a browser based engraving tool since it seems like virtually all of the problems people run into are either 1) licensing issues or 2) os problems. Making it browser based would basically solve all of those problems and enable a lot of cloud based advantages like automatically pushing changes to receiving devices.

Looks like Lilypond has the software already, and just lacks a server. Of course, it's very far from WYSIWYG.

LilyBin is a web-based LilyPond editor where you can typeset your scores directly online without needing to install LilyPond. Code snippets are kept available with a unique URL, like on so-called ‘pastebin’ websites. Although https://lilybin.com, where it used to be hosted, has been discontinued, its source code continues to be freely available under the MIT license; it may be found on its GitHub page.

[Digidog]

Well: As I have one chart on commission and one for my own big band project to lay up this week, I jumped on the upgrading offer and switched to Dorico.

It didn't take much research to see that Dorico was the best choice for me.

I obviously have to spend some time getting to know it, but I think it'd be doable over a couple of days.

I already miss my Finale templates and the infinite decimals determining the position of an articulation......sigh

[Matt K]

Last time I used it, Lilypond was more like a markdown editor. I think this is still true though it's a little hard to tell from the docs. You can write music on one pane as the source and it renders the music. That's kind of the opposite of what something like Finale, Sibelius, Dorico, or MuseScore do, which is you have a GUI which then gets translated into something that stores the file. Digging around the source code, it isn't obvious to me exactly why they call it a web based utility as I don't see anything that would make it usable inside a browser. I only looked for a minute so I may have missed something. Seems to be a C++ application for rendering and Python for manipulation into HTML, PDF, etc.

[marccromme]

For those who want a comparision between Finale and Lilypond, see here http://www.musicbyandrew.ca/finale-lilypond-1.html

There is also Rosegarden and Frescobaldi, a GUI for Lilypond

[AtomicClock]

Lilypond feels like a C compiler; you write your code in a text editor, and the compiler generates PDF (or whatever). There are some unaffiliated editors that improve the workflow, but not by much. LilyBin seems to be an unaffiliated tool that moves the compilation step to a web server.

I believe there are also bbs plugins, and I considered suggesting one for here. But I think no one would use it.

[JLivi]

After Avid off-shored development of Sibelius and canned nearly every working engineer with domain knowledge of music engraving, Yamaha-Steinberg picked up the pieces and Dorico was born. Choosing to newly adopt Sibelius at this point seems unwise.

I came here to say something similar.

[mgladdish]

[...]

I’ve thought about coding a browser based engraving tool since it seems like virtually all of the problems people run into are either 1) licensing issues or 2) os problems. Making it browser based would basically solve all of those problems and enable a lot of cloud based advantages like automatically pushing changes to receiving devices.

[...]

Oh you sweet summer child

If anything, solving cross-browser issues is even more annoying than cross-OS. The limitations and clinkiness of css and js make this sort of app a nightmare. Take a look at the engineering behind, say, Miro to see what they needed to do to have complete control over a UI.

All those cloud-based advantages could still be had from a native OS application.

[mgladdish]

And, really, people are going to put there trust in Open Source software and trust it to remain useful?

Absolutely. Bear in mind that this site is founded exclusively on open source software. Sure there are some things that I'd do differently, but phpBB, MySQL, Ubuntu, Apache, and at least dozens of components are all open source. I work at a company that uses almost exclusively open source software, as have the last several that I worked at. It's absolutely possible for open source software to be sustainable.

That doesn't mean one shouldn't use Dorico or Sibelius, but I wouldn't use any software solely because it isn't open source.

This. All companies rely on open source software to run their critical services, even the billion dollar megacorps.

I'd be interested to hear Finale's reason for *not* open-sourcing it. Presumably it uses some libs whose license forbids it, but it would be nice to hear that confirmed rather than it being solely down to management's bloody mindedness.

[Digidog]

I’ve thought about coding a browser based engraving tool since it seems like virtually all of the problems people run into are either 1) licensing issues or 2) os problems. Making it browser based would basically solve all of those problems and enable a lot of cloud based advantages like automatically pushing changes to receiving devices.

The issue I have with using browser based programs for creative work, is that there - potentially - could arise serious questions about the rights to - and protection of - the work. It is very easy to have a duplicating software working in the background, copying everything the user does, and then the software provider has an entire body of work someone else had produced, and it is by no means certain that the creator has the rights to what's been produced.

Adobe is currently trying to make their users signing off on the rights to everything they produce on Adobe's subscribed products, for Adobe to dispose at will. Everything. What's scary about this, is that Adobe is not alone. Microsoft has clauses that make the user agree on giving up some - or partial - rights to what they produce on their subscribed software, Google has, Apple tried but backed after serious and heavy critique, but the trend is clear. Software producers are more and more trying to get possession of the immaterial work their users produce; by agreements for using the software, by coercion from only providing subscribed products and then locking users up by proprietary formats and encryptions or by simply forcing users to agree on the company duplicating everything they do in real time.

I don't trust the goodwill of any such subscription software. The invention of those deals is only a mean to tie up, leech and exploit, and coerce and deceit the users of the rights to their work.

So I will never sign up for a subscription software service, nor use an online ditto. Not until there are forceful legal restrictions on how the user agreements can be written and used (but I'd be sceptical even then....).

[ghmerrill]

I've been following this thread with some interest because the situation illustrates a problem that a number of older (sometimes "venerated"?) software applications have. And I confess that I have a similar attitude towards "subscription software" although I'm coming around towards not seeing it as so burdensome and evil -- depending on exactly how it's implemented and provided.

In truth, subscription software itself has been around for a very long time (and could be argued to lie at the very heart of some of the largest companies even in the old mainframe world -- such as IBM). It actually addresses several significant problems (particularly for business/government/corporate users), including updating, support, and sales projections and planning on the side of the vendor, and cost, funding, and budgeting on the side of the customer/user. And I've seen that from both sides. For a decade I worked (both development and department-level management) for a company (still privately held) with subscription-only products which had its hooks very firmly into both industry and (particularly) government markets.

The more recent trend of attempting to acquire rights to "work product" is something different and is really independent of the subscription model. While I know that a semi-sophisticated argument could be provided about my having rights (to some degree) for products you produce using my product, there's at least a slippery slope here that ends in your owning part of my house because I used the circular saw I got from you to make improvements to it. In the end, I think there's no compelling argument for that -- which is precisely why some software vendors are now trying to lock in such rights through contractual agreements in which the user "voluntarily" gives up such rights in return for his/her right to use the software -- a seemingly straightforward quid pro quo. It may be interesting to see how that finally gets thrashed out in the courts.

The other aspect of this particular example involving Finale I find interesting is the complete flushing of the product in favor of creating an entirely new one that will "supercede" it. A lot of people (not themselves involved in software development) simply can't imagine why something like this should be "necessary," and instead suspect that it's simply a trick of the marketeers to squeeze more revenue out of an existing user base. I don't put that past the marketeers, but there are more fundamental issues driving such change. The technology used in implementing the original product is now so "old" that (with truly substantial changes in software and hardware technology since its original design and implementation) it simply isn't possible to keep "updating" the original product any longer: too complicated, too error-prone and destabilizing, and way too expensive. That route would kill the company producing it. Replacement is the only reasonable course: something that provides the same capabilities but on the basis of very different and contemporary technology. This is the way. Companies/organizations that don't follow this path will perish.

[Matt K]

I agree... sometimes, the developer(s)/owners, etc., don't want to maintain something anymore, and it takes extra effort to do anything other than quit. Given their glowing endorsement of Dorico, I suspect they likely had some arrangement, which is also acceptable; I get it. I'm somewhat disappointed, but my disappointment is irrelevant to their decision-making. And I'd rather Finale do what they did than Sibelius when it changed hands years ago... I loved Sibelius, but it's been plagued by licensing problems since Avid acquired it and fired the developers.

An open model with an open file standard would be much better for doing a "hand-off" since the open standard could be used by alternatives that crop up. MusicXML kind of does that but it lacks a lot of features. It's not the same as what, for example, even Microsoft has done for their document files which are actually surprisingly easy to open outside of Microsoft software - I just wrote an Excel interpreter for my job yesterday, actually, using all open source code and tools, no license paid to Microsoft.

The issue I have with using browser based programs for creative work, is that there - potentially - could arise serious questions about the rights to - and protection of - the work. It is very easy to have a duplicating software working in the background, copying everything the user does, and then the software provider has an entire body of work someone else had produced, and it is by no means certain that the creator has the rights to what's been produced.

Virtually all of the software you use has such telemetry baked into it, though you may have it disabled, including Dorico, Finale, Sibelius, and even MuseScore. Fundamentally, if you install something on your machine, it can exfiltrate data faster than you can even know it happened. As you indicated, license agreements can likewise be crafted on software that runs on your "desktop," which takes away your rights just as fast as something that runs on another machine, as Adobe is currently doing.

For what it's worth, assuming you trust your browser vendor (which you should if you have it installed on your machine because it has the ability to exfiltrate every shred of information you have on your computer), server software can be substantially more secure. Take this site, for example. If phpBB went away tomorrow, this site would still continue to function. So would all of the sites that use some kind of IaaS offering to offer subscriptions to people who pay for that provider to host phpBB. People could still install phpBB, copy posts, images, assets, etc. No functionality would be lost.

Beyond that, a whole machine can be dedicated to this one particular function. The user that runs the software can be granted the specific privileges that it needs, and the OS or the host OS (if virtualizing) can block ports, network traffic, etc. It is trivial to block outbound traffic, so all of the exfiltration you are worried about would be much, much easier to guarantee does not happen, provided that whoever is hosting the software (which could be you, someone you trust, or some organization you trust).

You can also isolate the application to only exist behind a VPN, so unlike this site which is open to everyone on the internet, you'd have to bypass another layer of security before you could even see the server. If it's setup properly (and this is indeed how I would set it up) you can run a whole web-based application on your computer using docker containers, which isolate the environment, so it only has access to resources on your machine.

Software that follows this design paradigm is actually pretty common now. For example, there is an application called BitWarden that I use for password backups. They are all open source, so what a lot of people (like myself) do is subscribe to BitWarden and then host a copy of the software on their internal network and have it periodically synchronize all of the passwords. This way, if Bitwarden ever decides to pull a Finale, all of those passwords are not permanently lost, and a migration.

Oh you sweet summer child

If anything, solving cross-browser issues is even more annoying than cross-OS. The limitations and clinkiness of css and js make this sort of app a nightmare. Take a look at the engineering behind, say, Miro to see what they needed to do to have complete control over a UI.

All those cloud-based advantages could still be had from a native OS application.

I build dev tools for teams internally, I know how much of a PITA it can be. I'm very fortunate that I'm only backend and some other poor fella has to deal with the front-end components

A native OS application could be interesting. I've been meaning to investigate something like flutter. A lot of those native apps just end up being a thin wrapper around the site, but I'm unlikely to have the time to do anything of this magnitude anytime soon as much as I'd like to.

[ghmerrill]

An open model with an open file standard would be much better for doing a "hand-off" since the open standard could be used by alternatives that crop up.

Yes, but then it would be way too easy for an alternative vendor to develop a competing product and sweep away your customer base.

The aforementioned company I used to work for (let's call it 'S') corralled its customer base with a proprietary data file format and then got government agencies (including the FDA) to require that data be in that format for various purposes. Even with loosening up this requirement a bit in recent decades, this gave the S application a huge advantage in the market.

In the mid-late '80s that application (though it's so huge that "application" hardly captures it, and for a brief period there was serious thought of producing an "S machine" that would optimally run S, basically as its OS) was rewritten from the original Fortran into C. Another transition occurred more recently (in the 2000s) when the application was moved slowly to more of a web/cloud interaction model. With the ownership of the company aging out at this point, and with the design and code base having "evolved" in this manner, I am very curious to see what the future holds for both the company and the product -- and the employees. Every couple of years there is talk about an IPO or a sale (the most recent projection is a delayed 2025 event of some sort), but it's never happened, and I can't imagine a model under which it will. I can't imagine a buyer for it because ... exactly what would you be "taking over," and how much value would that have in the current market and in the context of current technology and alternative approaches that have cropped up? So I look at what Finale is doing (though on a much smaller scale) as a wise -- even necessary -- move, before it's too late.

[Dennis]

Last time I used it, Lilypond was more like a markdown editor. I think this is still true though it's a little hard to tell from the docs. You can write music on one pane as the source and it renders the music. That's kind of the opposite of what something like Finale, Sibelius, Dorico, or MuseScore do, which is you have a GUI which then gets translated into something that stores the file. Digging around the source code, it isn't obvious to me exactly why they call it a web based utility as I don't see anything that would make it usable inside a browser. I only looked for a minute so I may have missed something. Seems to be a C++ application for rendering and Python for manipulation into HTML, PDF, etc.

In my working life, I spent 30 years as a professor of Statistics. That meant doing and publishing mathematics. The gold standard for publishing math is Don Knuth's TeX (pronounced, "tech" and the "e" ought to be a subscript, but I digress). TeX and Lilypond have very similar goals: to create beautiful, legible output (mathematics in the case of TeX and music in the case of Lilypond) similar to what a really good engraver or copyist might produce. I've used both TeX and Lilypond very extensively.

Creating beautiful output in the context of a WYSIWYG editor is hard--it may be impossible.

And so what you get is a markup language: you describe what you want to produce, and a compiler breaks that down to primitive elements and then assembles the final output.

Lilypond is not a compositional tool--I know that the developers try to present it that way, but it just isn't. And it can't be. Look at any urtext or composer's notebook. They worry about getting ideas onto paper and assembling them in a coherent fashion. They don't worry about making it easy to read. Even 'fair copies' sent to copyists are pretty messy. Once you have a score (or a part) Lilypond is great.

Just as when I wrote my dissertation: for 30 years I hauled notebooks around with me with all the dead ends that didn't make it into my dissertation as well as all the useful stuff that did. It was the useful stuff that got typed up in TeX and compiled into my dissertation. Back in those precambrian days there were a couple of pages of full color graphics that required special handling, too. But I could not have used TeX to run up and down all those dead ends--I would never have finished.

When I started playing tenor trombone in a contesting brass band, I didn't read Bb treble clef well enough to go to contest. So I took my part and used Lilypond to create a concert pitch part. I usually used tenor clef, but I did feel free to use bass clef if it made sense. I mean who really wants to read D1 written in tenor clef? I don't. I counted it as practice time, because it's certain that I learned the part a lot better by doing that. Like doing math in TeX from a fair copy in a notebook, it isn't work that requires a lot of brainpower.

So yeah--Lilypond is a markup language, like Markdown or TeX (or HTML or XML, for that matter). Maybe Frescobaldi (a WYSIWYG front-end for Lilypond) is a compositional tool. I'm not sure, because Lilypond doesn't run on the Mac OS Catalina and I haven't upgraded my hardware yet.

[Dennis]

An open model with an open file standard would be much better for doing a "hand-off" since the open standard could be used by alternatives that crop up.

The aforementioned company I used to work for (let's call it 'S') corralled its customer base with a proprietary data file format and then got government agencies (including the FDA) to require that data be in that format for various purposes. Even with loosening up this requirement a bit in recent decades, this gave the S application a huge advantage in the market.

In the mid-late '80s that application (though it's so huge that "application" hardly captures it, and for a brief period there was serious thought of producing an "S machine" that would optimally run S, basically as its OS) was rewritten from the original Fortran into C. Another transition occurred more recently (in the 2000s) when the application was moved slowly to more of a web/cloud interaction model. With the ownership of the company aging out at this point, and with the design and code base having "evolved" in this manner, I am very curious to see what the future holds for both the company and the product -- and the employees. Every couple of years there is talk about an IPO or a sale (the most recent projection is a delayed 2025 event of some sort), but it's never happened, and I can't imagine a model under which it will. I can't imagine a buyer for it because ... exactly what would you be "taking over," and how much value would that have in the current market and in the context of current technology and alternative approaches that have cropped up? So I look at what Finale is doing (though on a much smaller scale) as a wise -- even necessary -- move, before it's too late.

Actually, wasn't S(AS) originally written in PL/I and OS/360 Assembler, with a few routines in FORTRAN IV? For sure, for sure, for sure its syntax is nearly pure PL/I.

S(AS) is under serious threat from the open-source R language in the Pharma sector. The biggest problem R has library validation, and that seems to have been pretty well solved with Github and the like.

[ghmerrill]

Actually, wasn't S(AS) originally written in PL/I and OS/360 Assembler, with a few routines in FORTRAN IV? For sure, for sure, for sure its syntax is nearly pure PL/I.

I can't really say for sure since I never spent any time with SAS code (I was in the C/C++ commpiler development department). But my understanding was that it was predominantly in Fortran -- at least for the statistical processing stuff. But just think of a legacy system in PL/1, Fortran, and C on a mainframe evolving into the current technology.

S(AS) is under serious threat from the open-source R language in the Pharma sector. The biggest problem R has library validation, and that seems to have been pretty well solved with Github and the like.

Well, R is widely used by statisticians in the science side of Pharma. But for issues involving safety, trials and compliance, I don't think it meets regulatory needs. Again, however, I've been away from that since 2009 and things may have changed. I'll check with one of the guys who used to work for me and who is now in Drug Safety. I suspect that Github may not exactly thrill the FDA. We used all kinds (S, R, Python, XML, C#, Cyc, LISP, etc.) of things in implementing/testing/demoing new methodology for drug discovery and safety, but anything having to pass regulatory requirements is a different game.

[Dennis]

S(AS) is under serious threat from the open-source R language in the Pharma sector. The biggest problem R has library validation, and that seems to have been pretty well solved with Github and the like.

Well, R is widely used by statisticians in the science side of Pharma. But for issues involving safety, trials and compliance, I don't think it meets regulatory needs. Again, however, I've been away from that since 2009 and things may have changed. I'll check with one of the guys who used to work for me and who is now in Drug Safety. I suspect that Github may not exactly thrill the FDA. We used all kinds (S, R, Python, XML, C#, Cyc, LISP, etc.) of things in implementing/testing/demoing new methodology for drug discovery and safety, but anything having to pass regulatory requirements is a different game.

I'm on the trials planning, safety, and analysis side of Pharma.

90+% of what we do right now is SAS, but there is a lot of pressure (internally) to move to R. Qualified SAS programmers are getting harder and harder to find. We can hire someone with an MS in Statistics and they'll kinda, sorta know R. I've done some R package development in another life, so I'm dubious about it being quicker to teach someone who knows kindergarten R in the TidyVerse how to do package dev being faster than teaching them to code in SAS. But I'm a statistician, not an HR person.

[ghmerrill]

At some point, generative (or hybrid) AI is going to change all this -- in a way analogous to how higher level programming languages changed software development from the days of coding in assembly language. You'll be able to provide a problem specification together with available data, etc. to an AI which will then decide how to perform the analysis and render the answer to you. It's not that far away. The regulatory agencies (in any industry) will be dragged by the power of the technology. It's not that far away, in part because it's a highly competitive environment, and speed and success will rule. Focus will turn to validation of AIs.

[Bach5G]

Well, R is widely used by statisticians in the science side of Pharma. But for issues involving safety, trials and compliance, I don't think it meets regulatory needs. Again, however, I've been away from that since 2009 and things may have changed. I'll check with one of the guys who used to work for me and who is now in Drug Safety. I suspect that Github may not exactly thrill the FDA. We used all kinds (S, R, Python, XML, C#, Cyc, LISP, etc.) of things in implementing/testing/demoing new methodology for drug discovery and safety, but anything having to pass regulatory requirements is a different game.

I'm on the trials planning, safety, and analysis side of Pharma.

90+% of what we do right now is SAS, but there is a lot of pressure (internally) to move to R. Qualified SAS programmers are getting harder and harder to find. We can hire someone with an MS in Statistics and they'll kinda, sorta know R. I've done some R package development in another life, so I'm dubious about it being quicker to teach someone who knows kindergarten R in the TidyVerse how to do package dev being faster than teaching them to code in SAS. But I'm a statistician, not an HR person.

I have to admit I understood exactly 0% of this.

[ghmerrill]

I have to admit I understood exactly 0% of this.

That's okay, it's just about stuff that's in the brave new world of everyday reality. It will affect you, but you don't have to understand it or to care.

[BGuttman]

There have been changes in music software all along the way. I used to use something called Encore (by Passport Software) back in its heyday. Encore is about as current as Fortran (another language I know) and Cobol. Things you learn about in the History classes. Encore was OK in its day, but Finale and Sibelius put it to shame.

There is a point where trying to patch an old system to keep it running is more pain than gain. Windows 95 and NT supplanted the old MS-DOS/Windows combination in the mid 1990s because trying to keep updating the old system became unsupportable. Finale has been through a lot of upgrades and I suspect it's getting harder and harder to figure out what is going on what with the patches and alterations. A clean start is needed.

[Digidog]

At some point, generative (or hybrid) AI is going to change all this -- in a way analogous to how higher level programming languages changed software development from the days of coding in assembly language. You'll be able to provide a problem specification together with available data, etc. to an AI which will then decide how to perform the analysis and render the answer to you. It's not that far away. The regulatory agencies (in any industry) will be dragged by the power of the technology. It's not that far away, in part because it's a highly competitive environment, and speed and success will rule. Focus will turn to validation of AIs.

For detecting plain coding errors, AI is superior to anything I've used, but for programming logic and optimization, it still has a long way to go.

Some of the tests a friend and I made, ended up in the AI compounding structural logic errors and optimization steps, to the result that though everything worked, it produced and consumed a lot of most likely unnecessary data, and did unwieldy operations that we - actually - couldn't detect what they were doing and what they were responding to, or consequences of. One example was twelwe subroutines that probably could have been optimized into half that number, that produced so much operations and allocations that we could never disclose exactly what they were for. We could only monitor the hysterical amount of data used through the program's various cycles when running.

This was for satellite programming, and though I don't work with that, we sat down one saturday afternoon and tried to see if AI could do something my friend - who is the real space-ace programmer - hadn't done, or thought of. I don't remember what program monitor he uses, nor what the agency's - where he works - AI assistant is, but I can check it up because it was fun to get back into the strategic thinking and scheming of programming again.

[Dennis]

I have to admit I understood exactly 0% of this.

Just a couple of guys who both work/worked in different aspects of the same general space (Gary was a programmer/manager for the software publisher that I've spent about 80% of my professional life using in one way or another) and both happen to play trombone chatting.

Other than how it pertains to software obsolesence/senescense it isn't relevant to anyone else.

Regarding AI--having seen numerous examples of how large-language models can hallucinate, and having seen "coding assistants" write some really, really bad code (dates and time lapses are hard) that fail at basic logic checking (for example, the date someone stops taking a drug has to come after the date they started, and yeah, you need to check that somewhere), I don't see an AI replacing me for as long as I'm willing to work.

The biggest lesson we ought to learn (but probably won't) from large-language models is that how you ask the question is really important. The AI is going to freely incorporate your hidden assumptions into its answers.

[ghmerrill]

The biggest lesson we ought to learn (but probably won't) from large-language models is that how you ask the question is really important. The AI is going to freely incorporate your hidden assumptions into its answers.

And what you train the model on is even more important. It will incorporate the assumptions (beliefs, prejudices, interpretations, attitudes, whatever) of the corpus (from the people who determined what should be in the corpus). So AIs are as susceptible to bias as humans are -- although maybe we might be able to train them not to be (if we want to).

The last thing that Doug Lenat wrote prior to his death (https://arxiv.org/abs/2308.04445) addresses some of those concerns about AI and proposes a "hybrid" (a kind of checks and balances) approach to AI technology that combines LLMs with knowledge-based systems. In one straightforward sense this would build a kind of "truth checker" into your (potentially biased) generative AI system. But what would prevent the KBS from being biased as well (by its creators and curators)? I think there is no perfect solution. But some sort of checks and balances seems to be called for. Already we've seen some genuinely weird/hilarious/scary examples of "knowledge" generated by a Google AI. And I've had another AI outright lie to me about the history of some of my own publications even though I can't imagine why it would do that (though I think it was just sloppy design and implementation in that case). It at least admitted its "mistake", and apologized, when I called it on that.