Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Keyboard braille: a measure wider than one line aborts the whole transcription (no measure division, unlike the single-part path)

オープン
  • 何か問題がありますか？
#1,985 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
python
領域
backend

調査の方向性

Start in braille/text.py at BrailleKeyboard.addNoteGroupings and compare the keyboard path with BrailleSegment.extractNoteGrouping and splitNoteGroupingAndTranscribe in braille/segment.py. Reproduce with a two-part keyboard score containing a measure wider than maxLineLength, then trace the exception through braille.translate.keyboardPartsToBraille. Done means the measure is split at a beat across lines with the music hyphen, and the score transcription completes.

索引モデルが issue の本文から書いたものです。

説明

Environment: music21 10.5.0, Python 3.14, macOS.

Summary: In the keyboard (bar-over-bar) braille path, a measure whose one-hand transcription is wider than one braille line aborts the whole transcription — BrailleKeyboard.addNoteGroupings (braille/text.py) opens a fresh line pair and then calls append unconditionally, which raises BrailleTextException("Text does not fit at end of braille text line."); the exception propagates out of braille.translate.keyboardPartsToBraille and no braille is produced for the entire score.

Expected: the Braille Music Code's own device for this case — divide the measure at a beat and continue on the next line with the music hyphen (dot 5). The single-part path implements exactly this (BrailleSegment.extractNoteGrouping → splitNoteGroupingAndTranscribe in braille/segment.py); the keyboard path has no split at all (the commented-out method stubs near BrailleGrandSegment.extractNoteGrouping suggest it was left unfinished).

Impact: dense piano is untranscribable at the 40-cell embosser standard. In one test set, ~80% of the measures of a Beethoven presto movement exceed the 40-cell line, and a single ~148-cell measure in another sonata blocks the whole score at any tested width up to 100 cells.

Reproduction sketch: any two-part keyboard score with one measure of 16th notes wide enough to exceed maxLineLength (e.g. 20+ notes with accidentals and octave marks in one 4/4 measure), passed to braille.translate.keyboardPartsToBraille(score, maxLineLength=40).

Related keyboard-path findings from the same investigation (happy to split into separate issues if preferred):

  • Measure-repeat consolidation (segment.areGroupingsIdentical) compares notes with __eq__, which ignores Fingering articulations — repeated measures carrying different fingerings consolidate to the first measure's fingering.
  • BrailleGrandSegment.yieldCombinedGroupingKeys drops the first of two consecutive one-hand keys (storedLeft/storedRight is overwritten without being yielded) — whole measures of one hand vanish from the output when the other hand's measures repeat-consolidate.
  • The grand path never emits repeat signs for consolidated measures (unlike the single-part path's addRepeatSymbols), so a consolidated measure is lost rather than compressed.
主要言語
Python
スター
2.6k
フォーク
459
平均マージ
1日 7時間
マージ済み PR（30日）
40

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

cuthbertLab/music21 のほかの issue

cuthbertLab/music21 の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。