Closed mss2221 closed 5 years ago
Post the MIDI output from the verovio toolkit (in base64 format) and the original input to verovio. This is necessary to determine if the problem is in verovio or in the MIDI player. A scale would be a useful test input:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="4.0.0">
<meiHead>
<fileDesc>
<titleStmt>
<title />
</titleStmt>
<pubStmt />
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2019-02-16T12:29:51" version="2.1.0-dev-b1216de-dirty">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workList>
<work>
<title />
</work>
</workList>
</meiHead>
<music>
<body>
<mdiv xml:id="mdiv-0000000066504651">
<score xml:id="score-0000000276415737">
<scoreDef xml:id="scoredef-0000000982432722" midi.bpm="400">
<staffGrp xml:id="staffgrp-0000000452409736">
<staffDef xml:id="staffdef-0000002111283780" clef.shape="G" clef.line="2" n="1" lines="5">
<label xml:id="label-0000000223140406" />
</staffDef>
</staffGrp>
</scoreDef>
<section xml:id="section-L1F1">
<measure xml:id="measure-L1" right="end" n="0">
<staff xml:id="staff-0000000131587311" n="1">
<layer xml:id="layer-L1F1N1" n="1">
<note xml:id="note-L2F1" dur="4" oct="4" pname="c" accid.ges="n" />
<note xml:id="note-L3F1" dur="4" oct="4" pname="d" accid.ges="n" />
<note xml:id="note-L4F1" dur="4" oct="4" pname="e" accid.ges="n" />
<note xml:id="note-L5F1" dur="4" oct="4" pname="f" accid.ges="n" />
<note xml:id="note-L6F1" dur="4" oct="4" pname="g" accid.ges="n" />
<note xml:id="note-L7F1" dur="4" oct="4" pname="a" accid.ges="n" />
<note xml:id="note-L8F1" dur="4" oct="4" pname="b" accid.ges="n" />
<note xml:id="note-L9F1" dur="2" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
<fermata xml:id="fermata-L9F1" staff="1" startid="#note-L9F1" place="above" />
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>
Thanks. I'm afraid I don't know how to go about getting the midi output in base64, though. Could you let me know how I could do that so I could post what you need? And by input to Verovio, you mean the .mei file, yes?
And by input to Verovio, you mean the .mei file, yes?
Yes (unless you are using MusicXML, Humdrum, or Plaine and Easie data as input).
From the page:
https://www.verovio.org/tutorial.xhtml?id=topic09
Change the function:
function play_midi() {
if (isPlaying == false) {
var base64midi = vrvToolkit.renderToMIDI();
var song = 'data:audio/midi;base64,' + base64midi;
$("#player").show();
$("#player").midiPlayer.play(song);
isPlaying = true;
}
}
To
function play_midi() {
if (isPlaying == false) {
var base64midi = vrvToolkit.renderToMIDI();
console.log("MIDI data is:", base64midi);
var song = 'data:audio/midi;base64,' + base64midi;
$("#player").show();
$("#player").midiPlayer.play(song);
isPlaying = true;
}
}
Then in the console for your web browser (probably openable with command-option-j or command-option-i in MacOS, or command-alt-i on windows/linux), copy and paste the MIDI data into the issue.
Ok, thanks. Using the scale file provided above, I get the following:
MIDI data is: TVRoZAAAAAYAAQACAHhNVHJrAAAACwD/UQMCSfAA/y8ATVRyawAAAEUAkDxAeJA8AACQPkB4kD4AAJBAQHiQQAAAkEFAeJBBAACQQ0B4kEMAAJBFQHiQRQAAkEdAeJBHAACQSECBcJBIAAD/LwA=
Here is a textual version of the MIDI file from the base-64 string that you sent:
"MThd" ; MIDI header chunk marker
4'6 ; bytes to follow in header chunk
2'1 ; file format: Type-1 (multitrack)
2'2 ; number of tracks
2'120 ; ticks per quarter note
;;; TRACK 0 ----------------------------------
"MTrk" ; MIDI track chunk marker
4'11 ; bytes to follow in track chunk
v0 ff 51 v3 t400 ; tempo
v0 ff 2f v0 ; end-of-track
;;; TRACK 1 ----------------------------------
"MTrk" ; MIDI track chunk marker
4'69 ; bytes to follow in track chunk
v0 90 '60 '64 ; note-on C4
v120 90 '60 '0 ; note-off C4
v0 90 '62 '64 ; note-on D4
v120 90 '62 '0 ; note-off D4
v0 90 '64 '64 ; note-on E4
v120 90 '64 '0 ; note-off E4
v0 90 '65 '64 ; note-on F4
v120 90 '65 '0 ; note-off F4
v0 90 '67 '64 ; note-on G4
v120 90 '67 '0 ; note-off G4
v0 90 '69 '64 ; note-on A4
v120 90 '69 '0 ; note-off A4
v0 90 '71 '64 ; note-on B4
v120 90 '71 '0 ; note-off B4
v0 90 '72 '64 ; note-on C5
v240 90 '72 '0 ; note-off C5
v0 ff 2f v0 ; end-of-track
All of the notes are present, and the first one is middle-C (MIDI note 60). So it is a problem with playback in the MIDI player rather than a problem with generating of the MIDI file with verovio.
There are two possibilities for the source: (1) Either there is a problem with your computer configuration (OS and browser). If you can post what type of computer and web browser you are using, that would be useful. It would also be useful if you can try it on a different computer and/or web browser to see if the problem remains. If so, then possibility number two below is more likely.
(2) There is a bug in the javascript MIDI player's initialization process. @lpugin can check that out. I am using an older version of the player from two years ago, and the initial note is not missing, so if there is a problem, then it would have appeared after that time.
I encounter a similar problem with the QuickTime 7 MIDI player in MacOS. The first note is not played in a MIDI file when it is first loaded. Playing the same MIDI file again (while keeping the player open) results in the initial note being played correctly. The problem in this case is that the program is doing some sort of initialization when first playing the file, and it misses the note on command of the first note. A similar thing is happening to you -- but it could be hidden in one of the two places that I mentioned above. @lpugin might be able to track down the problem in the MIDI player. There is a related issue in the repository for the player: https://github.com/rism-ch/midi-player/issues/6 Stuttering may be a similar symptom of initialization overload when starting the MIDI file. The problem in this case and probably yours is that some processing thread is being created or woken up, and other processes on the computer have more priority that then one playing the MIDI file. This would make the problem apparent on some computers/web browsers but not on others.
Thanks for all the info Craig. I appreciate it. I have the same problem regardless of computer (mac and pc), but so far I have only been able to use Verovio on Firefox. (The tutorial mentions the need for running a server to pull up the files on Chrome. My pages are just copies of the tutorial page, so I don't know yet how to get them to display in another browser without the server method. But I will try to open the pages in Chrome by connecting to a local server and see what happens.)
I have noticed stuttering on some files, so this initialization problem could well be the cause.
Is this something I can ask Laurent Pugin to look into? I appreciate the guidance & patience...
The older version of MIDI player is working for me on Firefox, Chrome, Safari, and Opera on MacOS 10.13.6. In general Firefox will be much faster with Javascript code than Chrome, so it is not likely that using Chrome would fix the problem (but you never know).
Is this something I can ask Laurent Pugin to look into?
He should already know about the problem, as he gets an email whenever someone posts to verovio issues :-)
FYI: There seems to be a quite similar issue with MIDI in music 21, see e.g. here:
.show('midi')
(#330 ) And also in other repos: mudcube/MIDI.js: First note not played (again) #165
Yes, many systems have bugs in MIDI playback. For example, the Window's media player usually has the opposite problem of the last note(s) in the MIDI file being clipped. In the case of JavaScript and Python, which are interpreted languages, they use external libraries to access the computer's speakers/headphones. Javascript has an additional complexity since the main interface is single-threaded.
There will be some initialization process either from within the calling language, or in the compiled library and/or hardware drivers that plays the MIDI. One way of avoiding the problem is as @mss2221 is currently solving the problem: stick in a note that will be cause the initialization but get lost. The problem is that on my setup, I am not getting the lost note, so I would hear such an extra note (so inserting an invisible rest would be better if it works).
If verovio could add some sort of pause after initializing the MIDI player but before sending any notes to the player, that might solve the problem. For example, first initialize the webaudio system and load the soundfont. If there is a callback to inform the main thread that this is ready, then use that; otherwise, have a setTimeout()
function call to wait a certain amount of time before sending the MIDI data (perhaps 100 or 250 millisecond pause) to estimate when the MIDI/audio setup has finished.
so inserting an invisible rest would be better if it works
Related to this, you could try playing this MIDI data:
TVRoZAAAAAYAAQACAHhNVHJrAAAACwD/UQMCSfAA/y8ATVRyawAAAEUekDxAeJA8AACQPkB4kD4AAJBAQHiQQAAAkEFAeJBBAACQQ0B4kEMAAJBFQHiQRQAAkEdAeJBHAACQSECBcJBIAAD/LwA=
I added a 16th note delay at the start of the file. If that plays correctly on your setup (without missing the first real note), then one possibility would be for verovio to add such a delay at the start of the MIDI file (probably as an option since it may not always be desirable to have a delay hard-coded into the MIDI file).
I like the idea of a hidden rest instead rather than a hidden note. I'll do that for now.
A delay would be great, because then the mei would still be a faithful rendition of the notated score.
I don't know how I would get the midiplayer to play that string, unfortunately, so I can't test it out. I'm still just copying and pasting to create these pages, so I still don't understand a lot of what is going on under the hood. (I know the basics of html, but not javascript.) So there is an older version of this MIDI player? I'll have to look for that maybe.
I have also been getting the last note cut off when I try to play the MIDI data. That is less critical, though. But good to know, since I thought that was a mistake I was making in my mei.
I like the idea of a hidden rest instead rather than a hidden note. I'll do that for now.
That would be something like:
<space dur="16">
That will add extra a visual space to the music, so not ideal (but so does an invisible note).
Here is how to play the test MIDI file:
function play_midi() {
if (isPlaying == false) {
var base64midi = vrvToolkit.renderToMIDI();
base64midi = "TVRoZAAAAAYAAQACAHhNVHJrAAAACwD/UQMCSfAA/y8ATVRyawAAAEUekDxAeJA8AACQPkB4kD4AAJBAQHiQQAAAkEFAeJBBAACQQ0B4kEMAAJBFQHiQRQAAkEdAeJBHAACQSECBcJBIAAD/LwA=";
var song = 'data:audio/midi;base64,' + base64midi;
$("#player").show();
$("#player").midiPlayer.play(song);
isPlaying = true;
}
}
No matter what music you try to play, the scale (with the added pause) will be played instead 😄
So there is an older version of this MIDI player? I'll have to look for that maybe.
I just copied it two years ago as your are doing now :-). I will test the newest version later today or tomorrow perhaps, since I have been meaning to update the MIDI player version that I am using (unless it is eating the first note). I notice that I need to copy the midi player to a web server, @lpugin. It would be nice if the wildwestmidi.data file were not hard coded into the script, then I would not need to copy the MIDI file player, but just use it from github directly.
Thanks. That MIDI string goes by too fast for me to tell for sure, but I don't think it is playing that C. But the <space>
works great. At the beginning of the staff, dur="16" is not noticeable at all.
Thanks for all your help today. I can get back to work on my project now!
I downloaded the MIDI tutorial setup and ran it locally. I am getting all of the notes to play, including the first one (using macOS 10.13.6 and Chrome 72). Here is a zip file containing a .MOV video file that records the behavior:
Here is an animation without the sound (unzip the above file to get the audio):
However, I am getting two problems:
(1) The last note is never highlighted. When the music is slowed down to quarter-note at 50 beats/minute, the problem goes away. The problem seems to be related to the notes being highlighted about 250 milliseconds before the audio is heard. This misalignment of the highlighting and the sound was also present two years ago in the MIDI player (it would be useful to figure out how to get rid of it, as it is distracting). This problem could be related to the next one (where there is a 200 ms glitch in the sound when replaying the MIDI file). In other words, this problem is probably caused by a frame-buffer delay: the WildWebMidi interface fills an audio buffer and then sends it to the webaudio interface. The note is probably highlighted when the buffer is starting to be filled (or in the process of filling), so the highlight is seen first followed after a short wait by the audio which finally ends up at the computer speakers.
(2) When I replay the file, there is a little glitch in the sound. A piece of sound from the end of the previous playback is not cleared from the audio buffer. The defect is 50 milliseconds long and repeats a total of four times, or 200 millisecond (but is not an exact digital copy each repetition). The problem in this case is that the audio buffers need to be cleared before playback starts (you should notice that the pitch of the startup glitch is at the same pitch as the last note). This is either a bug in WildWebMidi where it should automatically clear the audio buffer after finishing playback, or in how the verovio interface to it interacts with it (maybe there is a audio buffer clearing function that should be called, for example). In general, this should be the responsibility of WildWebMidi. This is the cause of the stuttering at the start of playback (unless the stutter happens at the very first playback).
That MIDI string goes by too fast for me to tell for sure, but I don't think it is playing that C
You can slow it down by changing the tempo in the scoreDef, which is currently 400 quarter notes per minute:
<scoreDef xml:id="scoredef-0000000603603689" midi.bpm="400">
In any case there are 8 notes, and the first one should be the tonic scale degree 😛
Test MEI data:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="4.0.0">
<meiHead>
<fileDesc>
<titleStmt>
<title />
</titleStmt>
<pubStmt />
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2019-02-18T09:47:44" version="2.1.0-dev-0251fbc">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workList>
<work>
<title />
</work>
</workList>
</meiHead>
<music>
<body>
<mdiv xml:id="mdiv-0000000054452595">
<score xml:id="score-0000000356730543">
<scoreDef xml:id="scoredef-0000000603603689" midi.bpm="400">
<staffGrp xml:id="staffgrp-0000001529100764">
<staffDef xml:id="staffdef-0000001265577945" clef.shape="G" clef.line="2" n="1" lines="5">
<label xml:id="label-0000001046726995" />
</staffDef>
</staffGrp>
</scoreDef>
<section xml:id="section-L1F1">
<measure xml:id="measure-L1" right="end" n="0">
<staff xml:id="staff-0000000619531889" n="1">
<layer xml:id="layer-L1F1N1" n="1">
<note xml:id="note-L2F1" dur="4" oct="4" pname="c" accid.ges="n" />
<note xml:id="note-L3F1" dur="4" oct="4" pname="d" accid.ges="n" />
<note xml:id="note-L4F1" dur="4" oct="4" pname="e" accid.ges="n" />
<note xml:id="note-L5F1" dur="4" oct="4" pname="f" accid.ges="n" />
<note xml:id="note-L6F1" dur="4" oct="4" pname="g" accid.ges="n" />
<note xml:id="note-L7F1" dur="4" oct="4" pname="a" accid.ges="n" />
<note xml:id="note-L8F1" dur="4" oct="4" pname="b" accid.ges="n" />
<note xml:id="note-L9F1" dur="2" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>
Thanks for all this.
So when I play that scale at 400bpm it sounds out 4 notes, and does not highlight the last one.
Setting midi.bpm=50
highlights all the notes, including the last one, but still won't play that first one.
I'm doing this right now on my desktop pc, but I have had the same issue on my mac laptop. I will double check this scale file again on the mac.
I thank you for all this digging into the issue. I wish I understood better what to do about the issues you cite. But what I gather is that this is not a Verovio issue but a problem with midiplayer.js and wildwebmidi.js, right?
But what I gather is that this is not a Verovio issue but a problem with midiplayer.js and wildwebmidi.js, right?
Yes, the order of software dependence is:
The problem could be occurring at any one of these levels. The only solution that is possible at the moment is for verovio to add an option for an initial pause before playing the MIDI file (since <space>
works for you). However, that treats the symptom rather than cures it since the problem lies further down the software food chain and behaves differently on different computers.
I'm doing this right now on my desktop pc, but I have had the same issue on my mac laptop.
You mean that you are using Microsoft Windows 10 on the desktop PC? That would be strange if they both behave the same, since I do not have the problem on an apple laptop. I would expect Windows to perform worse, as their audio latency is historically bad, although I see on the web they are trying to address this in Windows 10: https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
The problem you are describing (only 4 notes playing) means there could be a 600 millisecond audio buffer somewhere, and it could be that the first audio buffer is being dropped when starting playback. My setup sounds like it is using a 50 millisecond audio buffer in WildWebMidi, but then expands to 200 milliseconds either in web audio or when going into the sound drivers for the operating system.
How do these work on your computers: http://www.ccarh.org/haydn/op20n5/mvmt2 http://www.ccarh.org/haydn/op20n5/mvmt2v (press the space bar or click on the play button in the lower left corner of the window). There should be a little breath from the 1st violinist at the start to set the tempo. Here is a zip with a .MOV video recording of the first system of music on my computer:
These webpages use the <audio>
/<video>
player in Javascript:
https://www.w3schools.com/html/html5_audio.asp
https://www.w3schools.com/html/html5_video.asp
which were implemented before webaudio, and I have not had a problem with them, and the alignment of highlighting and audio seems correct.
Yes: for that scale mei file, I have the same problem on my Windows X desktop pc and my mac osX laptop. I just get 4 notes. And both cut off first note on mei files in general-- when playing them using the tutorial file as a template. On my mac, even at <40bpm, the first note of the mei scale does not play.
Your links to the Haydn work perfectly on both systems!
I appreciate all the info. I wish I were knowledgeable enough to make use of it! Those links to the javascipt players you provided--you are suggesting that I get verovio to output MIDI that will be played by one of those players instead of the midiplayer used in the tutorial file. Is that right?
I wish I knew more javascript. But I will try to figure out how to do that. Thanks.
you are suggesting that I get verovio to output MIDI that will be played by one of those players instead of the midiplayer used in the tutorial file. Is that right?
No, but if anyone can get another one working that does not have a problem for your computer, that might be a good one to switch to. @musicEnfanthen says above that the mudcube midi player has a similar problem, so switching would not necessarily solve the problem (i.e., it could be a problem related to webaudio which all javascript MIDI players must use).
There is a Web MIDI API: https://webaudio.github.io/web-midi-api but this seems to only work for external hardware MIDI synthesizers. I tried it today in Chrome, and it did not list any MIDI output ports, so it looks to be useless in this sort of case.
Since the Haydn examples work on your computer, then it is less likely to be a problem with the operating system or sound drivers. And since I doubt that <audio>
and <video>
elements are implemented through webaudio, the most likely problem is within the webaudio interface, and possibly with WildWestMidi's use of that interface. (And having the same problem in Windows and MacOS also points towards a problem within the web browser).
When I run the MIDI tutorial locally, I can reproduce the error (only 4 notes played, no sync between audio and highlighting, "glitch" effect after replay). In the online tutorial, only the first note is cut off, everything else works fine. And in the MEI viewer (online), there is none of the problems at all.
When I run the MIDI tutorial locally, I can reproduce the error (only 4 notes played, no sync between audio and highlighting, "glitch" effect after replay). In the online tutorial, only the first note is cut off, everything else works fine. And in the MEI viewer (online), there is none of the problems at all.
Strange. One would think that a local version might behave the best, but it is the worst fo you.
How are you (@musicEnfanthen and @mss2221) running the example locally? I was using the gh-pages-develop branch:
git clone https://github.com/rism-ch/verovio
cd verovio
git checkout gh-pages-develop
There were some files missing from this version of the repository, so I deleted all of the other tutorial files and removed the include reference to the missing file in the 9th tutorial. And then played around with it. I should also try the gh-pages branch version to see if there is any difference.
I have been getting the tutorial from this link on the Verovio site: https://github.com/rism-ch/verovio-tutorial/archive/gh-pages.zip
I get the same set of errors having cloned the repository mentioned above: https://github.com/rism-ch/verovio
. Though the particular gh-tutorials
folder came up empty - I had to download a zip with those files. (It is named differently on the git hub site: gh-tutorial @ e300d51
. I don't understand what is going on there.)
the most likely problem is within the webaudio interface, and possibly with WildWestMidi's use of that interface
So what would be my next steps there? (Besides investigating what it is, exactly, that each of those do...)
I have been getting the tutorial from this link on the Verovio site:
https://github.com/rism-ch/verovio-tutorial/archive/gh-pages.zip
I downloaded the tutorial from that file and ran the example scale, and I am getting the same behavior as you. Four notes are played (the second through fifth notes). Replaying the same music reproduced the same result. In the following video, there is no glitch at the beginning of the music, but I ran the same setup a few minutes before and it did have the glitch. Here is a zip file of the video:
And here is an animated GIF of the video (no sound in GIF images of course):
When I play the same music in Verovio Humdrum Viewer, there is are no glitches or missing notes:
Animated GIF without sound:
It would be interesting for you to copy-and-paste the test scale into VHV and see how it behaves for you. To do so, first go to https://verovio.humdrum.org/?k=e
Then paste the MEI data, and then type alt-m
to switch to MEI mode (I will automate the mode switching at some point). And finally press the space bar or press the "Play" button in the upper right-hand corner of the window to play.
So for me, the zipped tutorial files exhibit a problem (only 4 notes played, missing the first note and the last three notes). Running from the gh-pages-develop branch of the github repository, it is running correctly for me (all notes playing, other than last note not highlighting). In VHV it is playing correctly and the last note is highlighting, although there is a syncing problem between the audio and the highlighting for the first few notes.
If the VHV playback works correctly for you, then I am suspecting mostly a threading problem. If this is the problem, then that means verovio and WildWestMidi are running in the main javascript thread, and they are competing for the same computing resources. So when they both start they are both requiring more computer time for initialization at the same time than the thread is able/willing to provide them.
In the more recent version of verovio (as used in the gh-pages-develop version of the tutorial), the computational demands of verovio have probably decreased compared to the gh-pages or zipped version of the tutorial. I have not looked at the differences between the two, but I would guess that the gh-pages version is somehow re-typesetting the music at the same time that the MIDI playback is started, and in the gh-pages-develop version the music is not being retypeset (as it should not be necessary).
VHV works great with all my MEI files. I noticed that little syncing problem on the scale, but on the larger files it looks good.
That is very interesting to know. I will get the gh-pages-develop version of verovio and see how that works. I will makes some time to do that tomorrow and let you know what happens.
Do you know why the folder gh-tutorial might be empty when I clone the repository and checkout the gh-pages-develop branch?
When I clone separately the folder gh-tutorial @ e300d51
that is in that gh-pages-developer branch, I get the same errors. Do you know what I am doing wrong here, or how I can get the updated version of the tutorial?
The @
sign after the directory name on the github website indicates that the directory is a module that pulls files from a different git repository. This means that you have to add the --recursive
option when cloning the git repository:
git clone --recursive https://github.com/rism-ch/verovio
This should also download the files that should be in gh-tutorial. If you want to download the files for the module after cloning the verovio repository type these command inside of the verovio directory:
git submodule update --init --recursive
After doing this I can see the files expected in gh-tutorial. Once the files have been downloaded, you can run jekyll to serve the website locally:
jekyll serve --watch
The --watch
option will update the website on the local server if you change a file while the server is running. Also add --incremental
if you make changes often. The website will be available at http://127.0.0.1:4000, or the MIDI tutorial demo: http://127.0.0.1:4000/gh-tutorial/topic09-midi.html
However, before running jekyll, you will need to edit _config.yml
and change the line:
baseurl: "https://www.verovio.org"
to
baseurl:
Interestingly, this is producing the same error for me: the first note does not play. The git clone didn't go exactly as you described above. Using this command:
git clone --recursive https://github.com/rism-ch/verovio
I did not get the gh-tutorial file. Then I entered:
git checkout branch gh-pages-develop
and I got the gh-tutorial folder, but again it was empty. I got the files with the other command you provided:
git submodule update --init --recursive
and that gave me the tutorial. I ran the site with Jekyll (which I had not been doing), and I get the same error regardless of what mei file I load. Can you see something I may be doing wrong?
I am using the Verovio tutorial to learn how to display mei in my webpages. It seems like the midi example, topic09, is not working quite right. The first note does not get played--regardless of what mei file is loaded. The example works fine if an initial note is inserted into the mei with @visible="false". I was wondering if anyone else noticed this. Thanks.