Новости


Русская книга о Finale выставлена в Москве на Всероссийской книжной ярмарке (12–16 марта), в первый день которой состоялась презентация книги с участием С. Лебедева. [16.03.2003]


Познакомьтесь с Инструкцией для авторов по оформлению нотной рукописи и правке корректуры. Это издание 1934 года сегодня не только представляет собой историческую ценность, но и может напомнить о некоторых очевидных, но многими забытых вещах. [3.02.2003]


Tobias Giesen в своих чрезвычайно полезных инструментах не предусмотрел экспорта / импорта настроек. Например, если на своём домашнем компьютере вы запрограммировали горячие клавиши, то, для того, чтобы пользоваться ими на работе, вам нужно будет повторить все действия на офисном компьютере ещё раз. Заново придётся программировать клавиши и после переустановки Windows. Впрочем, проблема решается. После настройки TGtools зайдите в редактор реестра Windows и запишите в файл содержимое ветви HKEY_CURRENT_USER \ SOFTWARE \ SOMUSQUE. После этого достаточно запустить сохранённый файл на любом компьютере, и Finale начнёт отзываться на ваши любимые клавиши. [20.01.2002]


В Finale 2002, наконец-то, появилась регулировка боковых штрихов для половинных и целых пауз. Теперь, чтобы было ясно, висит «кирпич» или лежит (когда он вне стана), не нужно пользоваться своим собственным шрифтом для пауз, а достаточно лишь установить параметры Left Half Rest и Right Half Rest в окошке Options / Document Settings / Lines равными 10e. [8.01.2002]


Нам помогают:
дистанционное образование в украине в 1996 г

16.08.2003

26. Откуда берётся ранжир?

История этого дела такова.

Гравировщик наделяет каждую вертикаль нотного текста (длительность) горизонтальным пространством исходя из общей ширины строки. Если сильно упростить процесс и рассмотреть случай, когда строка состоит только из нот одинаковой длительности, то можно сказать, что пространство, выделенное для каждой ноты, будет равняться ширине строки, поделённой на количество нот в ней. Всё это так.

Откуда же гравировщик знает, сколько именно нот ему нужно поместить в строку? Иными словами, каким образом осуществляется разбиение сплошного нотного текста на строки? Можно ответить так: гравировщик прикидывает, сколько тактов может поместиться в данной строке, и делит текст в соответствии с этими прикидками. Но для того, чтобы знать, сколько тактов (или сколько нот) поместится в строке, нужно хотя бы примерно предполагать, сколько пространства полагается отвести для каждой ноты.

Получается заколдованный круг, или, выражаясь математическим языком, рекуррентная зависимость: мы выделяем пространство для нот, исходя из их количества в строке, но количество нот в строке определяем, исходя из занимаемого ими пространства. Для того, чтобы вырваться из этого круга, нужно ввести какую-то абстрактную меру пространства, не зависящую от длины строки и количества нот в ней.

В разных нотаторах эта абстрактная мера устанавливается по-разному. В то же время, во многих нотных редакторах имеется режим «ленточного» просмотра, где ноты не делятся на страницы, а отображаются одним непрерывным целым,— то, что в Finale называется Scroll View.

Логично было бы предположить, что именно в этом режиме мы видим «истинный ранжир», выполненный на основе абстрактной меры, а не из расчёта длины строки. Как же обстоит дело на самом деле?

Finale

Что касается Finale, то да, в этом режиме мы видим ранжир, не продиктованный длиной строки. Однако назвать его «истинным» язык не поворачивается. Дело в том, что в Finale в основу ранжира положено не пространство, выделяемое для отдельной ноты или вертикали нотного текста, и даже не длина строки. Основой ранжира в Finale является ширина такта.

Таким образом, происходит вот что. Ещё до того, как мы ввели первую ноту, текст в Finale уже отранжирован. Уже существует один такт с заданной шириной.

Эта ширина взята с потолка. Поэтому случается, что когда мы вводим много мелких длительностей в (Speedy), они налезают друг на друга.

