Ideas on system for incorporating musical examples into a text document
This is a recurring topic that is of ongoing interest to many, particularly educators. Right now, MuseScore is perfectly capable of generating PNG or similar graphic files that can be be embedded into text documents, and that's viable for a short document with just a few examples. But the process is of actually doing this on a large scale is pretty cumbersome. A typical textbook might easily have hundreds of musical examples. Aside from just the pain of needing to manually export each example from MuseScore and then manually import each into your text document (and hopefully get the right example into the right place in the document), there is currently no easy way to keep track of which example within the text came from which MuseScore file, and thus trying to replace/update an example is difficult.
I have in the past described my own system for incorporating musical examples into text documents using macros that let me write ABC (a text-based music notation) directly into my text and having these automatically converted from from ABC to musical notation using abcm2ps and other tools. This system works pretty well, but it requires one to know ABC.
So I am looking at the possibility of coming up with something that would allow people to use MuseScore but still in an automated fashion. That is, to insert a musical example in your document, you place the cursor where you want it, hit a button, MuseScore pops up, you create the example, and when you save it and close MuseScore, and the graphic automatically appears in your document at that place. To edit an existing musical example, you click the example, hit a button, MuseScore pops up with the example loaded, you edit it, and again up save & close, the updated graphic appears in your document. For my own purposes, I want to also have a facility where ABC notation can automatically be generated and associated with each example. I suppose MusicXML could have a role here too.
First question - does this sound like the right use model? Makes sense to me, but maybe others have better ideas.
In a reply, I will talk about implementation.
Comments
As for implementing the scheme I described:
I am aware of a plugin that once existed for OpenOffice called OOoMuseScore, that could partially automate this process. I have found the source, and it seems to be a rough adaptation of OOoLilyPond, which was itself the inspiration for my ABC macros. But it seems it was a very incomplete adaptation - "Very simple test-version! By no way a "release" version!" according to the README - and I am not sure it is worth the effort for me to try to get it working on my system. I suspect I could adapt my own macros to do the job at least as easily as I could come up to speed on someone else's. But perhaps someone else has more recent experience with OOoMuseScore that would change my mind.
I do have reservations about whether the basic approach taken by all these macros is really the way to go. It's quite brute-force: the macros are in the business of stuffing text into temp files (LilyPond or ABC source in the case of OOoLilyPond and my ABC macros, presumably MSCX in the case of OOoMuseScore), executing shell commands to invoke LilyPond, abcm2ps, or mscore, reading in the resulting graphic file, massaging the graphic as necessary to have the right resolution & format, inserting the graphic, and attaching the original text input to the inserted graphic as an attribute. The details of how all this is done are maddeningly OS-specific, and the entire way the macros are written is different between OpenOffice/LibreOffice, Word, and Google Docs.
So before I go too far down this road, I am just wondering if others know of better ways of going about this whole process. In previous threads where this subject has been discussed, I've mentioned that OLE was at one time (pre-WWW!) a technology one might use for this sort of thing, at least on Windows. But I never learned how to use it, and I never hear about it any more. Seems to me that in today's world, this should all be implemented as URL's. The graphic could be a link to the source file, with the protocol specifying the application to be used. Something like "mscore://Users/Marc/Documents/MuseScore/example23.mscz". Then any program that could read the document would automatically do the right thing when you (double) clicked the image, and this would work on any OS, with no macro programming required to hook any of this up. I suppose I am dreaming?
In reply to As for implementing the by Marc Sabatella
So, after just a bit of experimenting, it seems OLE is alive and well, and may work as I might hope for this purpose. From LibreOffice, I did Insert / Object / OLE Object / Create from file, specified the name of one of my existing scores, ignored the selection of a "filter" for the object, and presto, an icon representing my example gets inserted into the document. I can then double click the icon, MuseScore comes up, and I can edit the score. I verified that if I then close MuseScore and double click the icon in my document, the changes I made on the previous edit are intact.
Of course, I don't want an icon representing my example to be inserted in the document; I want to see the graphic. I assume this is the role of the filter.
Does this mean if I were to figure out how to create a filter for MSCZ files (hopefully, something that would just invoke mscore with appropriate parameters), I'd have what I want? Sounds too good to be true.
I'd still prefer a more direct way to create the object initially. I see that, when inserting the OLE object, LibreOffice gives me the option to " "Create new" as well as "Create from file", but then I have to select from predefined object types, and of course, "MuseScore Score" isn't one of them. Perhaps it is possible to extend that as well.
In reply to So, after just a bit of by Marc Sabatella
You might want to check tools from other domains like OOoChemistry.
In this thread, the author explains how to add a new OLE type.
In reply to You might want to check tools by [DELETED] 5
Thanks, that does look useful!
I must admit that between what I have seen of OOoChemistry and also the documentation I have found on creating import filters, this does not look like it will be nearly as simple as I had hoped. I also got feedback from a post I made in the LibreOffice forum basically discouraging me from using OLE at all, which I suppose is understandable as anything that comes from Microsoft is likely to be looked down upon by folks associated with an open source alternative to a MS product. All of which has me wondering if the macro approach isn't preferable after all.
Either way - macro or OLE - it seems to me that the basic approach is quite sound, leading to me to wonder why Finale and Sibelius haven't tried to provide anything like this. Really, just about any program that is in the business of creating special-purpose graphics could benefit from this type of facility. Seems odd that there is still no ready-made solution to what I would think has to be a common problem: incorporating special-purpose graphics into a text document.
Oh well. I don't suppose this is the sort of thing that would interest anyone at one of those Music Hack Days?
In reply to Thanks, that does look by Marc Sabatella
Could you post link to the post on LibreOffice forum? (I know, it's a pain with those proprietary tablets :p)
Anything is interesting for a Music hack day ;) It's on my long list of hacks to be done but I always find something more fun.
Also could you link to your ABC plugin for OOo. The only link I found is dug deep in a yahoo! forum, with mandatory registration.
In reply to Could you post link to the by [DELETED] 5
Here is my post on the LibreOffice forum (I happened to be on my PC when reading this :-)
http://en.libreofficeforum.org/node/3794
I have attached the ZIP for my my ABC macros for OOo. There is a README file in the archive explaining how to get things running. It's not as simple a process as I'd like, but it does work.
It seems to me that the bulk of the code - and most of the fragile portions of it - is in the text handling. Parsing paragraphs looking for ABC fragments, etc. A facility like what I described in my initial thread here - a way to directly invoke MuseScore on a graphic - would actually be rather simpler. I'll probably just bite the bullet and do it. But my current textbook project is already pretty heavily invested in ABC. Might be interesting to adapt my macros to use abc2xml and MuseScure instead of abcm2ps and ghostscript and see what happens.
In reply to Here is my post on the by Marc Sabatella
I just read the README and got an idea. Probably a stupid idea, but just in case it's not, what about the following.
In reply to I just read the README and by [DELETED] 5
Nice idea - I didn't know you could insert and activate hyperlinks to arbitrary files on your file system in LibreOffice and get it to open them for you using ordinary file associations. Yes, that very nicely cuts out some of my least favorite portions of the existing code - the portions dealing with locating and executing the appropriate binaries. So the advantage of OLE diminishes.
The cropping I was thinking I might deal for now with by actually setting appropriate page sizes in my MSCZ files. I was also going to look into use of Image Magick from within the macro to do the trimming - I assume this is what the OOoMuseScore macros are doing? But then I'm back in the business of explicitly locating and running binaries from my macros, although I can think of tricks to get around that (eg,defining a new file type at OS level, associated with a script / batch file that invokes MuseScore and then ImageMagick). Of course, a command line option to MuseScore that caused the generated PNG to be trimmed would be nice.
But what OLE still would have bought me is automatic updating of an image within the LIbreOffice document when its MSCXZ file is changed. My macros would need to deal with this manually. Probably via an explicit "Update" command that looked at all the MSCZ files associated with a document to see which were more recent than the timestamp I'd store in corresponding the embedded image, or something like that, and then generating new graphics for all that were out of date. I could presumably also detect the exit of an instance of MuseScore that I had kicked off, but given that a user might be going back forth between LibreOffice and MUseScore this whole time, I don't think it makes sense to pin the update on waiting for MuseScore to exit.
Anyhow, dealing with updating the image when the score is edited is the other major part of what I expected OLE to give me for free. But going the macro route using hyperlinks could be OK.
In reply to Nice idea - I didn't know you by Marc Sabatella
You could use a while (1) loop in your code, with a wait(). The macro would run forever and check the modification date of linked files.
In reply to You could use a while (1) by [DELETED] 5
I see how I can use that to wait for MuseScore to exit, but does that help me notice updates to the files unless I'm constantly polling (which I assume would interfere with using LibreOffice)? Maybe it's possible to register interest in a given file and be notified when it is changed?
In reply to I see how I can use that to by Marc Sabatella
Silly me - if the graphic is inserted as a link in the first place, it *already* updates automatically. Well, it updates next time LibreOffice decides it needs to redraw the graphic on the page (like if you try to stretch it
So, even with no macros or OLE whatsoever, the core functionality works! If I could get screenr working on my system again (Java issues), I'd make a video, but for each example you wish to insert, the process is:
1. in MuseScore, create your example, save as example.mscz
2. either save as PNG or run snippet creator to generate example.png
3. in LibreOficce, insert->picture->from file, check the "link" box, enter example.png
4. double click image, hyperlink, enter example.mscz
Now you have a document with graphics that you can view or print as such, but if you wish to edit one of your examples, simply ctrl-click it. That automatically brings up MuseScore on the file, Make your changes, re-create the PNG file from within MuseScore, flip back to LibreOffice, do anything that causes it to need to redraw the graphic, and there's your change.
Sure wish I had realized this years ago!
So really, there isn't that much that needs to be automated via macro. I could simplify the associating of the link with the image. Also force the redraw. But now the cropping seems the more important issue.
Hmmm, will be thinking about how to use this myself. It's still rather more work than my ABC solution on a per-example basis, especially for short examples. And there are other advantages to the ABC method for me, like easy ability to update formatting of the examples (sizes, fonts, etc) all at once. But I like having the MuseScore option too!
I have developed a LibreOffice/OpenOffice macro to simplify the process of inserting MuseScore examples in a text document, using the apporach described in this message . There's not actually that much to it, and most probably won't see this as a big deal. But I think it is pretty cool, especially if you have lots and lots of examples you need to insert and are concerned about the possibility of needing to edit them later.
The macro keeps your the inserted graphics associated with their corresponding MSCZ files, so Ctrl-Click on an inserted graphic automatically launches MuseScore on the right file. And after editing it in MuseScore and regenerating the graphic, the updated graphic is (semi)automatically reflected in your text document. Here is a video demonstration:
http://www.screenr.com/0Fq8
To try the macros out for yourself, just open the following document:
https://dl.dropbox.com/u/31645840/MuseScore/musescore.odt
Be sure to agree to enable macros when asked. Further instructions are in the document itself.
To use this in your own documents, just open my original document then Save As something else. Eventually maybe I'll figure out a better way to package it.
In reply to Success! by Marc Sabatella
BTW, the main limiting factor to using this is now the fact that PNG files exported from MuseScore always seem to come out at 96DPI according to the file header, regardless of the actual resolution you used when saving. So if you use a larger resolution like 300DPI when saving your PNG files, they show up too large in LibreOffice, because it thinks they are only 96DPI. And if you use 96DPI, they look right on screen but don't print well.
I tried for a while to figure out a way to get LibreOffice to scale down the 300DPI graphics, but eventually gave up. A better answer might be to see if there is a way from within Snippet Creator to fix the incorrect header info. I also tried playing with that, but got nowhere. It seems the bug may actually be in Qt?
Also, SnippetCreator, wonderful as it is, gets kind of slow with high resolution graphics. Because of that as well as the wrong DPI setting, I suspect it might be better to use Image Magick to do the trimming and have it correct the DPI figure while it is at it.
In reply to BTW, the main limiting factor by Marc Sabatella
Hi Marc,
why not use vector graphics (svg) instead?
Btw. an early version of EPUB 3 export in EasyABC is almost done. There is support for customizing the stylesheet and core meta data. Furthermore, referenced images (whether on the internet or placed locally relatively to the ABC file) are automatically embedded in the compiled package. One can use the more simple Markdown syntax for most things, but it's also possible to use HTML anywhere.
In reply to Vector graphics by Nils L
SVG export is definitely the way to go looking forward, but it's broken in MuseScore 1.X. No matter; the plugin I created to replicate the functionality of Snippet Creator but using Image Magick to do the dirty work and fix the DPI field in the header suits my needs for now. I'm now starting my first project using this system: an aural skills workbook for my jazz theory class. I've been using my ABC macros for LibreOffice for the past couple of years, but I am excited to able to do this in MuseScore now and still have the easy of editing the ABC approach afforded me.
Very cool about the EPUB export in EasyABC. As I mentioned in a post to the ABC list, I'm very curious to see how this all works with the markdown and all, and I might amend my own ABC macros to use a similar syntax. Right now, there are no special markings to identify ABC in my system - I just look for things that "look" like ABC (paragraphs beginning with "X:"), then mark them with a special style to make them easy to find and work with later.
In reply to Success! by Marc Sabatella
Good thing with inserting links is the thing with updating the original files. Bad thing is that you have to keep the original mscz files together with your text document. So if you just paste the graphics into your text document, you only need the text document. Well, you need the original mscz documents, if you want to change something, as it has been pointed out. But in the first case you need all your mscz files whether or not you want to edit the examples later.
Anyway, pasting the graphics could work so that you'd mark bars in MuseScore, choose ctrl+c, then go to your text editor and choose ctrl+v and you'd get a svg or wmf file of the bars with included cleff and key signature, and maybe meter, too. If I recall correctly, the clipboard works so that a program can write data to the clipboard in more than one data type at a time. So doing the ctrl+c in MuseScore would write one chunk for MuseScore internal use and one chunk as a SVG like graphic object. And of course also as a BMP like object. Then, in your text editor, when you paste (or ctrl+shift+v), you can choose whether to paste as bitmap graphics or vector graphics. Though I don't know how much data MuseScore would have to write to the clipboard, especially when note heads and lots of other font created graphics would have to be converted to path based graphics.
In reply to Good thing with inserting by jotti
I figure the advantage of automatic update of linked images trumps the disadvantage of needing to keep them with the file, especially since the entire point of these macros is to facilitate updating. If you didn't plan on editing, you wouldn't be using these macros, so it wouldn't matter if they linked or embedded. And assuming you do use the macros, when you think you might be all done with all edits, I am pretty sure there exists a command to automatically go through and embed all linked images, if you really want to.
But I am *never* so completely done with a project that I imagine I will never have occasion to update it. And having to keep the images with the document doesn't bother me in the least - when I want I portable copy of my document, that's what PDF is for. Assuming it is worth keeping the text document at all (as opposed to just keeping the PDF), it's worth keeping it in editable form, I think.
BTW, I just realized there is already a Tools->Update command to force linked graphics to update, so I didn't need those extra three lines in my macro to do that :-)
Yes, ultimately it would be great to copy paste directly from MuseScore to a word processor. But that would be far more involved than just an evening's hacking.
In reply to I figure the advantage of by Marc Sabatella
You can't copy paste but using the new foto mode in the nightlies, you can capture a area in the score, right click, copy and paste in your word processor.
In reply to You can't copy paste but by [DELETED] 5
But that pastes it as a bitmap at screen resolution, right? If you mark a rectangle the width of a 4th of the screen, you get a 300 pixel wide bitmap. That's way too poor, if you want to print your text. Or is the nightly version capable of rendering a higher resolution to the clipboard? It could be an easy hack: when you do the capture and right click stuff, it would be like you would raise the zoom factor to 800% or 1600%, but this would happen to an unvisible temporary bitmap, not to the visual screen or application window. The bitmap copying to the clipboard would happen from this high res rendition.
* testing-testing-1-2-3 *
Gee, just tested the latest nightly. Seems I am able to do all that. The copy and paste really renders hi res, if that's what I want. When I set the resolution, the program mentions png/svg, but the copy-paste thing obviously deals only with bitmap. But the saving to an svg seems to work, too. And no fuss with fonts either.
In reply to But that pastes it as a by jotti
Yep, for quick one-off sorts of things, foto mode is going to be fantastic. Still, I wouldn't use it for a textbook. I'm way too picky about wanting the formatting, margins and so forth to be consistent from example to example, also there still remains the issue that prompted this thread in the first place: the need to associate each notated example in the text document with its source, to facilitate future editing.
This does remind me, I should modify my macros to allow SVG, and I guess other graphic formats as well.
Btw, simply changing the one occurence of "mscz" in the source to the macros to ".mus" or ".sib" would make it work for Finale or Sibelius too :-).
In reply to Success! by Marc Sabatella
Due to a bug that causes exported graphics to come out at the wrong DPI setting and thus import incorrectly, I have developed my own variation on the Snippet Creator plugin that uses the open source program ImageMagick to workaround the problem. Install ImageMagick (be sure to select the option to have it added to your PATH) and then the following plugin:
https://dl.dropbox.com/u/31645840/MuseScore/make_example.js
I also made some refinements to the macros in musescore.odt.
In reply to Success! by Marc Sabatella
Still refining this, and am running into a bit of a snag I was hoping to get input on.
The short version:
can anyone think of a way to get MuseScore to obey a specific page size and/or margins when converting MusicXML to MSCZ with a command line invocation? I know about the "-S" option to specify a style file, but it seems that style files do not include page layout settings (and any such settings are ignored when added by hand).
The long version:
It turns out that while the simple parts of the solution I described above are indeed quite simple, there turn out to be a lot of complications. For instance, if upon editing an example, its width changes, LibreOffice just squeezes/stretches the new graphic to fit in the space allocated for the old. Also, I found that constantly having to export the graphic from MuseScore and even then still have to kick LibreOffice to get it to recognize the change was kind of a pain. And while I doubt anyone else would care, I really missed the ability to simply type in my examples in ABC at least as a starting point, plus I still needed the ability to have all examples converted to ABC.
So I am doing a major overhaul of my macros, using re-incorporating a lot of the functionality of my old ABC macros but adapted for MuseScore. I am closing in on something I think will satisfy my needs better than either my original solution using ABC or my initial cut at a solution using MuseScore, and I think it should work quite well for others too.
The main stumbling block right now has to do with the width of examples initially created from ABC. I run abc2xml to produce a MusicXML version, then run MuseScore with command line arguments to convert to MSCZ, specifying a Style via the "-S" option. The Style does not contain any information on page layout, so the resulting MSCZ file uses the MuseScore defaults for page size and margins. This results in the example potentially being wider than will fit in the text document, and LibreOffice either squeezes the graphic to fit or extends it into the margin.
It is probably possible to get my LibreOffice macros to resize the graphic to fit, but I'd really rather be able to control the page width / margins during the conversion from MusicXML to MSCZ. Hence my desire to find a way to get MuseScore to obey specific page width / margins when doing the conversion.
Worst case for my own usage, I fire up MuseScore, go to Edit/Preferences/Score and manually change the default paper size to something appropriate, then try to remember to set it back when I am done generating examples. But that's very kludgy.
In reply to Still refining this, and am by Marc Sabatella
Paper size and margins can be specified in MusicXML and I think MuseScore would obey them.
Not sure I understand your workflow, but you start from ABC? if yes, (and I don't see why) you could modify abc2xml to accept a page size, margins to output in MusicXML, or maybe better use page format directive in your ABC (http://abcnotation.com/wiki/abc:standard:v2.1#page_format_directives) and see if abc2xml honors them. If not, it could be modified to.
if you don't start from ABC. You can specify a page size in the first place in your MuseScore file? so I don't see the problem
In reply to Paper size and margins can be by [DELETED] 5
Thanks for the suggestions. Currently, abc2xml does not seem to do anything with %%pagewidth or I:pagewidth, but I'm sure it could be modified to do so. Although actually, for a number of reasons - not wanting to have to embed pagewidth directives into my ABC over and over, the not-completely-standard nature of pagewidth, and not being sure how feasible messing with abc2xml's parser will turn out to be, I am thinking command line options to abc2xml to set the MusicXML page size and margins is actually the way to go.
As for starting when/why I might start from ABC, I have quite of bit of existing work with embedded ABC created over the past two years (for reasons you surely don't need to hear again :-) that I'd like to move over to MuseScore. And even in new work, really, for little one-line examples that maybe just demonstrate a single scale or chord, I find that typing them as ABC directly into my document is faster and less disruptive to my workflow than having to switch to MuseScore, create a new document, etc. But for anything more substantial, sure, doing them directly in MuseScore makes more sense. So I have my macros set up to allow either mode of operation, and it's actually working very well in all other respects.
Since I am active using this over the next weeks to put together teaching materials for the fall, I hope to have these kinks worked out soon and will be giving it all some pretty good testing. When I feel it is ready, I'll start another thread with the updated macros (hopefully packaged as an "extension" to make installation easier) and instructions.
In reply to Thanks for the suggestions. by Marc Sabatella
Marc,
As I migrated to Windows 7, I also want to insert MuseScore scores into text (Writer from LibreOffice).
Is the musescore-1.0.8.oxt still valid or is there a newer version?
Joe.
In reply to Marc, As I migrated to by JoeAlders
That is the current version. Looks like it's now a year old and so the LibreOffice site complains it may no longer be maintained, but if it ain't broke... no really, I probably will produce an update at some point, but there is nothing pending.
In reply to That is the current version. by Marc Sabatella
O.K. Marc, the installing procedure using the lates oxt version went fine without facing a nasty problem.
Just wanted to let you know......
Joe.
Marc,
I suggest you give OLE another thought because in my opinion it is the way to go. I used to be a programmer in the '90s when DDE was giving way to OLE and all this was new and hot. Look how it should be from the viewpoint of an end user. Here throughout the examples "Wordpad" stands for "Musescore":
in Writer, Insert -> Object -> OLE Object, Further objects. Then you choose a type for the new object:
![s1.png]( "s1.png")
An application registered for this object type opens (I may be fuzzy on terminology). Please note the window title and menu items (Update document, Exit and return to document) which reflect the embedding:
![s2.png]( "s2.png")
After you edit the object with its native application it behaves very predictably, much like a picture (or whatever support for embedded objects OpenOffice offers):
![s3.png]( "s3.png")
The benefits are obvious:
- it is THE cleanest scenario, no superfluous actions, updating is automatic (you don't think about it at all, no more that about updating let's say a table within a document), further editing is seamless
- no extra files since the object is stored within the container file
- the technology has been here for years and is well known and supported (I think so, having worked with MS products for the most part). I would go as far as call it a standard feature of modern software, like using a system clipboard and responding to Alt-F4.
There may be drawbacks but I cannot think of any at the moment. I dearly wish this was implemented because this would simplify mixing text and notation examples so much. I would love to have this feature available right now :) but if it makes its way in 2.0 it would be awesome, too. Thanks for reading. I haven't read these forums before and I hope I haven't broken any rules, apologies if so.
In reply to Give OLE another thought by Ivan L
It is indeed possible at some point i will look into reimplementing this using OLE. But the current approach - I assume you have read through this thread and realize the extension is completely implemented and available for download from the LibreOffice extensions site already? - does work well. Yes, it requires a manual step (a single button press) to update examples after a change, but compared to what would be required without use of the extension, that's nothing. I guess I may add an "update all" command at some point. But the current implementation has the advantage of simplicity and portability.
What may ultimately push me to go the OLE route will be my desire to provide other methods of accessing these examples for the end user of the document. In addition to the conversion to ABC I already provide, I intend to provide ways of exporting to MusicXML and eventually Braille, also of interfacing directly with programs that can read the notation aloud. Plus the ability to play audio associated with the examples. Overall, the goal will be to make the document itself a much richer multimedia experience for the reader, primarily for the benefit of the blind, but also people who perhaps don't read music well, or who just want to hear audio. But I'm not sure what implications that will have on the process of creating these documents yet.
In reply to It is indeed possible at some by Marc Sabatella
Thanks for the reply, Marc. Yes, of course I have read all and know about the extension and how it works. I have just done a bit of reading on OLE, it does not seem the perfect solution. Seems like another MS invention which requires everybody else to play by MS rules. However it's still cleaner/faster than VB scripting and exchanging data via file system and shell calls. Whether it justifies the effort of implementing is still not clear. Being able to insert MuseScore scores into MS Office documents would be great...