Text editing annoyances

• Jan 21, 2012 - 01:21

Relative to more typical text editing UI design, the following keep getting me:

1. Clicking past the end of a text line but still within the frame ends the edit instead of positioning the cursor to the end of the line.

2. HOME and END take to to the start and end of the frame, not to the more common start and end of the current line.

3. As mentioned elsewhere, no text wrap.

4. No apparent in-frame format control other than bold, italic, underscore; would also like to be able to change selected text within the frame to different font, size, alignment, etc., add bullets, special symbols/glyphs, etc. Of course full HTML editing would be one way to go.

I expect that 2.0 is addressing many such format issues but thought I would provide this 1.1 feedback anyway.

Comments

• Jan 21, 2012 - 05:42

Regarding #4, some of that is possible already. Font face, size, and alignment can be changed for selected regions using the text toolbar at the bottom of the screen, and special symbols can be added via the paltte that comes up when you press F2 while typing. But it's still obviously well short of a word processor. I think you'll find that if you are trying to intermix any serious amount of text with notated music - like putting exercise books together and so forth - it's more efficient to export your notated examples as PNG files and just import those into a word processor. The Snippet Creator plugin is quite useful for that purpose; 2.0 will also have some more built in support for exporting selected regions of a page.

Reply

• Jan 21, 2012 - 10:24

Another trick with text is use an external text editor (I use TED Notepad) to write and format your text block then copy & paste it into the MuseScore Frame.

But we do need word wrap!

I believe that you shouldn't have to resort to exporting PNGs but should be able to write everything in MuseScore.

That way Exercises and tutors can be written in MuseScore for display on iPad and Android devices, and students will be able to playback the examples :)

Reply

• Jan 25, 2012 - 20:59

Geez I can't believe I never noticed that toolbar at the bottom of the page. What a maroon! The other controls all seemed to be top-oriented. And F2 is a revelation...another thing I hadn't discovered. Thanks for the remedial help.

Regarding the export of snippets, that is obviously a good approach for creating a document with bits of music. In my case, I have been working on fairly long (15-20 page) scores with occasional blocks of text. Really too much material to be extracting many dozens of snippets, so I'm working with the text editing abilities. Actually if just word wrap were present, text management would be entirely workable. On the other hand, I grew up using text editors without word wrap, so I'm pretty fast at reformatting text blocks. :) And I do cut/paste with a text editor (I use TextPad) that provides word wrap, block select, and other features that speed this process up. Though I find myself doing it manually much of the time.

Reply

• Feb 7, 2017 - 19:45

It's now 2017, I'm using the latest MuseScore, and it appears there's been no progress on this issues. There is no word wrap, and there is no ability to embed an external word processor using some kind of object API. (I understand this might be challenging because of the proprietary nature of object APIs.)

I'm attempting to create a menual for percussion. There might be a few pages of plain text, several pages of text and staff interspersed, and multiple pages of staff only. Managing this by exporting image files from MuseScore into a word processor is challenging and inefficient.

I have extensive programming experience, so I've considered writing a script that would match tags between two source files, one MuseScore and the other a word processing document, and combine the output into a single MuseScore file. But without word wrap, this seems unworkable.

The alternative would be to programmatically do screen grabs from MuseScore and add them to the word processing doc. Haven't looked into this yet.

Even if the first option were possible, both options would require some clean-up after the merge, so there doesn't seem to be an easy solution whereby I can modify two source documents and easily output a finished product after modifications and merges.

This leaves me with the manual cut and paste solution, which is also tedious.

At this point, my opinion is that MuseScore is not the right tool for this kind of job. I'm not trying to be negative. Software applications are designed for specific tasks, and I expect that any given application might not be able to do what I want it to. But what I'd like to know is: Is there a development roadmap for MuseScore that might show when someone could expect better support for integration of music and text? Because I'll stick around if there's reason to believe this is in the works. But given this discussion thread is 5 years old and we still don't have even word wrap is a serious concern.

