[Finale] Re: Sibelius to Finale?
Hi Bonnie, As J D and Eric have mentioned, the Dolet 5 for Sibelius plug-in exports MusicXML files from Sibelius 6 that Finale can read. It is available for purchase from: http://store.recordare.com/dolet5sib.html The Dolet 5 for Finale plug-in does have a 10-day trial, but the Sibelius plug-in unfortunately does not. However, you can see a video demonstration at: http://www.youtube.com/watch?v=wvy-Uw_aBsA If you just have this one file to translate, our file translation services will probably be less expensive. This is where we do the translation for you, from Sibelius to Finale or for many other combinations of software. You can request a quote at: http://www.recordare.com/xml/translation.html Hopefully one of these alternatives will work for you! Best regards, Michael Good Recordare LLC www.recordare.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
As I see it, Finale has created a climate of resistance to their upgrades. The bugs are one factor, but for me, the much bigger factor is the lack of file-level compatibility across releases. 100 bucks for an upgrade is not much of an issue for me, even if the feature set were marginal. The real issue for me is that every time I upgrade, I separate myself from other Finale users who might be collaborators on a project here and there. While MakeMusic! does not provide it as a native option in finale, note that there is backwards compatability between many versions (I don't know for sure how far back, at least 2k3, IIRC) of Finmale, by means of Music XML using the Dolet plugin, which presumably also allows for cross compatability with certain versions of S~, too. I know that it has been a rcurring complaint in this list, at least, that there is not backwards write capability in Finale, but to be fair, evere since I started using the product with version 2k, MakeMusic! and its predecessor organizations has always stated that there was no backwards write capability. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
On 31 May 2009 at 23:27, Craig Parmerlee wrote: The database doesn't have to be fast. The objects are stored in memory during program execution. The penalty would only apply when opening or saving files. Yes, of course. Autosave would be intolerably slow (unless it saved to some form of intermediary format, but that leads to a whole host of other potential problems). Backups made when you manually save would be intolerably slow. When Microsoft switched its help file format to HTML help, they didn't use plain HTML for storage, but a compiled form of HTML. The reason for this was that plain-text storage was too slow. A help file *really* needs to open quickly, so they decided to optimize the process by using a binary format. If there is a decoding penalty during runtime it would surely be negligible. I think you are badly mistaken here. Delays in opening and saving are very noticeable to the end user, and saving is a frequent operation in Finale (because of the automatic saves and backups, and because so many of us have lost data so often in Finale that we save after any signficant operation). But the underlying premise of that argument, if I understand what you are saying, is just wrong. You seem to be saying that a proprietary, highly structured binary format cannot provide forward compatibility. I didn't say that, no. That is simply not true. ANY file storage system can provide forward compatibility at very little cost. It is simply a question priorities and the competence of the system designers. Starting from scratch, perhaps. But when dealing with a legacy app that's been around through 3 generations of OS's and hardware is not nearly as easy. I haven't designed forward compatibility into every single project I've every done, The key word here is that you would have designed it into your project from the beginning. That didn't happen with Finale. Whether or not it should have is pretty much a moot point at this juncture. but you can bet I have done that for any project that anticipated having multiple releases in the field where file interoperability would be a concern. Honestly, it isn't that hard. Then why is it that only large software companies seem to do it? That is, it's only the developers with deep pockets that seem to have the capability of doing this. And not even all of those do it. I just helped a client who is an account install a new version of QuickBooks Pro. All the files have to be converted to the new version, and it's quite a slow process. If Intuit, a very large software company with deep pockets, can't afford to devote the resources to developing an extensible file format, I think it's pretty unreasonable to expect a tiny company like MakeMusic to be able to devote resources to such a complex project. It's not like the file format is completely divorced from the application. Unless you've designed your app from the ground up with a data access layer that your app communicates with exclusively for file access, you're going to have connections to the file format littered throughout all sorts of areas of your application. I'm sure there is already a data access subsystem in Finale and the UI is not bound directly to that subsystem. But to add features to the file format, you have to add interfaces to the data access subsystem, and you may have to alter existing interfaces when existing structures are extended. So, it gets very complicated. Do you create a new interface to represent the new structure? Or do you somehow extend the properties of the old interface? It's a complicated problem and there's no simple answer. If you create a new interface, then the app has to know which one to use depending on the file format. That means your app needs to know things about the file format, or that you need a layer in between the app and the data access layer. It's not a trivial set of problems. My bet is that Finale has a data access layer, but that it is specific to each version, with interfaces changed to fit the new file format, and the app built on top of it altered to reflect the new interfaces. That is a very simple way to do the job, and it results in no backward compatibility, because the data access layer is tied to a single file format version. As I said above, altering that structure would require: 1. a rewrite of the data access layer. 2. a possible addition of a version management layer. 3. a rewrite of Finale to decouple it from direct communication with a particular data access layer version. And that doesn't even get into the issue of altering the basic file format to be extensible. If you make that change, then you may make it easier to implement interfaces to it (i.e., an extensible format might obviate the need for a version management layer), but at the cost of redesigning your file format. This is not a triviality by any means. For a system designer who knows
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
David W. Fenton wrote: On 30 May 2009 at 20:26, Craig Parmerlee wrote: The obvious solution is to program each release such that it can read future files but simply ignore any elements it doesn't recognize. If Finale worked this way, I would automatically purchase every upgrade. That is a complete impossibility without there being a freeze on the basic structure of the file format. Sure, it's possible to design an extensible file format, but that's a very complex task, especially for a database format (which is what a Finale file is). No it isn't. We do this every day of the week. It is absolutely routine. Today, with inherently extensible formats like XML, you would have to go out of your way NOT to have forward compatibility. The programming rule couldn't be simpler - handle all the objects you recognize and ignore the ones you don't. I realize Finale's files aren't stored in XML, but the same principle can be used in ANY storage system. I have been designing commercial business applications since 1973. Trust me. Not only is it possible, it is easy to do has essentially no cost when planned from the outset. Regarding the examples of Microsoft Word, whenever they have not preserved forward compatibility, they have released a free filter that users install retroactively on the older release to enable seamless file sharing. Microsoft, unlike Finale, understands that file sharing is an essential requirement for their users. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
At 5/31/2009 01:14 PM, Craig Parmerlee wrote: I agree with your comments about the trade-offs of filters versus XML. I would be just as happy if I knew I could send a 2010 filter to any collaborators so that they could open my 2010 files. Not to nitpick, but 2 additional points: 1) Even in a database oriented structure, you can still plan for object extensibility. The main reason for the size of XML is that it contains mostly formatting characters and self-definition structures. That enables XML to be used for any application by any combination of partners using any combination of programming frameworks. In the case of Finale, you don't need most of that overhead if the goal is simply to have forward compatibility between different programs released by MakeMusic. In AutoCAD and Revit, all database objects are labelled with a version number. Then an earlier version can tell they don't know how to deal with a later version number, and later versions know how to deal with earlier version numbers and convert them to updated versions. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
On 31 May 2009 at 14:04, Craig Parmerlee wrote: David W. Fenton wrote: On 30 May 2009 at 20:26, Craig Parmerlee wrote: The obvious solution is to program each release such that it can read future files but simply ignore any elements it doesn't recognize. If Finale worked this way, I would automatically purchase every upgrade. That is a complete impossibility without there being a freeze on the basic structure of the file format. Sure, it's possible to design an extensible file format, but that's a very complex task, especially for a database format (which is what a Finale file is). No it isn't. Uh, yes it is. What do you think those C-Tree error messages that pop up every now and again are referring to? http://en.wikipedia.org/wiki/C-tree We do this every day of the week. What is this? It is absolutely routine. Today, with inherently extensible formats like XML, you would have to go out of your way NOT to have forward compatibility. The programming rule couldn't be simpler - handle all the objects you recognize and ignore the ones you don't. Text-based storage of relational database data is inherently very slow. This is why no database that I know of uses XML as it's native storage format, but instead uses a structured binary format for storage and exports to XML when needed. I realize Finale's files aren't stored in XML, but the same principle can be used in ANY storage system. But not efficiently. I have been designing commercial business applications since 1973. Trust me. Not only is it possible, it is easy to do has essentially no cost when planned from the outset. I disagree. Text-based storage of data will never be as fast as binary storage with indexing and structured record formats. Regarding the examples of Microsoft Word, whenever they have not preserved forward compatibility, they have released a free filter that users install retroactively on the older release to enable seamless file sharing. Microsoft, unlike Finale, understands that file sharing is an essential requirement for their users. And Microsoft's file format is very simple compared to Finale's because it's stream-based (i.e., it's a collection of text streams related by pointers). It's a problem that is several orders of magnitude simpler than maintaining backward compatibility in a database format. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
The database doesn't have to be fast. The objects are stored in memory during program execution. The penalty would only apply when opening or saving files. If there is a decoding penalty during runtime it would surely be negligible. But the underlying premise of that argument, if I understand what you are saying, is just wrong. You seem to be saying that a proprietary, highly structured binary format cannot provide forward compatibility. That is simply not true. ANY file storage system can provide forward compatibility at very little cost. It is simply a question priorities and the competence of the system designers. I haven't designed forward compatibility into every single project I've every done, but you can bet I have done that for any project that anticipated having multiple releases in the field where file interoperability would be a concern. Honestly, it isn't that hard. For a system designer who knows what he's doing, it adds no more than 1% to the system cost / time and can be done on ANY file storage platform that I have ever encountered. I get that Finale doesn't think this is important and is never going to do it. I'm simply pointing out they make that decision at their own peril because for people like me, it makes me less likely to buy every upgrade. David W. Fenton wrote: On 31 May 2009 at 14:04, Craig Parmerlee wrote: It is absolutely routine. Today, with inherently extensible formats like XML, you would have to go out of your way NOT to have forward compatibility. The programming rule couldn't be simpler - handle all the objects you recognize and ignore the ones you don't. Text-based storage of relational database data is inherently very slow. This is why no database that I know of uses XML as it's native storage format, but instead uses a structured binary format for storage and exports to XML when needed. I realize Finale's files aren't stored in XML, but the same principle can be used in ANY storage system. But not efficiently. I have been designing commercial business applications since 1973. Trust me. Not only is it possible, it is easy to do has essentially no cost when planned from the outset. I disagree. Text-based storage of data will never be as fast as binary storage with indexing and structured record formats. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Sibelius 6 :: Finale discouraging upgrades
As I see it, Finale has created a climate of resistance to their upgrades. The bugs are one factor, but for me, the much bigger factor is the lack of file-level compatibility across releases. 100 bucks for an upgrade is not much of an issue for me, even if the feature set were marginal. The real issue for me is that every time I upgrade, I separate myself from other Finale users who might be collaborators on a project here and there. I don't know if Sibelius is any better in that regard. But considering that I don't know of any product that makes its file formats obsolete every year, I'm betting that this is not a problem with Sibelius. The obvious solution is to program each release such that it can read future files but simply ignore any elements it doesn't recognize. If Finale worked this way, I would automatically purchase every upgrade. dhbailey wrote: As a member of the Sibelius group at yahoogroups, I have to say that there I don't recall there being anybody who complains about the upgrade schedule. And while there are those who don't upgrade due to financial restrictions, I've never read that people aren't upgrading because they want to wait to see how the new features work and whether they really work at all, and never has anybody posted that they're skipping an upgrade because the improvements and additions in any single Sib upgrade aren't worth it. At least that I recall. One thing that Finale has done is to create a gun-shy user base, at least as indicated on this group. Many people don't jump on Finale upgrades the way they used to because of the horrible bugs which have been prevalent in the initial releases of the past several annual Finale upgrades. How many messages on this group have been of the I'll wait until they bring out the Fin200Xa patch which can't be helpful to the financial engine of the company. I wonder how many people hold off waiting for the first update patch to the upgrade (what a stupid thing that a company's user base has to wait for such a thing to feel comfortable with a new version) only to find that when the update patch is released the early-adopters aren't raving about how much got fixed. There must be many people who waited for the update patch and then waited an additional period for the b patch (not there always is one) or simply decide they were smart not to fall for that upgrade and simply wait for the next full version upgrade hoping the major bugs introduced in the current version manage to get fixed in the next full version upgrade? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Sibelius 6 :: Finale discouraging upgrades
At 8:26 PM -0400 5/30/09, Craig Parmerlee wrote: The real issue for me is that every time I upgrade, I separate myself from other Finale users who might be collaborators on a project here and there. I don't know if Sibelius is any better in that regard. But considering that I don't know of any product that makes its file formats obsolete every year, I'm betting that this is not a problem with Sibelius. Basically it is not. I can open files from previous versions (back through Sibelius 2 plus their introductory Sibelius Student) and I can then save those file in any of the previous file formats. That has been a real handy feature when I've exchanged files with my son (who still used the Sibelius 2 he was given when he was a Sibelius demonstrator in college) and with some of my students who have Sibelius 3 or Sibelius 4 (which I open in Sibelius 5 and then save as the version they have to return them). The obvious solution is to program each release such that it can read future files but simply ignore any elements it doesn't recognize. If Finale worked this way, I would automatically purchase every upgrade. Backward compatibility, yes. But I'm not sure that forward compatibility is even possible (although I lack the background to judge). When MS brought out WinOffice2007 their .docx files could not be opened in ANY previous version of Word, or in Word for Mac, so there's a limit to backward compatibility when big changes are made. John -- John R. Howell, Assoc. Prof. of Music Virginia Tech Department of Music College of Liberal Arts Human Sciences Blacksburg, Virginia, U.S.A. 24061-0240 Vox (540) 231-8411 Fax (540) 231-5034 (mailto:john.how...@vt.edu) http://www.music.vt.edu/faculty/howell/howell.html We never play anything the same way once. Shelly Manne's definition of jazz musicians. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Sibelius 6 :: Finale discouraging upgrades
On 30 May 2009 at 22:44, John Howell wrote: When MS brought out WinOffice2007 their .docx files could not be opened in ANY previous version of Word, or in Word for Mac, so there's a limit to backward compatibility when big changes are made. But they quickly brought out file filters for older versions of Office (at least on Windows -- the Mac version was delayed an inordinately long time). MS Office document formats, and especially the Open Doc formats (which use a proprietary, though published, form of XML, i.e., text and no binary code) are substantially simpler than a database file. There is no Open Doc Access file format, because it would be completely impossible. A database filed stored in plain text is not really a database (no indexes, for instance), and would be incredibly hard to edit efficiently. Finale files are database files, with all the benefits (and complexities) that come with that. I just checked the size of a MusicXML file exported from Finale. The original file is 354KB, while the MusicXML file produced from it is 4.4MBs. That's 10x as large because it simply takes a lot more data to store a database in plain text than in a binary file. Consider that in a database file, a piece of data's meaning is defined by where it is stored in the file -- it's in a particular row of a table and in a particular column. With XML formats, every data point has to be surrounded by verbose tags describing what it is, and those tags in turn are surrounded by even more tags. So, for a single column of a data table, every row repeats the XML tags for each piece of data. That adds huge overhead to the file. But it also makes it extremely easy to interpret the data, which is, of course, the whole reason for the existince of XML, to be able to create documents with customized and flexible structures that are nonetheless easy to interpret as long as you have the document type declaration that describes what the tags mean. Thus, creating read/save filters for the Open Doc formats (which are XML) was a relatively easy task compared to creating filters for binary formats. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Sibelius to Finale 2007
MusicXML transfer works like MIDI transfer between programs, but is much more accurate for notation. You save a MusicXML from one program, and then read the MusicXML file in another program. For instance, Finale will not read a Sibelius file directly. Instead, Finale 2007 will read a MusicXML file exported from Sibelius. The composer using Sibelius will need to have the Dolet for Sibelius plug-in to export the MusicXML file. The latest version for Sibelius 5 is available at: http://store.recordare.com/dolet4sib.html MusicXML import into Finale has improved a lot since Finale 2007. While you can use Finale 2007's built-in MusicXML import, you will get the best results using the Dolet 4 for Finale plug-in, available at: http://store.recordare.com/dolet4fin.html Alternatively, Recordare can do the translations from Sibelius to Finale files for you. You can request a quote using the online form at: http://www.recordare.com/xml/translation.html Sincerely, Michael Good Recordare LLC ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Sibelius to Finale
Hi Eric, As Richard and David have mentioned, MusicXML is the most accurate way to transfer files between Finale and Sibelius. If you have Sibelius as well as Finale, you can use the Dolet 3 for Sibelius plug-in yourself. Otherwise, the person with the Sibelius file will need to be the one to use it. You use the plug-in to export a MusicXML file from Sibelius that Finale can then open. For the most accurate results, use the Dolet 4 for Finale plug-in to open the MusicXML file, but Finale 2008's built-in MusicXML import does a good job as well. There is a video that demonstrates this process in comparison to MIDI files at: http://www.recordare.com/sibelius/video/dolet3sib.html The plug-in is available for purchase at: http://store.recordare.com/dolet3sib.html Best regards, Michael Good Recordare LLC ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Sibelius to Finale
Hi Richard, As Noel and David have mentioned, you can use MusicXML format to go between Sibelius and Finale. As with MIDI files, you write a MusicXML file from Sibelius, then read the MusicXML into Finale. But you'll get a lot more of the notation details with MusicXML than with MIDI, even with the restrictions imposed by the limits of the Sibelius plug-in development tools. Our Dolet for Sibelius plug-in runs on Sibelius 2.1 and 3.1 on both Windows and Mac. The Finale situation is different on Windows and Mac. On Windows, Dolet Light for Finale has been included since Finale 2003. However, the full version does a better job with Sibelius tablature than the light version. You can also use the full version with any Finale for Windows from 2000 on. On Macintosh OS X, V2 of Dolet for Finale is available for Finale 2004 and 2005. If you're on OS 9, there's no plug-in available, but we can do the translation for you with our file translations services. All the plug-ins and file translation services are available at our site: http://store.recordare.com/software.html Best regards, Michael Good Recordare LLC www.recordare.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
