Peter True Be Know (ptrue) wrote,
Peter True Be Know
ptrue

Category:

На что ушли выходные

Известно, что Finale хранит названия групп нотоносцев в формате текстовых блоков — точно таких же, как и номера страниц, название произведения и так далее. В текстовом формате эти тексты следуют за тэгами ^block и имеют сквозную нумерацию.
     Известно так же, что после оптимизации все названия групп получают независимость: их можно редактировать в каждой системе нотоносцев отдельно, и эти изменения не отразятся на названиях тех же групп в других системах. Что это значит? Это значит, что для каждой системы создаётся дополнительный комплект текстовых блоков, дублирующий основной комплект.
     Допустим, у вас в партитуре имеется 25 именованных групп нотоносцев. (К примеру, партия виолончелей делится на две, вы записываете их на двух нотоносцах, объединяете акколадой и у этой акколады подписываете «Виолоночели» — и точно так же с остальными инструментами.) После того, как вы набрали ноты и перешли в режим вёрстки, у вас получилось, к примеру, 300 систем (речь идёт об объёмном произведении). Вы запускаете оптимизацию, пустые нотоносцы исчезают, оставшиеся получают независимость. Теперь внимание: программа создала 300 дополнительных комплектов по 25 названий групп. Это значит, что в файле появилось 7500 лишних текстовых блоков, всего навсего дублирующих предыдущие.
     Теперь, допустим, вы отредактировали первые несколько страниц, изменили вёрстку, помеяли количество тактов в системах, и теперь заново оптимизируете документ. Finale снова создаёт 7500 дополнительных текстовых блоков. Почему она не использует уже существовавшие до этого? Потому что она знает, что при оптимизации нужно скопировать названия групп из основного комплекта. Тем фактом, что оптимизация до этого уже проводилась, и копия комплекта для каждой системы уже имеется, она пренебрегает. Вернее, она считает, что предыдущая копия уже не нужна, и удаляет её. Таким образом, размер файла при последующих оптимизациях не увеличивается, как это происходит в самый первый раз. Просто 7500 текстовых блоков встают на место предыдущих 7500. Однако номера новых блоков следуют за удалёнными, а не замещают их.
     Таким образом мы имеем:
Блоки 1–25 — основной комплект,
блоки 26–7525 — пропуск; блоков с этими номерами не существует,
блоки 7526–15026 — копии блоков с названиями групп для каждой системы после второй оптимизации.

     Если вы привыкли работать страница за страницей, то при размере партитуры в 300 систем (это может быть от 100 до 300 страниц), вы захотите проделать оптимизацию ещё очень много раз. Возможно, все 300. И наверняка вы будете оптимизировать не только ту систему, с которой сейчас работаете, но и все последующие. Однако уже после четвёртой оптимизации нумерация текстовых блоков в файле достигнет 30 000, а пятой оптимизации... может не быть. Дело в том, что на хранение номера текстового блока Finale выделяет два байта, и почему-то хранит его как значение со знаком. Это означает, что максимальное значение номера может быть 32 767. При попытке создать ещё один новый блок, ему присваивается отрицательный номер -32 768, и программа сходит с ума: все тексты в партитуре вдруг пропадают, а после отмены и восстановления последней операции при попытке сохранить файл программа виснет, дойдя до 99%, старый файл оказывается стёрт, а новый не записан. Все ваши 300 страниц партитуры идут коту под хвост.

     Что я сделал. Во-первых, я сохранял отдельную копию своей работы каждый день, а когда заметил, что с программой что-то неладное, то стал сохранять копию через каждые несколько операций — именно отдельную копию в новом файле, а не запись поверх старого файла. Таким образом, вероломное поведение программы не вызвало потери данных. Однако оно приостановило работу, поскольку без оптимизации работать с симфонической партитурой невозможно, а до того момента, когда оптимизация приводит Finale в исступление, я уже дошёл на 20-й странице (впереди ещё около 150).
     Во-вторых. После того, как начались трудности, я проанализировал файл, выявил всё, что написано выше и написал программу на Jave, которая отыскивает пропуски в нумерации текстовых блоков в файле, и перекидывает на пропущенные номера блоки с бóльшими номерами, а затем исправляет ссылки на эти блоки из других элементов партитуры. Дополнительная загвоздка возникла из-за того, что начиная с версии 2004 в Finale текстовые обозначения (Text expressions) стали храниться примерно так же, как и текстовые блоки, но с параллельной нумерацией. Однако удалось найти флажок, который показывал, на что ссылается элемент — на блок или на обозначение, и исправлять только нужные ссылки.
     Таким образом, сейчас номер последнего текстового блока в моём файле — около 4500. Однако этого хватит всего на несколько оптимизаций, а потом снова придётся пропускать файл через мясорубку моей исправительной программы. Не очень весело, но работать можно.
     Если кто-то столкнулся с похожей проблемой, то обращайтесь — приведу программу в товарный вид и поделюсь.
Tags: bug, finale, layout, notovodstvo, text block
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 17 comments