Reply

• Feb 7, 2017 - 20:12

What specifically do you find challenging about inserting images into a word processor document? Which word process makes this more complex than Ctrl+V to paste? You can use the built in image capture tool to do the copy within MuseScore. Also look into the MuseScore Example Manager extension for LibreOffice / OpenOffice, which automates the process and provides additional convenience as well (linking the graphic back to the original source file to make it easy to edit, etc).

Anyhow, I'm not saying MuseScore will *never* have more text-processing features, but as you say, it's not really the task for which it is designed, and the general feeling is to focus more on core notation features. Which is why MsueScore has advanced a *ton* in this area over the last five years - advancement that would not have been possible if development resources had been redirected towards trying to re-implement a word processor, or some other functionality not central to the main purpose of MuseScore. Let word processors process words, let MsueScore notate music, and if you need both in the same project, expect to use both tools. It's certainly worth continuing to discuss how these tools can interact better, though. Which is why i'm wondering what specific difficulties you are having. I've produced literally thousands of pages of mixed text and music so I certainly have some insight into the process and can share advice on how to solve whatever problem you are having.

Reply

• Feb 7, 2017 - 20:44

Good suggestions from both of you, and thanks. My specific problem is the repetitive manual process of copying and pasting and the fact that I haven't found a way to automate it yet. For word processing, I'm using Pages on an Apple Mac but I could switch to Debian Linux and LibreOffice if necessary. The MuseScore Example Manager Extension sounds intriguing and I'll dig into that.

I agree it makes sense to let word processors be word processors, and let MuseScore focus on notation. But what I'm really after is some system of tagging or whatever that would let me create one finished merged document (PDF or whatever) from multiple source documents - one or more MuseScore doc, plus one or more word processor documents. It doesn't even have to be a word processor, it could be an XML or tagged plain text file. (I picture such a tool as handling word wrap, which is a fairly trivial algorithm that has been around since before 1980.) This seems like it would be the most efficient end-user solution.

Reply

• Feb 7, 2017 - 23:30

What about copying and paste would you like to automate? As I mention, the LibreOffice extension does a certain amount of it. From within LibreOffice, click a button and a dialog box pops up asking you for the score you want to insert. Then the score is automatically converted to PNG and inserted in the document at the cursor position, with a link back to the original score you can easily go back and edit it. If Pages has a scripting language, you probably reproduce that functionality. But aside from that, it's pretty easy to write a script to convert all scores in a given folder to PNG, so that part is automatable no matter what word processor you use. Then all you need to do is insert the file. But realistically, for simple short examples, the image capture tool is so easy to use, it's easier to just insert images as you go. Not sure what else you'd wanting automation-wise.

Not sure what you mean about the tagging - feel free to flesh out that idea here. I did "Mastering MuseScore" in LaTex, with all images saved as PNG files, and then a simple script generates the PDF from that point. Not sure there was any real advantage in this over just inserting the images into a Word document or whatever, but it worked fine.

As for implementing word wrap within MuseScore, in principle it's not that difficult. Qt can tell us what we need to know in order to figure out if a word fits, and we can then add line breaks as needed. But then next thing people will want is automatic hyphenation, that is an extra level of complexity. Then people will want their nicely word wrapped text to flow from one page to the next like a word processor- word wrap is not all that useful without this. And then they'll want user-defined text boxes of any shape and size, with definable borders. And of course, heading and paragraph styles that can be customized and applied. And search and replace, and spell check, and so on and so on. I'm not saying *none* of this is worth doing, but given that the task of producing an actual text book will probably requiring *all* of these features, I still suspect it's going to work better to just use a word processor.

Reply

• Feb 8, 2017 - 01:47

