Infrastruktura projektu In adiutorium
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.