16.08.2003
26. Откуда берётся ранжир?
История этого дела такова.
Гравировщик наделяет каждую вертикаль нотного текста (длительность) горизонтальным пространством исходя из общей ширины строки. Если сильно упростить процесс и рассмотреть случай, когда строка состоит только из нот одинаковой длительности, то можно сказать, что пространство, выделенное для каждой ноты, будет равняться ширине строки, поделённой на количество нот в ней. Всё это так.
Откуда же гравировщик знает, сколько именно нот ему нужно поместить в строку? Иными словами, каким образом осуществляется разбиение сплошного нотного текста на строки? Можно ответить так: гравировщик прикидывает, сколько тактов может поместиться в данной строке, и делит текст в соответствии с этими прикидками. Но для того, чтобы знать, сколько тактов (или сколько нот) поместится в строке, нужно хотя бы примерно предполагать, сколько пространства полагается отвести для каждой ноты.
Получается заколдованный круг, или, выражаясь математическим языком, рекуррентная зависимость: мы выделяем пространство для нот, исходя из их количества в строке, но количество нот в строке определяем, исходя из занимаемого ими пространства. Для того, чтобы вырваться из этого круга, нужно ввести какую-то абстрактную меру пространства, не зависящую от длины строки и количества нот в ней.
В разных нотаторах эта абстрактная мера устанавливается по-разному. В то же время, во многих нотных редакторах имеется режим «ленточного» просмотра, где ноты не делятся на страницы, а отображаются одним непрерывным целым,— то, что в Finale называется Scroll View.
Логично было бы предположить, что именно в этом режиме мы видим «истинный ранжир», выполненный на основе абстрактной меры, а не из расчёта длины строки. Как же обстоит дело на самом деле?
Finale
Что касается Finale, то да, в этом режиме мы видим ранжир, не продиктованный длиной строки. Однако назвать его «истинным» язык не поворачивается. Дело в том, что в Finale в основу ранжира положено не пространство, выделяемое для отдельной ноты или вертикали нотного текста, и даже не длина строки. Основой ранжира в Finale является ширина такта.
Таким образом, происходит вот что. Ещё до того, как мы ввели первую ноту, текст в Finale уже отранжирован. Уже существует один такт с заданной шириной.
Эта ширина взята с потолка. Поэтому случается, что когда мы вводим много мелких
длительностей в 
(Speedy), они налезают друг на друга.
Если у нас включена опция ,
то после выхода из данного такта произойдёт перерасчёт его ширины в соответствии
с количеством введённых нот и загруженной библиотекой ранжира. Если мы пользуемся
для ввода не
(Speedy), а 
(Simple), то такой перерасчёт будет происходить после каждой введённой ноты, поэтому
скученности нот в такте не возникнет. Когда первый такт оказывается заполнен нотами,
для ввода следующих нот требуется сперва создать новый пустой такт (с уже заданной
изначальной шириной) и всё повторяется сначала.
Итак, Finale позиционирует ноты внутри такта согласно таблице ширин или при помощи коэффициента, а затем подсчитывает суммарное пространство и назначает его такту. Если нас не устраивает данный ранжир, мы подбираем другую библиотеку (таблицу) или назначаем другой коэффициент.
Кроме того, мы можем изменить ширину такта — в этом случае распределённые внутри него длительности пропорционально сожмутся или разрядятся. При этом уже никакие коэффициенты или таблицы учитываться не будут. Отправной точкой является ширина такта.
Что происходит дальше? Допустим, у нас появилось два такта шириной по 500e каждый. А в строке, предположим, с учётом раштра помещается 700e. Finale автоматически растянет первый такт на всю строку, а второй перенесёт на следующую. Если нас это не устраивает, мы втянем второй такт на эту же строку и запрём его замком. Однако что происходит внутри? Изменилась ли ширина тактов при растягивании и сжатии? Нет, она не изменилась. Ширина обоих тактов так и осталась по 500e — в этом можно убедиться, если дважды щёлкнуть по ним в режиме Measure tool и проверить значение в поле Change Width. Однако и длина строки по прежнему осталась 700e. Для того, чтобы привести в соответствие эти величины, при форматировании строки на странице Finale пользуется горизонтальным масштабированием. Так, если оставить в строке один такт, то Finale растянет его с коэффициентом 140%, а если втянуть второй, то сожмёт на 70%.
К сожалению, процент горизонтального масштабирования Finale хранит в тайне, не выдавая его ни в каких сообщениях и не позволяя менять в настройках. Единственное, что доступно пользователю, это сравнивать нотный текст визуально с его представлением в Scroll View, где горизонтальное масштабирование всегда равно 100% — только в этом смысле можно назвать это состояние «истинным ранжиром».
На практике ранжир, показываемый в Scroll View, часто оказывается ложным. Это является результатом того, что бóльшую часть ручной работы по форматированию партитуры мы проводим уже в Page View после того, как произведена тайная операция по горизонтальному масштабированию строк. Мы можем передвигать тактовые черты, отдельные доли в такте, вводить численные значения для ширины такта — и при этом визуально ориентируемся на то, что видим в Page View. Если после такой работы перейти в Scroll View, то можно с удивлением обнаружить, что некоторые такты сплющены до неузнаваемости, а другие неоправданно растянуты. Это не истинный ранжир. Это истинное лицо принятой в Finale методики ранжирования.
Capella
Несколько иная система принята в нотаторе Capella. Такт не является для него такой же краеугольной единицей, как для Finale. Наличие пустого такта не является обязательным условием для ввода нот. Фрагменты нотоносца возникают с появлением каждой новой ноты (вертикальная черта справа — не тактовая черта, это курсор):
В Capell’е не предусмотрено отдельной операции ранжирования. Ноты здесь всегда отранжированы. По сравнению с Finale методика ранжирования в этой программе проста до умопомрачения. Здесь нет таблиц ширин, подгружаемых библиотек, ранжирных вертикалей, понятия ширины такта. Здесь есть лишь две величины: базовая ширина для самой мелкой длительности и коэффициент увеличения ширины по сравнению с ростом длительности:
Любовь к тайнам в Capell’е превышает все мыслимые пределы: если в Finale мы могли с точностью до тысячной доли знать значение ширины для базовой длительности (там эта ширина называлась , здесь — ) и коэффициента приращения ( в Finale или в Capell’е), то здесь мы можем лишь сказать, что ширина для базовой длительности находится между 100 % и 150 %. Кроме того, неизвестно от какой величины берутся эти % и какая собственно длительность является базовой.
Ещё одним ключевым отличием систем ранжира в обсуждаемых программах является то, что в Finale можно применить к разным участкам партитуры разные таблицы или коэффициенты ранжира, а в Capell’е изменение приведённых выше значений тотчас же отражается на ранжире всего документа — поделить партитуру на независимые участки с собственными значениями коэффициента невозможно.
Тем не менее, есть в алгоритме ранжира этих программ и общее: в Capell’е, как и в Finale, основой для ранжира служит не длина строки, а отвлечённая величина. Capella позволяет разбивать бесконечную нотную ленту на строки как вручную — простым нажатием Enter в месте переноса (причём, не обязательно на границе тактов) — или при помощи специальной подпрограммы . Однако полученные строки не выравниваются сразу по правому краю, как это происходит в Finale. Благодаря этому мы видим отранжированный, но не искажённый горизонтальным масштабированием текст.
Это и есть то главное достоинство ранжирной методики программы Capella, ради которой и затевалась данная статья. Что же такого привлекательного в этом промежуточном режиме? Взглянём на следующий фрагмент (см. то же, 1000x450, 48K):
 |