I must say I really disagree with this view (i.e. Marc's concern about editing feature creep). I don't think that implementing a minimal level of word wrap would suddenly have people clamoring for a full-blown embedded word processor. I would be delighted with the simplest capability, and I would promise never ask for hyphenation, pagination, etc. I disagree that word-wrap is not useful without those things. The type of document the poster describes, with lots of notation but with some interspersed text, is really quite a common need, and something that I view very differently from the type of document I'd construct with a text-oriented system.

I have used MuseScore to make *many* such documents, in which I manually assemble text frames to explain the harmony or fingering or other aspects of the exercise being notated. Doing this is somewhat annoying, but it is still vastly preferable to cutting and pasting images exported from MS, because my active editing process is mostly concerned with the notation rather than the text. The notation keeps evolving. I don't want to keep exporting it. That's because the notation isn't used to illustrate the text (in which case I'd use a document processor); rather, the text is used to explain the notation. So I create these documents 100% in MuseScore.

Here's the thing: The simplest and most trivial phone apps and desktop widgets give us word wrap on text boxes (without hyphenation or pagination). Users have come to expect this functionality from a text box. At least I have.

Reply

• Feb 8, 2017 - 02:06

FWIW, I wasn't saying that implementing word wrap would cause people to clamor for more or that we shouldn't do it. I am saying that people would soon discover that the mere existence of word wrap won't suddenly make MuseScore suddenly better suited *for the task of producing a textbook* than an actual word processor. There are too many other features that would still be missing. So people who are producing textbooks would *still* be better off using a word processor even if we added word wrap, I am quite convinced.

But word wrap is perhaps unique among all of those features I mentioned in that it would *also* useful for plain old regular sheet music. So to me, *that* would be the reason to implement it. Not to make life easier for textbook writers, but to make life easier for people producing sheet music.

I suspect Qt might even provide a native textbox widget we would be able to use, except we also provide a number of special shortcuts (like how we handle special musical characters). And we also like having our regular text boxes seem consistent with lyrics editing or chord symbol editing, which definitely need lots of special handling. Right now we are literally having to process every keystroke one at a time, including things like cursor motion, selection, etc. If it's possible to reduce reliance on our own home-grown text elements, that would be great!

Reply

• Feb 8, 2017 - 02:37

If nothing else, this discussion is at least making me think more about what I really want. And I'm realizing I haven't thought it out completely. But I still have some thoughts.

I kind of want the best of both worlds, word processing (WP) and MuseScore (MS) notation, in some kind of flexible system that lets me intersperse text and notation. What I imagine, then, is a set of source files consisting of one or more WP files and one or more MS files, and a "compile" step (for lack of a better word) that outputs a final document in some format, probably a WP file containing music notation images from the MS files.

When I mentioned tagging before, I meant that a given block of text in a WP file might have some kind of unique ID so that the compile step could identify the text and place it in the final output appropriately. Perhaps the compile step might take some kind of XML database describing the input files, IDs for text or segments of notation, and how to combine them in the output, sort of a control file. Maybe I'm making this more complicated than it needs to be but I'm not sure how else to provide maximum flexibility.

For those of you hoping I'll jump in and code this, I'm sorry to disappoint you, but I'm old, retired, rusty on coding, and losing my eyesight, so it's unlikely I'd be able to make a significant contribution to this effort.

I'll look at the LibreOffice solution mentioned, and see what else I can come up with. Thanks for the discussion.

Reply

• Feb 8, 2017 - 03:58

Ah, sorry for interpreting that in the most restrictive way. Yes, this makes sense. The multi-media assembly described by Paul is obviously a much bigger undertaking, for a different type of user.

Still, I do think that even a slightly better set of text manipulation tools would go a long way toward meeting many book writers' needs. To create a book today, one is forced to make and paste many small pieces with MS; but just a little more in the way of text handling would let MS create larger chunks of self-contained material, perhaps spanning many pages. These could then be assembled externally via PDF creation tools, rather than having to work with pasting single images (or building up text in MS frames, as I do today).

