musescore / musescore/MuseScore

First note of glissando sometimes doesn't play back when starting playback from that note (MS basic)

Open
#28,128 1 comment 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

P2 playback regression
Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Issue type

General playback bug

Description with steps to reproduce
  1. Create new score, say for violin, and set tempo to 80
  2. Add two crotchets of different pitch on the first two beats of measure 8 and connect them with a glissando
  3. Start playback from the beginning of measure 8 (the first crotchet)

Expected behaviour: Playback starts with the first note of the glissando.

Actual behaviour: The first note is not played back at all (heard best for two notes a semitone apart, where the result is that only the second note is played back, as in the example score). However, if I play back the score from the top, the glissando is played back correctly.

Supporting files, videos and screenshots

Screen recording (mp4 file upload failed, so here is a zipped version):

Gliss-Playback.zip

Score: Gliss-Playback.zip

What is the latest version of MuseScore Studio where this issue is present?

OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.5.2-251141402, revision: github-musescore-musescore-ac9d3bc

Regression

I was unable to check

Operating system

Windows 10

Additional context

I encountered this bug using MS basic audio (no MuseSounds). Which instrument is used does not seem to make a difference.

If the glissando playback style is set to "portamento" instead of the default "chromatic", then playback is as expected.

Also, it seems that timing makes a big difference to reproduce the bug. If the two-note pattern is copied into adjacent measures (as in the example), playback seems to work fine for those, even when playback is started from beat 1 of one of those measures. I experimented with different tempos, and my impression was that in a faster tempo, the measure for which playback fails moves further to the right. Sometimes, strangely enough, changing the tempo marking to something else than 80 and then back to 80 seemed to resolve the issue.

Possibly related to #23052 and #24300.

Checklist
  • This report follows the guidelines for reporting bugs and issues
  • I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
  • I have attached all requested files and information to this report
  • I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.