Если у нас включена опция Edit / Automatic Music Spacing, то после выхода из данного такта произойдёт перерасчёт его ширины в соответствии с количеством введённых нот и загруженной библиотекой ранжира. Если мы пользуемся для ввода не (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 мы могли с точностью до тысячной доли знать значение ширины для базовой длительности (там эта ширина называлась Reference Width, здесь — Absolute spacing) и коэффициента приращения (Scaling Factor в Finale или Relative spacing в Capell’е), то здесь мы можем лишь сказать, что ширина для базовой длительности находится между 100 % и 150 %. Кроме того, неизвестно от какой величины берутся эти % и какая собственно длительность является базовой.

Ещё одним ключевым отличием систем ранжира в обсуждаемых программах является то, что в Finale можно применить к разным участкам партитуры разные таблицы или коэффициенты ранжира, а в Capell’е изменение приведённых выше значений тотчас же отражается на ранжире всего документа — поделить партитуру на независимые участки с собственными значениями коэффициента невозможно.

Тем не менее, есть в алгоритме ранжира этих программ и общее: в Capell’е, как и в Finale, основой для ранжира служит не длина строки, а отвлечённая величина. Capella позволяет разбивать бесконечную нотную ленту на строки как вручную — простым нажатием Enter в месте переноса (причём, не обязательно на границе тактов) — или при помощи специальной подпрограммы Extras / Score wrap around…. Однако полученные строки не выравниваются сразу по правому краю, как это происходит в Finale. Благодаря этому мы видим отранжированный, но не искажённый горизонтальным масштабированием текст.

Это и есть то главное достоинство ранжирной методики программы Capella, ради которой и затевалась данная статья. Что же такого привлекательного в этом промежуточном режиме? Взглянём на следующий фрагмент (см. то же, 1000x450, 48K):

 
Шуберт. Соната д. ф-но, op. 42.— Ed. Peters, Nr. 488a.— P. 16.

Здесь во всех тактах содержится равное количество равных длительностей, однако гравировщик разместил в первой строке три таких такта, а во второй — четыре. При этом он руководствовался интуицией и расчётами. Нам, чтобы повторить набор данного фрагмента, потребуется то же. Однако расчёты за нас выполняет программа, и посвещать нас в их тонкости она не собирается, а что касается интуиции, то некоторую помощь мы ожидать всё-таки можем.

После разделения на строки наш текст будет выглядеть следующим образом (см. то же 957х334):

Каждая строка имеет ровно ту длину, на которую претендуют содержащиеся в ней ноты. Серая полоска справа — это правое поле страницы, по которому в конце концов должны быть выравнены все строки.

Такое представление текста даёт наборщику возможность оперировать неискажёнными по протяжённости кусками материала, перераспределяя его между строками. В условиях, когда текст растянут или сжат по правому краю страницы, это делать сложнее, так как у наборщика нет точного представления о реальном пространстве, необходимом для материала — см., как на предыдущей иллюстрации такты с одинаковым содержимым в разных строках имели совершенно разную ширину.

Второе важное достоинство невыравненного по правому краю нотного текста — это возможность обнаружить ошибки автоматического ранжира. Например, Capella хорошо справляется со знаками альтерации, раздвигая соседние ноты для избежания столкновений:

Однако она выделяет недостаточно места для созвучий с секундами:

Если текст растянут, то эти ошибки становятся незаметными, так как для каждого элемента выделено достаточно пространства. Однако при переформатировании такт может оказаться в более тесной строке и ошибка вылезет, но не будет вовремя замечена.

Другое дело, что Capella не предоставляет достаточных средств для исправления ошибок ранжира. Пользователь не имеет доступа к положению ранжирной вертикали — мы можем лишь передвигать отдельные ноты или созвучия относительно этой вертикали, но не всю вертикаль целиком. Допустим, например, нам нужно дать дополнительное пространство для бемоля, налезающего на секунду из предыдущего аккорда в правой руке:

Ставим курсор между раздвигаемыми созвучиями и, удерживая клавишу «J», несколько раз нажимаем клавишу «стрелка вправо». В результате получаем:

Как видим, произошёл сдвиг одного созвучия относительно ранжирной вертикали. Сама вертикаль осталась на месте, это мы видим по оставшемуся на месте созвучию в левой руке. Кроме того, уменьшилось пространство справа от второго созвучия в правой руке, что также свидетельствует о сдвиге относительно вертикали, а не самой вертикали. Для того чтобы сдвиг в правой руке отразился на положение нот в левой, нам нужно повторить опреацию для левой руки. Это плохо: представьте, что мы имеем дело не с фортепианной партией, а с оркестровой партитурой на пятидесяти строчках. Двигать придётся на каждой в отдельности. Ну а при растягивании по ширине полосы сдвиг, заданный вручную, не устранится, а, наоборот, умножится, что тоже плохо.

После того, как ошибки найдены и исправлены, а текст распределён по строкам наилучшим образом, можно выравнивать его по правому краю. Для этого служит команда (Justify), которую можно применить как к отдельной (текущей) строке, так и к выделенному фрагменту. Собственно, эту команду можно давать и отменять много раз в процессе работы, для того, чтобы сравнивать чистый ранжир с ранжиром, выравненным по ширине (см. то же 957х346):

Выводы

Мы выяснили, что методика ранжирования каждой из двух сравниваемых программ обладает своими недостатками и преимуществами. Надо отметить, что некоторые из этих преимуществ являются исключительными признаками данной конкретной программы, не повторяющимися ни в каких других из распространённых нотаторов. Capella предоставляет визуальную помощь, предлагая дополнительный промежуточный режим отображения материала до выравнивания по правому краю, а в Finale существует возможность применения к разным фрагментам партитуры разных таблиц или коэффициентов ранжира.

Тем не менее, надо признать, что обе системы далеки от идеала: Finale связывает нотный текст непреодолимыми рамками такта, а в Capell’е полностью отсутствует доступ к ранжирным вертикалям и нет возможности применять разный ранжир к разным фрагментам партитуры.

Возникает вопрос: нельзя ли объединить достоинства разных методик ранжира в рамках одной программы? Можно. Дело за программистами.


назад содержание вперед