I also see a continuum between pure sheet music and publication-quality text books, one that includes a variety of teaching materials that seem appropriate for MS. (It's in that middle area, including study notes, classroom materials, annotated scores, etc., that MS is already my tool of choice, despite some usage challenges.)

I suppose one other approach might not involve too much complexity: provide tools for referencing and embedding other document types within a MS document. These would have to be fully-rendered, e.g. PDFS or images, since we don't want to try to interact with an active component on the fly. But being able to insert a printable file in-line, to be refreshed at print time, might address some of Paul's goals. Though this might strike you as too far over the line.

Reply

• Feb 8, 2017 - 17:39

Yes it is these in-between cases - not just sheet music, but not a full-scale textbook - where I see individual features like word wrap being most useful even without page flow, search/replace, paragraph styling, etc. I am constantly putting together handouts, assignments, and tests for my students of 1-2 pages, about 50/50 music and text, and it makes more sense to this completely within MuseScore. Word wrap would be the single most helpful new feature for this type of usage.

Reply

• Feb 9, 2017 - 02:28

I do see a problem with "mission creep" here. We are now saying that word wrap would be the most important feature to have. Until we have it at which point another feature would emerge in "pole position". Rinse and repeat.

I am a chemist by profession and I used to write a lot of reports containing large amounts of chemical formulas. This is exactly the same problem. We used to use a program called "chemtext" which was a word processor specifically written for this purpose. It wasn't a very good word processor and it wasn't a very good chemical drawing program either. So after two years the company took it away from us, gave us a proper chemical drawing tool and made us copy/paste into Word. The reports looked a lot more professional immediately.

Copy/pasting is just not such an enormous burden as to justify going off on missions not related to the core purpose of Musescore. I would generally think that those not-quite-sheet-music-not-quite-text-documents are still easier to do (and to edit!) and will look more professional on a word processor with pasted in scores than on Musescore.

Reply

• Feb 9, 2017 - 07:15

Mission creep is a valid concern.

However, since I create "scores-with-some-text" documents all the time, I can assure you that I will *never* create them by pasting images into a word processor, except in the rare case where I am really creating a text document that needs a bit of music notation as an illustration. For my more normal case of annotated scores, I will instead continue to create MuseScore documents that incorporate manually-justified text boxes. It is a pain in the butt and seems unnecessary; but it is significantly better than the process you describe.

I could provide details on why my particular use case is what it is, but who cares? However I don't think it's so unusual; Marc seems to have similar needs.

Basically I don't buy the argument that (exaggerating for humor) "we should discourage text use by keeping our text handling tools as restrictive as possible." I think that today's naive user, seeing *any* text manipulation tools, will reasonably expect a minimal suite of capabilities based on past experience with other apps. Text wrap seems, to me, a particularly ubiquitous capability. Its absence seems surprising in 2017.

As I look at the sheet music that I use on a daily basis, I see quite a few scores that have significant amounts of text on the page, of various kinds: reference or historical data; technique or performance notes; dedications/introductions/explanations; etc. I think that off-staff text *is* a normal part of sheet music creation. Its omission in MuseScore seems to be due to technical and historical reasons, not because it is outside the range of sheet music creation.

At any rate, providing the ability to embed sub-documents would let us push all the "mission creep" problems out into an external app.

Reply

• Feb 9, 2017 - 17:53

Since I'm the guy with the itch to scratch, I'm pursuing a solution that requires a minimum of coding/scripting, and I think I'm pretty close.

I ought to be able to have one master LibreOffice source document with all my text, and embed some tags or UIDs that identify MS files to convert to PNG/SVG and embed. Then, with a single Python or C++ program, I should be able to copy blocks of text from the source LibreOffice file to an output LibreOffice file, and as the code encounters tags that reference MS files, do a command line conversion to PNG/SVG and embed the result in the output LibreOffice file. I have not looked at the LibreOffice API yet, but that's next on my to-do list.

A question for me, personally, that I have to answer: Do I want to focus on creating music curriculum, or do I want to sidetrack myself with a programming project? The answer is yet to be determined. But I'll at least look at the LibreOffice API before I make that call. If I decide to focus on the music, then I'll likely go with embedding MS output images into LibreOffice. I can at least automate the conversion with a simple bash script.

Assuming I do create something, and assuming it actually has some value, I will of course open source it on github.

Reply

• Feb 9, 2017 - 18:00

azumbrunn mentioned embedding chemistry formulae in WP docs, and I've done similar work in the past with algebraic formulae in Microsoft Word. This might be useful - embedding MuseScore in a word processor via an object API - but it's more than I'm willing to take on.

Reply

• Feb 9, 2017 - 19:17

The "manual step" is clicking a button which pops up a dialog from which you select the score. By any count I imagine, this is fewer clicks than manually typing out a tag followed by the naming of the score. So I can't imagine how your solution would be simpler when it comes to inserting the example. But there are other tradeoffs as mentioned above.

Reply

• Feb 9, 2017 - 19:15

It's a similar idea, but somewhat different in execution. Much simpler for the average use in that no scripts are required, no markup - it's a simple dialog to insert the example. But it does lack one ability Paul's solution would have - the ability to generate a new PDF after a change to one of the MSCZ files that automatically incorporates those changes. Instead, if you do update one of your musical examples, my extension requires you to click the example in the document and hit a button to force it to update. I wanted add a button to automatically update *all* such examples, but a problem I had was identifying which examples are actually inserted and managed by my extension. I'm sure it's not unsolvable, I just didn't bother to deal with that.

On the positive side, though, my extension makes it much easier to actually find the MSCZ file for the example you want to update - you just need to Ctrl+click it in the document and it automatically fires up MuseScore with the MSCZ loaded. Then after making the change, you hit the magic button in LibreOffice and your changes are automatically sucked in. Plus, of course, you get WYSIWYG, which the script solution doesn't have - you just get placeholder tags. Again, that's how I did "Mastering MuseScore" for various reasons (one of which is, I often needed actual *screenshots*, not just the music, and my extension only deals with the music). But I think msot people - myself included - will prefer WYSIWYG given a choice.

So I do think most people - perhaps including Paul - will find my extension to be a superior solution. But they are slightly different, with different pluses and minuses. Paul, if I were you, I'd consider looking at the extension and just adding the "update all" facility, which probably wouldn't take much effort.

Reply

• Feb 10, 2017 - 16:09

I'm trying to get the MS example extension up, but no success yet.

On my Mac, I get an error dialog that it can't convert to PNG. I suspect this is because I didn't install ImageMagick. I can't find IM binaries for the current OSX release anywhere, so I'll have to go with MacPorts or build from source.

So I thought I'd try it on my Debian 8.2 box. I used apt-get to install MS, and unfortunately the latest version in the Debian repo is v1.3, which doesn't appear to have an export to PNG capability at all. I get the same "can't convert to PNG" dialog.

Current plan is to pursue IM on my Mac. But I have to take some time off and actually develop some music notation for a few days. LOL.

Last but most important, I want to thank you all for the good discussion. I swooped in like a newbie cry-baby looking for a free feature, and you all treated me with respect instead of dishing out the ass-whooping I probably deserved. Thanks.

Reply

• Feb 10, 2017 - 17:51

:-) No worries, it's a good discussion indeed.

