On 2021-10-30 5:02 pm, Wol wrote:
On 30/10/2021 08:42, Pablo Cordal wrote:
The problem: WMP blocks the midi file while (and after) it's playing,
so if I modify something in lilypond and I want to hear it, I have to
close WMP, then compile, go to the folder and reproduce again.. and
I'm composing so I do it a LOT of times.
Except that's NOT the problem. The problem is that WINDOWS locks the
file against writing if anything else has it open. You need to get WMP
to drop the file.
Only if you instruct Windows to do so. See [1] where you may call
CreateFile with GENERIC_READ and FILE_SHARE_WRITE. (In practice, you
probably want the trifecta of FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE to be most permissive.)
[1]:
https://docs.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-files
I have exactly the same problem with Acrobat Reader - if I'm viewing a
score I can't run lilypond until I close Acrobat, otherwise it just
fails on me because it can't overwrite the pdf.
I run SumatraPDF which is able to display a PDF without causing Lilypond
to fail to write to the file at a later time. In fact, it is also able
to detect such changes and redisplay its contents. None of this is
special to Sumatra though, so there could be other PDF viewers that are
similarly well-behaved.
One of the main issues with proprietary software is that we cannot
review or audit Adobe's programming decisions. They very well may have
a good reason to hold onto file handles that block writing, but such a
reason will be a mystery.
NOTE: I just discovered that WMP no longer blocks file I/O like it used
to. Not sure when the behavior changed, but it seems that I can keep
WMP open and regenerate the MIDI file. I am running 20H2/19042.1288 for
reference.
-- Aaron Hill
