štítek nástroje:
Nedělám si iluze, že tento článek bude pro někoho zajímavý
nebo přínosný, ale mně poslouží ke srovnání myšlenek a
jednou třeba někomu jako inspirace, odstrašující příklad nebo tak ...
Chci vyložit, jak teď probíhá práce na projektu,
jaké používám nástroje a pracovní postupy, jak se postupně
vyvinuly a v čem mi teď překáží. Závěrem se pokusím načrtnout a porovnat
možná řešení.
Motivací k tomu mi je, že už dlouho cítím, jak mi stávající "pracovní
proces" v cestě k cíli spíš překáží než pomáhá a již příliš dlouho
se odhodlávám k jeho tolik potřebné reformě.
Postupný rozvoj
Na začátku (podzim 2010) bylo několik izolovaných zpěvů bez ladu a skladu
vysázených v LilyPondu.
Neměl jsem v plánu vytvořit žádné rozsáhlejší dílo.
Zcela přirozeně jsem tenkrát své hudební pokusy psal na papír,
do notových sešitů (nedávno při stěhování jsem na ně narazil
a divil jsem se, kolik jsem jich za rok stihl popsat),
a na počítači sázel jen ty, které jsem považoval za hodné zveřejnění.
Počítač použitelný pro práci mi tenkrát navíc nebyl dobře přístupný -
můj domácí byl rozbitý, takže jsem mohl jen příležitostně
parazitovat na vybavení své sestry;
později při pobytu v Erfurtu jsem byl odkázán na školní počítače,
jejichž užívání bylo omezeno otevíracími hodinami výpočetního střediska.
Již někdy před odjezdem do Erfurtu (jaro 2011) jsem ale na složku
se zpěvy k oficiu nasadil verzovací systém
git.
Verzování jsem se naučil mít rád při práci na softwarových projektech
a vyvinulo se tak nějak samo sebou, že jsem jeho vymoženosti
(mj. možnost kdykoli se vrátit ke kterékoli starší verzi
a snadno porovnávat historické verze mezi sebou)
chtěl mít k disposici i pro svůj projekt hudební.
(Konkrétně git jsem ale použil prvně právě pro projekt In adiutorium.
Do té doby jsem používal jen cvs.)
Vzhledem k tomu, že počítačově vysázené noty byly v této fázi
projektu jakousi "výkladní skříní" či "špičkou ledovce"
a všechen vývoj probíhal na papíře, bylo schema vývoje - z pohledu
git repositáře - lineární.
Postupně byly přidávány nové a nové zpěvy;
když se některý kousek postupem času ukázal jako nepříliš dobrý,
byl v notovém sešitě připraven nový a původní podoba nahrazena.
Když jsem později získal vlastní funkční počítač,
zanevřel jsem na notové sešity - bylo pro mě pohodlnější psát noty
rovnou do počítače v textovém formátu užívaném LilyPondem
než nejprve na papír a pak je přepisovat.
Tak najednou bylo potřeba vyřešit, jak ve struktuře projektu
udělat místo na pokusy a omyly:
První verze nové antifony totiž většinou vzniká "načisto": probrnkávámm a
prozpívávám se k podobě, která zní přijatelně, průběžně upravuji
notový zápis. Poté, co se propracuji k uspokojivému výsledku,
přesouvám se k dalšímu kousku.
Když se však časem ukáže, že nějaká hotová antifona
má zásadní nedostatky a její melodii bude potřeba složit znovu,
pracuji už zpravidla s více variantami, než se pro jednu rozhodnu.
Také se jako čím dál méně vyhovující ukazoval systém
nahrazování jedné verze druhou - bylo by výhodné mít všechny
historické podoby daného zpěvu stále po ruce a moci je bez námahy
porovnávat. (Naprogramoval jsem kdysi skript, který uměl
vytahat všechny historické verze daného zpěvu z gitu;
bylo to sice zábavné cvičení, ale jeho výsledek nepatří k nástrojům,
které by opravdu usnadňovaly každodenní tvůrčí práci ...)
Dílem na základě svých tehdejších
zásadně mylných představ ohledně magických schopností gitu
při slučování (merge) větví jsem se rozhodl v hlavní větvi pokračovat
jako doposud (na jednu antifonu jedno znění - to momentálně oficiální)
a pro účely "pracovního bloku", kde je možné od každého zpěvu
vršit neomezené množství variant, vytvořit novou větev
(variationes;
hlouběji na blogu je k nalezení
článek z oné doby,
kde se o tom píše).
Postup revize nepovedených zpěvů od té doby probíhá tak, že
ve větvi variationes rozpracuji několik možných podob,
tu nejpovedenější pak vyčistím od pracovních poznámek a zkopíruji
na příslušné místo do větve master.
Původně jsem ke zkoušení možných variant využíval přímo lokální
verzi toho kterého souboru. Později jsem však zjistil,
že pak aktualizace větve variationes z master
pomocí git merge neprobíhala vždy podle mých představ,
a tak jsem pro "špinavou pracovní verzi" začal používat zvláštní
kopii příslušného souboru (např. kompletar.ly má pracovní verzi
kompletar-VAR.ly).
Otravná režie
Revize jedné antifony teď tedy vypadá takto:
Mám dva lokální klony repozitáře projektu,
v jednom je načtena větev master, ve druhém variationes.
(To by samozřejmě nebylo potřeba, je možné přepínat se mezi oběma
větvemi v jediném klonu, ale postupem času jsem přišel na to,
že v kontextu tohoto projektu se mi v popsaném uspořádání pracuje lépe.)
# 1. nejnovější změny z hlavní větve promítnout do větve pracovní
(variationes)$ git merge master
2. V pracovní verzi (-VAR.ly) daného souboru vyzkouším několik možných podob;
vyberu nejlepší, barevně ji označím jako novou hlavní;
3. zkopíruji ji do
"čisté" verze souboru. Vymažu z ní pracovní značky, které mimo
sekvenci variant většinou nemají smysl (upozorňují na místo,
kde se melodie odchyluje od předchozího pokusu).
# 4. uložit změny pracovního souboru
(variationes)$ git commit -m 'one ant. revised' kompletar-VAR.ly
# 5. uložit změny "čistého souboru"
(variationes)$ git commit -m 'revised ant.' kompletar.ly
# 6. všechny změny předat i druhému klonu repozitáře
(variationes)$ git push ~/In-adiutorium variationes
# 7. přejít do druhého klonu
$ cd ~/In-adiutorium
# 8. změny "čistého souboru" promítnout do hlavní větve (master)
(master)$ git cherry-pick variationes
I tomu, kdo třeba úplně nerozumí naznačeným operacím s gitem,
bude zřejmé, že popsaný systém práce nastavený začátkem roku 2012
kromě vlastní tvůrčí práce na nápěvech antifon obnáší i odpudivě
velkou porci režie okolo, spočívající převážně v četných interakcích
s verzovacím systémem.
Přitom, jak již bylo řečeno, tento způsob práce byl kdysi dávno nastolen
převážně proto, že jsem měl chybné představy o magických schopnostech
gitu a věřil jsem, že mi bude práci naopak výrazně šetřit.
Nyní jediným pochybným ziskem z toho všeho je, že hlavní větev je
relativně čistá, od každého zpěvu obsahuje pouze jednu verzi v jednom
souboru. To je ale zisk, který pro mě nemá v podstatě žádnou hodnotu.
Kudy z toho ven
Jako programátor k smrti nenávidím duplicity a ruční kopírování.
Čehokoli. Přesto se právě projekt In adiutorium stal takovým
ne-li peklem, pak nepochybně předpeklím, limbem či peklíčkem
všemožných duplicit komplikujících další vývoj a plodících nepořádek.
Duplicity spojené s provozem větve variationes jsou přitom
ty, které momentálně představují největší zátěž. Jak je eliminovat?
1. Zrušení větve variationes
Samostatná vývojová větev, která nepřináší žádný užitek, může být
beze škod opuštěna. Pracovní verze souborů (-VAR.ly) se mohou
odstěhovat do vyhrazené podsložky hlavní větve.
Tím ze sedmikrokového scénáře výše odpadnou body 1, 5, 6, 7, 8
a stane se z něj scénář tříkrokový.
Stále zůstává otravná nutnost ručně kopírovat z pracovního souboru
vybranou variantu do souboru čistého/produkčního.
I tomu snad lze předejít. Ale pro pochopení toho, proč některé
možné cesty předem vylučuji z úvah, je potřeba znát jeden další
detail, také související s problémem duplicit.
Odkazování na zpěvy - FIAL
Když projekt In adiutorium nabyl většího rozsahu, vznikla potřeba
trvalých strojově zpracovatelných referencí na jednotlivé zpěvy.
Vedou k tomu dva různé motivy:
Prvním je sazba zpěvníků. Projekt In adiutorium by neměl skončit
vychrlením několika desítek dokumentů o jednotkách až desítkách
stran obsahujícíh nápěvy antifon a responsorií oficia,
ale vytvořením skutečného antifonáře, tj. přiměřeně funkční a
pohodlné liturgické knihy pro každodenní zpívané oficium.
Kromě toho také občas sázím menší příležitostný
zpěvníček pro sebe nebo pro někoho jiného.
Ať ve velkém či v malém, je silně nežádoucí muset jednotlivé
zpěvy pro účely nového díla ručně kopírovat.
Nenávidím kopírování. Když chystám sazbu zpěvníku, chci pouze
odkázat na zpěv, který chci na daném místě zahrnout, a nějaký nástroj
by měl umět kdykoli najít a dodat jeho nejčerstvější verzi.
K tomu je nutné mít způsob, jak na každý zpěv jednoznačně odkázat.
Takový způsob mám, a dávno mám i ten kýžený nástroj.
Již jsem o něm v minulosti psal.
Než ten jednoduchý systém referencí na zpěvy představím, je třeba zmínit
i druhý motiv vedoucí k jeho zavedení.
V liturgii hodin se některé zpěvy opakují, i vícenásobně.
Jindy se objevují texty velmi podobné - s trochu jinými slovy,
s částí navíc, s velikonočním aleluja a bez něj, ...
Pro stejný text používám vždy stejný nápěv. Pro zhudebnění textu
výrazně podobného jinému, dříve zpracovanému, se podle vhodnosti
pokouším vyjít z již existujícího. (Ne vždy je to možné.)
V těchto případech je potřeba mít někde poznamenáno, že nová antifona
je kopií či adaptací jiné, protože v případě,
že se v budoucnu bude měnit jedna, měla by se zároveň s ní
upravit i druhá. Původně jsem si o tom dělal jen poznámky pro sebe,
ale s rostoucím množstvím těchto referencí bylo zřejmé,
že nebude v lidských silách zvládnout je a bude nutné připravit
nástroj, který kontrolu koherence příbuzných antifon alespoň
částečně zautomatisuje. Naprogramování tohoto nástroje zatím zůstává
úkolem pro budoucnost.
Reference na konkrétní zpěv se skládá z cesty k souboru -
vždy cesty relativní k hlavnímu adresáři projektu - a id zpěvu,
které má každý kousek v hlavičce; v rámci daného souboru je vždy unikátní.
Několik příkladů:
| kompletar.ly#sim |
antifona k Simeonovu kantiku |
| antifony/tyden1_1nedele.ly#1ne-ant2 |
druhá antifona prvních nešpor neděle prvního týdne žaltáře |
| commune/commune_maria.ly#invit1 |
antifona k invitatoriu ze společných textů o Panně Marii |
Bezpočet reálných příkladů je možné
najít přímo v repozitáři projektu.
Reference na zpěv vytvořená popsaným způsobem se jmenuje FIAL.
Jmenuje se nějak hlavně proto, že bylo potřeba nějak pojmenovat
pole v hlavičce zpěvu, kde se odkazuje na jiný zpěv, z něhož
byla celá melodie nebo její část převzata. Je to zkratka, a že
je to zkratka špatně utvořená a její tvůrce se za ni stydí,
nebude ji vykládat.
2. Zbavit se veškerého ručního kopírování
Ideálem programátora k smrti nenávidícího duplicity je,
nikdy nic ručně nekopírovat. Každá varianta každého zpěvu by ve struktuře
projektu měla figurovat právě jednou. Jestliže mám dva druhy výstupů -
jeden pracovní pro sebe, s variantami a pracovními poznámkami,
a druhý čistý pro zbytek světa - pak by ideálně mělo být možné
nějak oba generovat z jediného zdroje.
Omezující podmínkou je, že výše popsaný způsob odkazování na zpěvy
musí zůstat funkční a existující reference se nesmějí rozbít.
"Produkční" verze každého zpěvu by tedy měla zůstat ve stejném
souboru jako doposud. Přitom generování výstupů by mělo být i nadále
co nejjednodušší.
Schůdnou cestou se zdá být nějaká varianta uspořádání, kdy se
čistá verze generuje automaticky redukcí verze pracovní.
V pracovní verzi pak musí být konvenčně dáno nebo
strojově čitelným způsobem vyznačeno, co do čisté verze patří a co ne.
Alternativou je zachovat čistou a pracovní verzi jako relativně
nezávislé entity (ve kterých lze bez nutnosti vzájemných ohledů psát
poznámky, řešit zalomení stránek apod.), ale plně automatizovat proces
přenesení vybrané varianty zpěvu z pracovní verze do čisté.
Zvolená cesta
Tady je určitá cesura. Jsem ten typ člověka, který často k tomu,
aby vůbec mohl přemýšlet, potřebuje psát. V próze. Žádné bodovité poznámky.
A o pár řádek výše a řadu hodin dříve jsem konečně dospěl k uspokojivému
plánu. Zanechal jsem psaní a dal se do jeho realizace.
Nově nastolený systém vypadá následovně:
Pracovní verze souborů s notami odteď sídlí v hlavní větvi
v adresáři pojmenovaném stejně jako dosavadní vývojová větev -
variationes.
Pracovní soubor se jmenuje stejně jako odpovídající soubor "produkční".
O přenesení nově upravených zpěvů z pracovního souboru do "produkčního"
se stará nový skript škaredého jména
updatefromvar.rb:
$ ruby updatefromvar.rb kompletar.ly
Najde pracovní soubor odpovídající souboru předanému v parametru,
načte ho a prochází zpěv po zpěvu. Kdykoli najde kus označený
jako varianta vybraná do "produkční" verze, vyčistí ho od pracovních
značek, podle id najde odpovídající kus v hlavním souboru a provede
náhradu.
Z provedených změn mám radost. Očekávám, že se příznivě projeví
na rychlosti postupu dalších prací. Není žádné tajemství, že jsem
dosud - z velké části právě kvůli výše popsanému nepohodlí
spojenému s procesem
revize - mnohem ochotněji skládal nové zpěvy než pracoval na starých,
označených pro opravu.
Při jednom z rozhovorů přes dva monitory
o tom, co jejich obsluhy dělají ve volném čase,
jsem kolegovi popisoval algoritmizační problém,
který řeším v souvislosti se sazbou
žaltáře.
"Fuj, hlavně to neříkej nikomu z FITu, ještě by to třeba začali
používat jako domácí úkol,"
zareagoval kolega, který na zmiňované fakultě ČVUT studoval
a domácí úkoly na tvrdě optimalizovaná řešení náročných
úloh neměl rád.
Mám podezření, že normální budoucí programátor se špetkou
nadání mou úlohu vyřeší lusknutím prstu, a jako domácí úkol
z algoritmizace tudíž příliš výživná není, ale můj opičí mozek
("ti, co dělají weby, to nejsou žádní programátoři, ale cvičené opice,"
říká bratranec matfyzák)
ji každopádně zatím uspokojivě nevyřešil,
takže úplně triviální zřejmě také není.
Tady je.
(Následující text nepředpokládá znalost liturgie hodin
a některé skutečnosti záměrně zjednodušuje, aby vynikla podstata
algoritmizačního problému.)
Mějme knihu s texty modliteb (žaltář).
Kniha obsahuje všechny texty potřebné pro všechny modlitby
v pořadí, v jakém se používají o běžných dnech.
Modlitba sestává obvykle ze tří textů.
Texty jsou rozloženy na čtyři týdny a v tomto
čtyřtýdenním cyklu se některé
z nich vícenásobně opakují.
O některých svátcích se modlitby neberou z tohoto pravidelného
cyklu, ale jsou volně vybrané z jeho různých míst.
K vyhledání modliteb o takovýchto svátcích slouží zvláštní
index na konci žaltáře, který pro každou denní modlitbu
odkazuje na tři nebo více textů.
Napište program, který dostane
seznam textů potřebných pro každou denní modlitbu a
seznam textů, jak jdou v knize za sebou
(reálná data: texty pro svátky,
normální pořadí textů)
a vypíše, kolikátý z případných více výskytů téhož textu v knize
se má použít, aby ten, kdo se z knihy modlí, při jedné denní modlitbě
listoval právě jen nezbytně málo.
Za větší dobro je přitom považováno to, že jsou dva nebo více
použitých textů
bezprostředně za sebou, než to, že uživatel v průběhu modlitby
obrátí nejmenší možné množství stránek.
[EDIT 28.6.2014]
Řešení hrubou silou, které by na cvičeních z algoritmizace
samozřejmě neprošlo, je
na githubu.
Spíš z legrace jsem, letos nikoli poprvé,
hecoval sestru, ať si se mnou přijede zazpívat nešpory
z památky své křestní patronky, sv. Marie Magdalské.
Když hecovaná překvapivě pozvání přijala, bylo potřeba připravit
sešit s kompletním "programem" nešpor. Když zpívám sám, vystačím
s notami na notebooku a breviářem, ale člověk breviáře a žalmových nápěvů
méně znalý by se ztrácel...
Původně jsem počítal, že noty snadno připravím za sobotní večer.
Pokusil jsem se proceduru pro sestavení zpěvníčku sestavit
nakopírováním ze skriptů, které sestavují stávající svazky
Antifonáře k DMC. Ukázalo se ale, že tyto skripty jsou tak
špinavě napsané (už v nich samých jsem příliš kopíroval),
že je neúnosně náročné vypreparovat z nich funkční celek potřebný
pro aktuální potřebu a přenést ho jinam.
Když jsem měl na výběr mezi "hodiny se patlat s kopírováním a rozběháváním
kódu z těch odporně páchnoucích skriptů" a "hodiny programovat nástroj,
který mě toho patlání navždycky zbaví", vybral jsem si celkem logicky
druhou variantu a větší část neděle strávil přilepený ke klávesnici.
Nový nástroj, z nedostatku invence nazvaný prozatím Typographus,
zásadně usnadňuje tvorbu zpěvníků s notami vzniklými v rámci projektu
In adiutorium tím, že odstraňuje mnohostranné duplicitní informace,
dosud zatěžující přípravu svazků Antifonáře.
Doposud některé informace existovaly až na třech místech:
např. modus a diference byly uvedeny v notovém materiálu
v hlavičce dané antifony, dále v hlavním .tex souboru,
kam se antifona vkládala, a znovu v rake-skriptu, který k dané
antifoně připravoval žalm. S příchodem Typographa se do
.tex souboru vloží jediné makro. Typographus najde příslušné noty,
z jejich hlaviček zjistí, jaký je potřeba připravit text žalmu a případně
žalmový nápěv, a do dokumentu všechno vloží.
Dokument níže, proti zdroji opravdového zpěvníku
samozřejmě jednodušší o mnoho formátování a kratší o mnoho obsahu,
obsahuje všechny potřebné informace k vygenerování jednoduchého
zpěvníku obsahujícího hymnus, antifonu se žalmem, responsorium
a antifonu s kantikem Magnificat.
V obsahu dokumentu jsou pro přehlednost pouze speciální
makra zpracovávaná Typographem.
Makra začínající \set sdělují umístění důležitých dat.
Další makra už vkládají "obecné noty" (\simpleScore),
antifonu s textem příslušného žalmu (\antiphonWithPsalm),
responsorium (\responsory).
Noty ke vložení jsou identifikovány pomocí relativní adresy
souboru vůči ChantBasedir, znaku # a id uvedeného v hlavičce daného
kousku. Pokud cesta není uvedena, bere se ta z nastavení ChantSource.
\documentclass[a5paper, twoside]{article}
\usepackage[utf8]{inputenc}
\usepackage[left=1.5cm, right=1cm, top=1.5cm, bottom=2cm]{geometry} % okraje stranky
\usepackage[T1]{fontenc}
\usepackage{bookman}
\newcommand{\preLilyPondExample}{ \begin{flushleft} }
\newcommand{\postLilyPondExample}{ \end{flushleft} }
\input{../antifonar/spolecne.tex}
\newenvironment{psalmus}{}{}
\begin{document}
\setChantBasedir{../}
\setPsalmsDir{../antifonar/zalmy/}
\setIncludes{../antifonar/spolecne_antifonar.ly, ../dilyresponsorii.ly}
\setChantSource{sanktoral/0722mariemagdalena.ly}
\simpleScore{sesity/mariemagdalena_2013_noty.ly#ne-hymnus}
\antiphonWithPsalm{#ne-a1}
\responsory{#rch-resp}
\antiphonWithPsalm{#ne-amag}
\end{document}
Proces sestavení zpěvníčku sestává z preprocessingu
.tex souboru Typographem, zpracování jeho výstupu programem
lilypond-book a konečně kompilace pomocí pdfLaTeXu.
Pokud chcete vidět "opravdový" dokument pro sázení s pomocí Typographa,
tady je zdroj zpěvníčku k dnešním nešporám
a tady se můžete podívat,
jak zpěvníček vypadá vysázený.
Nástroj je samozřejmě teprve v raném stadiu vývoje. V budoucnu bude
potřeba doplnit některé nové funkcionality a možnosti nastavení
a pokud se má stát efektivním nástrojem pro sestavování rozsáhlých
zpěvníků, jako jsou plánované svazky Antifonáře k DMC,
bude potřeba i trocha optimalizace.
Již teď ale umožňuje vyrábět malé zpěvníky, v rozsahu třeba onoho
výše zmíněného, za ten jeden večer, jak jsem bláhově odhadoval
na začátku výše podané historie. A to je, alespoň pro mě, něco.
Ze zvláštních liturgických dob je na tom co do množství hotových
zpěvů bezkonkurenčně nejlépe doba adventní.
Na podzim jsem seděl doma, neúspěšně hledal práci,
k tomu, abych se pořádně opřel do studia, kde by to bývalo bylo dost
potřeba, jsem se z různých důvodů nedokázal přimět -
a ve volném čase, kterého jsem tak měl velice nazbyt,
vznikly kompletní adventní antifony, vč. těch k evangelním kantikům
ve všední dny.
Doba postní a velikonoční takové "štěstí" neměly a i nadále jim scházejí
a přinejmenším ještě rok nebo dva budou scházet i antifony
k nedělním žalmům.
Chci ale upozornit, že projekt In adiutorium ve skutečnosti
může nabídnout ještě o něco víc, než co je pěkně uspořádáno
a naservírováno v připravených notových materiálech.
Myslím, že ten, kdo je zvyklý hodinky pouze recitovat, má dobrou
šanci vůbec si toho nevšimnout - ale ten, kdo hodinky zpívá,
nebo se breviářem z nějakého důvodu zabývá i mimo čas modlitby
(ať už proto, že ho překládá, skládá k němu zpěvy, nebo nad ním
provozuje vědu), si brzy všimne, že se řada antifon při různých
příležitostech vrací.
Pro mě je důležité mít o tom přehled proto, abych stejný text
zbytečně nezhudebňoval vícekrát.
(Pozn.: v předkoncilním antifonáři bylo vícero antifon, které
se objevovaly na různých místech s různými melodiemi;
já se ale snažím, pokud dobrý důvod nevelí jinak, stejný text
dávat vždy se stejným nápěvem. Šetří mi to práci i učení.)
Samozřejmě si dávno jednotlivě nepamatuji, které texty jsem již
zhudebňoval, natožpak pro kterou část liturgického roku.
Dříve jsem již zmiňoval některé jednoduché, ale šikovné nástroje,
které jsem si naprogramoval,
aby mi přehled o zhudebněných textech zprostředkovávaly.
Jeden z nich používám už dlouho a teď o velikonočních fériích skoro denně.
Velká část (určitě přinejmenším polovina) antifon, které se teď
zpívají s Benedictus a Magnificat, se totiž dá najít
v materiálu pro neděle v mezidobí, ve společných textech o svatých
nebo ve svátcích sanktorálu.
Mám na to nástroj, který může použít každý, kdo má k disposici
operační systém unixového typu (nebo možná i Windows s Cygwin?)
s nainstalovaným interpretem jazyka Ruby.
Stačí ve složce se zdrojovými kódy notových materiálů
spustit skript antigrep.rb a předat mu hledané slovo.
(Resp. jakýkoli přepínač a hledací výraz akceptovaný programem
grep, který se v pozadí k hledání používá.)
Skript proběhne všechny noty, vytahá z nich texty a vypíše
odpovídající texty, které našel, spolu s názvem souboru, ve kterém
jsou k nalezení. Pak stačí najít odpovídající PDF a může se zpívat.
Příklad výše ukazuje, jak jsem dnes ráno našel antifonu k Benedictus.
(První příkaz na obrázku, volající skript indexmaker.rb,
ukazuje přibližný počet zatím vytvořených zpěvů, přičemž ale nijak
nezohledňuje skutečnost, že některé antifony jsou zkopírované
na více místech a že některé texty, jako např. antifony
kompletáře, mají více různých zhudebnění.)
Se vznikem obsáhlejších materiálů a zejména postupně vznikajících
svazečků Antifonáře k Denní modlitbě církve někoho možná začala
zajímat otázka, jak knížky z elektronické podoby co možná elegantně
převést na papír. Já sám už několik týdnů používám vytištěný
Antifonář ke kompletáři
a Žaltář a chci se podělit o postup,
který používám.
Tisk
Svazečky Antifonáře jsou zamýšlené k tisku na papír
formátu A5 oboustranně.
Aby si s tiskem dobře poradila tiskárna a aby se pak knížka
dala dobře svázat, je potřeba stažený PDF dokument upravit:
umístit vždy dvě stránky A5 vedle sebe na stránku A4
a z takto vzniklých "tiskařských" stránek ty sudé otočit.
(Předpokládám, že čtenář má jako já k disposici tiskárnu tisknoucí
na papír formátu A5 a chce knížku vázat nějakou metodou pracující
se složkami. Pro toho, kdo tiskne rovnou na formát A5 a bude vázat
třeba kroužkovou vazbou, je tento článek irelevantní.)
Pro postup, který sám používám a chci i vám nabídnout, je důležité
předem zvážit, jak se materiál připravovaný k tisku bude vázat.
Rozsahem malé materiály čítající, řekněme, do 30 stran, je
zřejmě nejlepší svázat jako jeden sešit. Z nabídky projektu
In adiutorium do této kategorie spadá např.
Antifonář ke kompletáři.
Rozsáhlejší materiály je naproti tomu vhodnější vytisknout a zkompletovat
jako větší množství složek ("malých sešitů") a ty pak spojit některým
typem knižní vazby.
K přípravě dokumentů k tisku používám program pdfbook ze sady
nástrojů
PdfJam. (Moje linuxová distribuce - Debian -
má PdfJam v nabídce připravených balíčků. Bohužel nevím o tom,
že by bylo možné PdfJam používat ve Windows.) Postará se o ni jediný
příkaz:
pdfbook --signature N --suffix X SOUBOR
N: číslo dělitelné 4 - kolik stránek na složku. (Číslo musí být dělitelné
čtyřmi proto, že čtyři stránky se tisknou na jeden list.)
X: přípona výstupního souboru.
SOUBOR: cesta ke zpracovávanému souboru.
Antifonář ke kompletáři,
čítající právě 12 stran, tisknu se 12 stránkami na složku a svážu jako
jeden sešit.
pdfbook --signature 12 --suffix broz antifonar_kompletar.pdf
Jak úspěšně upravený soubor vypadá je možné vidět na
Antifonáři ke kompletáři:
po rozkliknutí detailu se ukáže nabídka dvou souborů ke stažení.
antifonar_kompletar-broz.pdf je připravený výše popsaným způsobem.
Obsáhlejší materiály je vhodné rozdělit na složky
po 12 nebo 16 stranách.
Upravený soubor oboustranně vytiskneme.
Vazba
Vytištěné listy uprostřed přehneme a poskládáme do složek.
Malé materiály vázané jako jeden sešit sešije větší sešívačka.
Já tak velkou sešívačku nemám a sešity sešívám jehlou a nití -
jedním velkým několikrát "obtaženým" stehem uprostřed.
Vazba větších brožur a knih je poněkud dobrodružná záležitost.
Na internetu je k nalezení řada návodů
(např. ve WuWejově zápisníku).
Nemohu doporučit žádný "zaručeně nejlepší", protože sám vážu
knížky zřídka a zatím jsem umění knižní vazby dostatečně neovládl. Poměrně
dobré zkušenosti mám s návodem obsaženým v knize
Skautskou stezkou (Václav Břicháček a další; vydal Junák 1998, 2. vyd. 2001).
V git repozitáři projektu In adiutorium ve složce "nastroje"
je prográmek indexmaker.rb, který umí projít noty v souborech
zadaných na příkazové řádce, z každého kousku vytáhne text,
upraví jej do čitelné podoby (odstraněním značek, vysvětlujících
LilyPondu, jak text přiřazovat k notám), nakonec texty setřídí
podle abecedy a vypíše spolu s údajem, ze kterého souboru
byl ten který text vzat.
Ukázka:
index antifon a responsorií z materiálu "antifony ze žaltáře".
Tento program činí výstup projektu In adiutorium významně
přehlednějším. Umožňuje při troše šikovnosti vyhledávání
antifon podle textu napříč všemi materiály.
To se stává dost potřebným: čím větší část breviáře je zpracovaná,
tím častěji se stává, že vím, že jsem s určitým textem už v jiném
kontextu pracoval, někdy si i pamatuji melodii, kterou jsem pro něj napsal,
ale netuším, kdy to bylo a ve kterém souboru ho najdu.
(Dnes se mi to např. stalo s antifonou k modlitbě uprostřed dne
o slavnosti Zjevení Páně odpoledne: "Dám tě národům jako světlo...".)
Dále je např. soupis textů všech antifon ze žaltáře předpokladem
pro zpracování
"malého antifonáře", o kterém jsem psal celkem nedávno.
Některé antifony ze starších vrstev projektu mají za sebou poměrně
dlouhou historii revizí melodie. Rád bych představil nový nástroj, který
umožňuje tuto historii si prohlédnout.
V adresáři se zdrojovými kódy projektu se ve složce
"nastroje" nachází skript prehledverzi.rb.
Je to skript napsaný v jazyce Ruby, pro jeho spuštění je tedy
potřebný příslušný interpret. Nemá žádné grafické uživatelské rozhraní
a spouští se z příkazové řádky. (Dobře vím, že právě teď většinu čtenářů
dokonale přešla chuť ho zkoušet. S tím se počítá - tento článek je
především pro další skladatele a "skladatele", kteří píší noty
v LilyPondu a pro správu verzí používají git a po drobné úpravě
by můj skript třeba mohli dobře využít.)
Skriptu se jako jediný argument na příkazové řádce předá název souboru,
jehož historie má být získána.
Pro správnou funkci skript musí být
spuštěn v Git-repositáři a zpracovávaný soubor musí být zdrojový kód not
pro sázecí program LilyPond. Tento soubor dále musí být v Git-repositáři
vedený. (Skript je totiž primitivní nadstavbou nad nástroji git.)
Nakonec je pro funkci skriptu potřeba adresář "pracovni", do kterého
skript ukládá své pomocné soubory i svůj výstup.
git clone git://github.com/igneus/In-adiutorium.git
cd In-adiutorium
mkdir pracovni
ruby nastroje/prehledverzi.rb kompletar.ly
Skript z git-repozitáře vytahá všechny dostupné verze
specifikovaného souboru (resp. všechny ty, které přímo vedly ke vzniku
té aktuální) a pro každý jednotlivý kousek not (score) vytvoří
v pracovním adresáři soubor,
který obsahuje všechny její verze od nejnovější po nejstarší.
Ten je možné normálně přeložit LilyPondem a prohlížet.
Na ukázku jsem připravil historii
jedné z antifon kompletáře.
Napsal jsem skript prehledverzi.rb výhradně pro potřeby projektu
In adiutorium a bez ambic na funkčnost za jeho hranicemi.
Dovede si poradit jen se zcela primitivními soubory not -
nerozumí ani lilypondovským proměnným, ani vnořeným souborům,
nedovede si adekvátně poradit s textem vloženým mezi noty příkazem
\markup, ... Pro potřeby, pro které byl napsán, ale funguje dostatečně.
Podobný skript, který by si dokázal korektně poradit s jakýmikoli
notami napsanými v LilyPondu, by sice nejspíš byl velice užitečnou
pomůckou pro řadu uživatelů, nevystačil by ale při zpracovávání not
s jednoduchou mechanickou fintou a musel by obsahovat
kompletní nebo téměř kompletní
sémantický analyzátor jazyka LilyPond - a to dělat nechci. A neumím.
Důvodem vzniku skriptu byla potřeba mít možnost kontrolovat degenerace
melodie - melodii antifony, která se mi z nějakého důvodu po určitém
časovém odstupu přestane líbit, předělám. Když ale některá
antifona nemá na melodie štěstí a projde takovým předěláním desetkrát,
bohužel není jisté, že desátá melodie je lepší než devět předchozích.
Možnost vidět je všechny za sebou a porovnávat je tedy důležitá.
[EDIT 19.2.2012] Skript už dlouho umí vyrobit přehledný soubor
obsahující vývoj všech antifon ze zpracovávaného souboru.
Oddíl každé antifony je nadepsán jejím textem a každý commit má
u sebe datum.