If you are seeing any mention of ImageMagick, then the problem is you have an extremely out of date version of the extension. The current version doesn't require it, but will not work with older versions of MuseScore. Whereas the old version of the extension does need ImageMagick, but probably won't work with the the current version of MuseScore. Old extension needs old MuseScore (plus ImageMagick); current extension needs current MuseScore (no requirement for ImageMagick).

For the Debian box, even though your distro might only provide 1.3 by default, it's easy enough to a the current version - see the Download link in the menu at right of this page. But for the record, 1.3 *does* export to PNG - it just won't automatically trim the excess white space from the margins, which is what ImageMagick was needed for.

If you have a current version of MuseScore *and* a current version of the extension, it *should* work out of the box on your Mac. So if you are having problems with current versions, give me more info and I can try to help. Like, what version of Mac OS, what version of MuseScore, what version of the extension, what version of LibreOffice. Also, during installation, were you prompted for the location of MuseScore, or what it able to locate it automatically (and possibly got this wrong)? Do you have MuseScore installed in a non-standard location? Any other versions of MuseScore installed that might be getting in the way?

Reply

• Feb 10, 2017 - 18:21

Thanks Marc. I'll focus on my Mac for now, and maybe try the Debian system again later.

MacOSX v10.12.3
LibreOffice v5.2.3.5 - latest from Apple app store
MuseScore v2.0.3.1 - latest from Apple app store
MS Example Mgr v2.0.0 - latest from LibreOffice extensions page