| Шуберт. Соната д. ф-но, op. 42.— Ed. Peters, Nr. 488a.— P. 16. |
Здесь во всех тактах содержится равное количество равных длительностей, однако гравировщик разместил в первой строке три таких такта, а во второй — четыре. При этом он руководствовался интуицией и расчётами. Нам, чтобы повторить набор данного фрагмента, потребуется то же. Однако расчёты за нас выполняет программа, и посвещать нас в их тонкости она не собирается, а что касается интуиции, то некоторую помощь мы ожидать всё-таки можем.
После разделения на строки наш текст будет выглядеть следующим образом (см. то же 957х334):
Каждая строка имеет ровно ту длину, на которую претендуют содержащиеся в ней ноты. Серая полоска справа — это правое поле страницы, по которому в конце концов должны быть выравнены все строки.
Такое представление текста даёт наборщику возможность оперировать неискажёнными по протяжённости кусками материала, перераспределяя его между строками. В условиях, когда текст растянут или сжат по правому краю страницы, это делать сложнее, так как у наборщика нет точного представления о реальном пространстве, необходимом для материала — см., как на предыдущей иллюстрации такты с одинаковым содержимым в разных строках имели совершенно разную ширину.
Второе важное достоинство невыравненного по правому краю нотного текста — это возможность обнаружить ошибки автоматического ранжира. Например, Capella хорошо справляется со знаками альтерации, раздвигая соседние ноты для избежания столкновений:
Однако она выделяет недостаточно места для созвучий с секундами:
Если текст растянут, то эти ошибки становятся незаметными, так как для каждого элемента выделено достаточно пространства. Однако при переформатировании такт может оказаться в более тесной строке и ошибка вылезет, но не будет вовремя замечена.
Другое дело, что Capella не предоставляет достаточных средств для исправления ошибок ранжира. Пользователь не имеет доступа к положению ранжирной вертикали — мы можем лишь передвигать отдельные ноты или созвучия относительно этой вертикали, но не всю вертикаль целиком. Допустим, например, нам нужно дать дополнительное пространство для бемоля, налезающего на секунду из предыдущего аккорда в правой руке:
Ставим курсор между раздвигаемыми созвучиями и, удерживая клавишу «J», несколько раз нажимаем клавишу «стрелка вправо». В результате получаем:
Как видим, произошёл сдвиг одного созвучия относительно ранжирной вертикали. Сама вертикаль осталась на месте, это мы видим по оставшемуся на месте созвучию в левой руке. Кроме того, уменьшилось пространство справа от второго созвучия в правой руке, что также свидетельствует о сдвиге относительно вертикали, а не самой вертикали. Для того чтобы сдвиг в правой руке отразился на положение нот в левой, нам нужно повторить опреацию для левой руки. Это плохо: представьте, что мы имеем дело не с фортепианной партией, а с оркестровой партитурой на пятидесяти строчках. Двигать придётся на каждой в отдельности. Ну а при растягивании по ширине полосы сдвиг, заданный вручную, не устранится, а, наоборот, умножится, что тоже плохо.
После того, как ошибки найдены и исправлены, а текст распределён по строкам наилучшим образом, можно выравнивать его по правому краю. Для этого служит команда 
(Justify), которую можно применить как к отдельной (текущей) строке, так и к выделенному фрагменту. Собственно, эту команду можно давать и отменять много раз в процессе работы, для того, чтобы сравнивать чистый ранжир с ранжиром, выравненным по ширине (см.
то же 957х346):
Выводы
Мы выяснили, что методика ранжирования каждой из двух сравниваемых программ обладает своими недостатками и преимуществами. Надо отметить, что некоторые из этих преимуществ являются исключительными признаками данной конкретной программы, не повторяющимися ни в каких других из распространённых нотаторов. Capella предоставляет визуальную помощь, предлагая дополнительный промежуточный режим отображения материала до выравнивания по правому краю, а в Finale существует возможность применения к разным фрагментам партитуры разных таблиц или коэффициентов ранжира.
Тем не менее, надо признать, что обе системы далеки от идеала: Finale связывает нотный текст непреодолимыми рамками такта, а в Capell’е полностью отсутствует доступ к ранжирным вертикалям и нет возможности применять разный ранжир к разным фрагментам партитуры.
Возникает вопрос: нельзя ли объединить достоинства разных методик ранжира в рамках одной программы? Можно. Дело за программистами.
