Weblabor

Mindenképpen csak a látható plusz előre-hátra néhány ütemet tartanám betöltve, kirajzolni pedig csak azt, ami látszik. A hosszú kottákhoz ez nyilvánvalóan alapfeltétel. Nem gondoltam, hogy minden egyszerre rajzolódjon ki, nem is használtam ezt a szót, ha jól látom.

Az eredeti elkézelésem ez volt:

Van a teljes kottarendszer (ScoreSystem), vannak ütemek (Bar), és az ütemeken belül soronként sorütemek (LineBar). Leegyszerűsítve, temészetesen. A Bar-ok szekvenciálisan követik egymást a ScoreSystem-en belül, ennek lapozásához elérhető egy kétirányú ScoreSystemBarIterator. Minden Bar-on belül a BarLine-onként (valójában szólamonként, de most ne bonyolítsuk) független LineBarTimedObjectIterator-okat pörgetjük, keressük, hogy melyik sorban van az időben következő objektum, illetve melyek az azzal egyazon időben lévő más objektumok. Erre már van egy algoritmus, ami Bar-onként számolja a pozíciókat, de BarLine-onként készíti a bitmapet (azt is csak akkor, ha végzett a kalkulációkkal, és a bitmap a látható részbe kerülne). Ezt sebességileg viszonylag jó megoldásnak gondoltam, de úgy, hogy a Java bitmap-lehetőségeivel nem volt jelentősebb tapasztalatom. Az ilyen bitmapes megoldás fő hátrányait a nyitó postban felsoroltam. Úgy megérzés szintjén sem hiszem, hogy ez a jó megoldás. Ekkor fölmerültek az első konkrét kérdések a grafikát illetően. A többszálúság kihasználása valószínűleg sokat lendítene a dolgon. De hogyan? Mivel kell egyáltalán spórolni? Ha betöltök a memóriába pl. 30 db 120x100-as bitmapet, az már sok (pl. mobilon)? Ha sokminden egy bitmapre kerül, akkor egy apró módosítás is a bitmap újrarenderelését követeli, mit érdemes tehát egybetenni? És így tovább.

De térjünk vissza a megoldás útjára.



Ez alatt azt érted, hogy pl. egy-egy kottafejet, kulcsot stb. rendereljek előre, majd Flyweight-szerűen osszam meg? Igen, lehet, hogy ezt így kell csinálni. Kérdés (és épp ez az, amiben nincs tapasztalatom), hogy egy nagyobb alkalmazásban az ilyen előrerenderelések mekkora tehermentestést jelentenek. Mennyivel gyorsabb kirajzolni a bitmapot, mint renderelni a vektor-ábrát az egyes esetekben? Egy kör kirajzolása is lassabb, mint az azt tartalmazó ARGB bitmapé? Egy nem fix vektor-ábránál ("vonal") mi az előnyös? Végülis mennyi előrenderelt képet lehet a memóriában tartani (mobilon)? Persze, igen-igen, csinálhatnék sebesség- és memóriateszteket (már csináltam is egy párat!), de valójában nem akartam hónapokat eltölteni a jó megoldások megtalálásával (teljes munkaidő, család mellett), amikor erre nyilvánvalóan megvannak a kész bevált módszerek, amiket egy tapasztaltabb valaki talán gyorsan össze is tud foglalni.

Igen, mint írtam is, a bitmapekbe nem férne bele minden, főként az általad is említett átkötések, továbbá a sorváltó szólamok stb.

Olyan szerkesztőre gondoltam, ahol soronként több szólam is lehet, és kivételes esetben egy szólam át is mászhat a másik szólamba. Összeszedtem néhány zeneművet referenciaként, amelyeket mindenképp le kell tudnjon kottázni a program (Bach-fúgák, Chopin-mazurkák stb.).

Azonnal lejátszható zene is lesz belőle. Ezt a részét már kvázi véglegesen specifikáltam magamnak, ez nem is bonyolult, sőt talán ez a legkezelhetőbb része. A lejátszáskor a betöltődő hangzó objektumok egy prioritásos sorba kerülnek. Így megoldódik az a probléma is, amit sok szerkesztő csinál, mégpedig, hogy minden előke, arpeggio stb. lejátszása csak a főhang időpontjában kezd lejátszódni, ami meglehetősen rosszul hangzik. A prioritásos sorral az előkék a főhang előtt sorra tudnak kerülni, és a megfelelő időben lejátszódni.

Az eredeti inspiráció az volt, hogy érintőképernyőn javarészt mozdulatparancsokkal nagyon hatékonyan lehessen kottázni, amellett, hogy a szerkesztő minden fontosabb dolgot ismerjen (ami az eddig megjelent nem túl sok mobilos kottaprogramoknál nem nagyon valósul meg).

A magam részéről a Lilypond nagy rajongója vagyok, de a hozzá tartozó Denemo sok szempontból nem éppen felhasználóbarát. Élő renderelés esetén természetesen nem lehetnek olyan minőségi elvek, mint egy Lilypondnál, de későbbi tervem, hogy egyúttal jól használható Lilypond GUI-t hozzak létre. Az viszont már semmiképp nem egyszemélyes projekt lesz.

Reggel rákerestem a kotta szóra, és a találatok között volt ez. Itt a sorok közti átkötést úgy oldották meg, hogy az utolsó hangjegy alá tettek egy mosolygó szájat, valamint a következő sor első hangjegye alá is.

Teljes gőzzel ezen vagyok.


Erre gondoltál?:
Van egy ScoreObjectDrawer és az abból származó NoteHeadDrawer interfész, amit a NoteHeadRenderer osztály és a NoteHeadBitmap osztály (a dekorátor) valósít meg. Ezek is absztrakt osztályok, amiket majd például az android.2DAPINoteHeaderRenderer, desktop.G2DNoteHeadRenderer és hasonló osztályok konkretizálnak platformonként.

De talán mégis jobb, ha a dekoráció helyett csak NoteHeaderRenderer van, ami lusta betöltés elvén a már kész bitmapot adja vissza, amit szükség esetén helyben generál. (Tehát csak a komponens cache-eli magát.)

Na jó, ezek végülis részletkérdések, a lényeg, hogy minden kis objektumot rendereljek előre, ha lehet.

Sok ARGB bitmap kompozitálásától viszolyogtam. De a héten teszek egy tesztet, ahol minden szorosan összefüggő részt bitmapre cache-elek. A kis objektumok akkor flyhweight módon lesznek megoldva. Végül minden egy nagy kompozittal kerül a canvasra. Nagy reményeket fűzök ehhez a teszthez.

Gondoltam erre is, de végül határozottan a Java mellett döntöttem. Pedig eddig talán a legtöbbet JavaScriptben programoztam. JS-ben már mások is próbálkoznak, és én természetesen sok sikert kívánok nekik. Az én céljaimnak viszont a JS nem a megfelelő eszköz, és nincs annyi szabad időm, hogy ekkora mellékkört tegyek. Mindenképp Java a célplatform.