MS is installed in the default location, and is the only MS on this system. When I installed the extension and tried it for the first time, it prompted me for the MS path and already had the path filled in with a default value. I verified this path was correct via a console window, and clicked OK.

I open the Tools menu, select MuseScore Example, select a MSCZ file from the dialog, and immediately get an error dialog from "MuseScore Example Man..." which reads: "unable to convert MSCZ to PNG". (Same behavior on Linux with the older version of the Example Manager, but let's tackle that later.)

Thanks for taking a look at this. If it doesn't need ImageMagick explicitly, then that's a head-scratcher.

Reply

• Feb 11, 2017 - 04:38

My best guess is that something is going wrong and MuseScore is not successfully being invoked at all. If you feel like getting your hands dirty, the exrension is just BASIC source you can access and potentially debug yourself directly from the menu (under Tools, I think).

Reply

• Feb 11, 2017 - 15:57

We seem to be moving in the right direction. After I added the MS path to my PATH variable, I get a slight change in behavior. I select the MSCZ file through the Example Mgr, click OK, and then there's a slight pause - as if it's loading the MS app. But then I still get the exact same error dialog.

Prior to adding to PATH, there was no pause - just an immediate error dialog. So I'm assuming it's at least finding and loading MS now.

Reply

• Feb 11, 2017 - 17:31

As an additional note... After I attempt to add an MS example, and it fails as noted, it leaves a little box with "Mu" written in it, as a sort of placeholder for the example that didn't happen. If I command-click on that, it does actually launch MS with the MSCZ file that I specified. So we know PATH is working, and we know the embedded links are working. It's just the writing to PNG that fails. Is it using some kind of temp directory that needs write permission, or something like that?

Reply

• Feb 11, 2017 - 18:11

As yet another datapoint: I grabbed the MS appimage for my Debian system and tried that. It works flawlessly in that environment. I'll give this a try in production usage over the next week and let you know if I encounter any issues.

It would still be nice to use this on my Mac, as that's my preferred desktop environment (I use the Debian system primarily in console mode). Unfortunately the Mac isn't set up as a dev system, so debugging the extension is probably not going to happen soon. Let me know if you have other ideas to try.

Reply

• Feb 11, 2017 - 18:51

It's been while since I wrote that code, but I'm pretty sure PATH is not supposed to be involved. Note the function call here is to "myShell". That function is one I created, defined elsewhere:

https://github.com/MarcSabatella/MuseScoreExampleManager/blob/master/Ex…

As you can see (?), we don't just search the path - we try to read the location from an INI file we created. That was the purpose of the dialog presented earlier - to ascertain the location and write it to the INI file. Now, the whole INI business is system-dependent, and not having a Mac, I have no way of knowing if my code works. But I thought it did at one time.

See ini.xba for the code that actually manages the INI file. And maybe search your system to see if you can actually find the INI file and check its contents. My read of the code suggests that on Mac it should be in "$HOME/.MuseScore Example Manager".

If you see the correct value there, then I'm guessing that is what the script is trying to run. If you see it run a few moments then stop, it could indicate the operation did run but maybe returned an error code, so it would be worth looking to see if there is any evidence of this - perhaps the PNG file *does* exist, or a temp file was left behind, or the file accessed time on the MSCZ is updated, etc.

Reply

• Feb 12, 2017 - 01:47

The path for the MS example manager INI file is in a typically oddball Mac location:
~/Library/Containers/com.collabora.libreoffice-free/Data/MuseScore Example Manager/msem2.ini
And it looks correct:

# MuseScore Example Manager
mscore=/Applications/MuseScore 2.app/Contents/MacOS/mscore

The path for MS is certainly correct.
I compared it to the Linux INI file and the only difference was the Linux file contained RESIZE=TRUE, which I assume was added because I responded "yes" to a prompt to resize the MS PNG to fit (occured when I got this working on Linux).
Back to the Mac: I deleted the msem2.ini file and tried inserting an example into LibreOffice again. As expected, it regenerated the INI file with the dialog asking me to verify the MS path. But, after regenerating, I still get the "unable to convert MSCZ to PNG" failure dialog. As I mentioned before, it inserts a dummy "Mu" box into the LibreOffice document, and command-click opens MS and takes me to the MSCZ I tried to insert.
Here's the kicker: 'stat'ing the mscz file after attempting to insert it indicates the file was just accessed. And, as I mentioned before, I can generate the PNG on the command line using -o. So... Why would this operation fail in the Example Manager?
I want to check to see if a PNG file is being written somewhere, but I'm not sure where to look. Can you give me a pointer?
I feel like we're getting really close. Remote debugging is a PITA. Thanks for the assistance.

Reply

• Feb 12, 2017 - 22:05

Main reason I can for the operation to fail is something about the way BASIC works on this particular version of LibreOffice for the Mac - maybe syntax for the call changed or something. You could try finding the code I mentioned and debugging it.

The PNG would be in the same folder as the MSCZ I believe - either that or same as the document.

Reply

• Feb 14, 2017 - 16:23

Thanks. I tried it with 1) escaping the space, 2) not escaping the space, but surrounding the whole filepath with double quotes, and 3) same as 2 but escaping the double quotes. In all three cases, when I attempted to add an MSCZ, I got an error dialog from MS Example Manager saying it could not find MS. (More precisely, it said "FILEPATH not found", where FILEPATH was whatever string I had set in the INI file.) And that error was followed by the "unable to convert MSCZ to PNG" dialog.

If I go back to the INI as shown in my previous post (no escapes or quotes), then there is a slight delay before the "unable to convert..." dialog, and the MSCZ file access time gets updated. So I think the syntax of the INI is correct - it's finding MuseScore and attempting to export to PNG, but it's unable to do so.

After the operation fails, there is no temp *.PNG file, in either the INI folder or the MSCZ folder.

I'll try to at least take a closer look at the source code soon, but I haven't coded in BASIC for years, and my Mac isn't set up as a dev environment. I assume you're using the equivalent of a C exec() call to launch MS with the command line args to export to PNG. If it's like C, exec() is really fastidious about how it's invoked.

Reply

• Feb 14, 2017 - 17:17

The nice thing about BASIC is how natural-language it is, I doubt you'll have trouble following the logic. And you don't need anything special as far as development environment goes - everything you need is built into LibreOffice.

I believe I am using the equivalent of shell(), not exec(). Different sets of issues, but sure, I have no doubt that somehow whatever I am doing there is not working on Mac for whatever reason.

Reply

• Feb 14, 2017 - 18:32

Okay, I found "Debugging a Basic Program" in LibreOffice help, let me read through that.

In the meantime, I've done a 'find . -name \*-1.png' from my home directory and did not find any PNG output, so I suspect the output to PNG is failing somehow. In the myShell() call, what is the second parameter, the '6'? There are 7 space-seperated arguments to mscore, so I was suspicious. But then it would fail everywhere, so I'm still inclined to believe it's a path issue.

Reply

Do you still have an unanswered question? Please log in first to post your question.