ugrás a tartalomhoz

Java 2D gyors vektorgrafika

Süsü · 2013. Szep. 16. (H), 01.54
Sziasztok!


Egy grafikai API fejlesztésébe kezdtem bele, melyet egy többplatformos (mobil, applet, asztali) kottagrafikai szerkesztőhöz szeretnék használni. Elsősorban kottagrafikai kalkulációkért és a kirajzolás ütemezéséért felelne ez a library. A lényeg, hogy minimális beállítással egy komponenst lehessen létrehozni, amely a hozzá tartozó canvason megjeleníti a kottaképet. Ez a kottakép természetesen interakcióra képes, az interakció módja viszont már platformfüggő.

A kottagrafikában jártas vagyok, magam is sokat kottázom, ezért is mertem belefogni. A Java sem új a számomra. A problémám az, hogy a Java 2D lehetőségeire nincs elég rálátásom.

Alapvetően Androidra terveztem a szerkesztőt, és elsősorban a memóriával akartam spórolni. Később úgy adódott, hogy mégis a segességet helyeztem előtérbe a tervezésnél. Utóbbinak megfelelően minden soronkénti zenei ütem külön bitmapre került volna, majd a bitmapek megfelelő összeillesztéséért egy külön komponens felelt volna.

Ez azonban több problémát is felvetett. Például nem foglal-e túl sok helyet a memóriában a sok bitmap? Nagyításnál/szerkesztésnél így is folyamatos újrarenderelés szükséges, nem válik-e fölöslegessé az előrenderelés? És nem is minden osztható el ezekbe a bitmapekbe (átkötések, sorváltó szólamok)... Végül úgy kezdtem neki, hogy nincs előrenderelés, minden egyszerre rajzolódik ki a draw eseményre. Hamar kiderült viszont, hogy így nagyon lassúvá válik, ha sűrű a kotta.

Kérdezem tehát az ilyesmiben tapasztaltabbakat, hogy Jávában nagyszámú vektoros grafika kirajzolásánál nagyjából milyen elveket érdemes követni. Fontos még, hogy minél általánosabb legyen a megoldás, mert a platformok közötti eltérések miatt magát a grafikát absztraktan szeretném megoldani (tehát, hogy a canvas objektum és a grafikai könyvtár cserélhető legyen).


Üdv,
Süsü
 
1

Mit jelent az egyszerre?

Joó Ádám · 2013. Szep. 16. (H), 02.10
Mit jelent az egyszerre? Mindenképpen érdemes lenne külön szálban, sorban kirajzolni, hogy amit a felhasználó először lát, az hamar kikerüljön, a kotta vége pedig nem baj, ha csak másodpercekkel később renderelődik le. Ha a kotta mentén vannak kirajzolva a jegyek, akkor annyira nem is néz ki rosszul, még akkor sem, ha látható a folyamat.

Ha a memóriafelhasználás számít, akkor az aktuálisan nem megjelenített képet ne rajzold ki; ha a sebesség számít, akkor gyorstárazz, amit csak lehetséges, akár előre is.

Alap dolog, de ne hozz létre minden lejegyzést külön, csak egyet, amit minden helyen megjelenítesz.

Használsz profilert?
10

Betöltés

Süsü · 2013. Szep. 16. (H), 14.07
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.

ne hozz létre minden lejegyzést külön


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.
2

Kotta nehéz ügy

Pepita · 2013. Szep. 16. (H), 02.35
(Nekem még olvasni is, ha komolyabb mű :))
Mi van, ha egyik sor végéről a következő sor elejére is kell átkötés? (Pl. orgonapedál sok ütemen keresztül.)
Szóval szerintem itt a rajzolással is gondok lesznek, mint a legtöbb zenei szerkesztőben. A régiekben (ugye desktopon) egyetlen sort láttál (szólamonként) és vízszintes görgetés kilóméterszámra.

Szerintem ha meg tudod oldani sorról-sorra is, akkor több képből is.
Lesz belőle zene is? Vagy "csak" kottarajzoló?
3

Ütemközi elemek

Süsü · 2013. Szep. 16. (H), 13.18
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.
5

Betvek

Hidvégi Gábor · 2013. Szep. 16. (H), 13.37
Emlékeim szerint valamelyik általam használt szoftverben a kirajzolást úgy oldották meg, hogy a hangjegyek egy font betűi, és az operációs rendszer beépített függvényeit használták a kirajzolásra.
8

Fwiw: a Unicode kódol

Joó Ádám · 2013. Szep. 16. (H), 13.57
Fwiw: a Unicode-ban pedig vannak kottajegyek.
12

Font

Süsü · 2013. Szep. 16. (H), 14.13
Igen, a font használata bevett módszer, bár a kirajzolás absztrakt szintjén irreleváns, hogy font, svg vagy pure Java-kód a forrása a vektor-adatnak.
33

Hogyan?

Pepita · 2013. Szep. 16. (H), 23.53
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.
Ha MIDI-t csinálsz belőle, nagyon érdekelne a specifikáció és hogyan csinálod (azzal együtt, hogy Java-t nekem csak tanították meg kicsit vizsgáztam belőle, de már rég elfelejtettem).
Ha bármilyen hanghullámot gyártasz, akkor hacsak nem te kevered a frekiket (ez nagyon erőforrásigényes), akkor szinte biztos, hogy hamis lesz. A MIDI viszont pont erre való (mint nevéből is adódik).
34

Na ez engem is érdekelne.

inf3rno · 2013. Szep. 17. (K), 00.09
Na ez engem is érdekelne.
36

Hang

Süsü · 2013. Szep. 17. (K), 00.47
Itt két külön dologról is beszélünk. Az egyik a lejátszás, a másik a mentés MIDI-be.

Lejátszás esetén a logika a fentebb említett proritásos sor, amit a lejátszó iterál, és küldi a hangot a MIDI kimenetre a Java Sound API-n keresztül. Alapvetően a MIDI az egyetlen alternatíva, a legjobb kompromisszum. Egy beep jellegű nyávogás (mint a régi mobilok csengőhangjai) minőségileg elviselhetetlen lenne, olyan szintű hangszintetizáció pedig, mint pl. a Kontakt Player, nem fér el ebben a projektben. Jómagam pedig inkább nem vállalkozom hanggenerálás implementálására.

Mentés esetén a teljes kottát exportáljuk MIDI formátumba, attól függetlenül, hogy a kotta meg van-e nyitva. Ennek megvalósítását későbbre tervezem, mert ehhez alaposabban át kell néznem a MIDI specifikációját, mint eddig tettem. Bizonyos értelemben itt is hasonlóak az elvek a kotta feldolgozását illetően.
37

Na, ez érdekelne

Pepita · 2013. Szep. 17. (K), 02.11
alaposabban át kell néznem a MIDI specifikációját

Ha találsz olyat, amit te értesz is, egy cikkben igazán bemutathatnád... :) (Bár kicsit messi van a webfejlesztéstől, de jövőképet mutat: a telódon írod a saját csengőhangodat - az már valami.)
Komolyan érdekelne, de mikor Delphiben tiff kép olvasást és írást csináltam (mert nem volt rá komponens), belepistultam, mire kibogarásztam meg kijegyzeteltem magamnak...
Pedig csak a tömörítetlen formátumokkal foglalkoztam, de azokból is van vagy 8.
Szóval nagyon érdekelne, hogy műxik a MIDI, ha csak van egy jó doksid (vagy linked rá), megköszönném.
39

Rendben

Süsü · 2013. Szep. 17. (K), 11.18
Rendben, ha eljutottam idáig, szívesen írok egy összefoglalást a tapasztalataim alapján.
42

Köszi!

Pepita · 2013. Szep. 19. (Cs), 01.59
Várom.
6

Átkötés

Hidvégi Gábor · 2013. Szep. 16. (H), 13.46
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.
9

Ez eléggé bevett, én még csak

Joó Ádám · 2013. Szep. 16. (H), 14.03
Ez eléggé bevett, én még csak ilyenből játszottam.
11

Na, csak nem

Hidvégi Gábor · 2013. Szep. 16. (H), 14.11
Na, csak nem zongoráztál(/zol) te is?
20

Egy nyolc évet :) De fel kéne

Joó Ádám · 2013. Szep. 16. (H), 14.59
Egy nyolc évet :) De fel kéne hangolni.
4

Próbáltad már SVG-vel?

inf3rno · 2013. Szep. 16. (H), 13.35
Próbáltad már SVG-vel?
13

http://upload.wikimedia.org/w

inf3rno · 2013. Szep. 16. (H), 14.19
http://upload.wikimedia.org/wikipedia/commons/4/41/Adeste_Fideles_sheet_music_sample.svg

https://github.com/0xfe/vexflow

stb...

svg-ben szerintem van már egy csomó ilyen rendszer, annyi plusz kell bele, hogy hozzácsapod a kirajzolást és a mozgást, bár talán még az is benne van egyikben másikban...

De ha nem akarsz más rendszereket megnézni, svg-ben akkor is itt van az összes kottában előforduló dolog:
http://en.wikipedia.org/wiki/List_of_musical_symbols
15

Igen de,

Süsü · 2013. Szep. 16. (H), 14.36
... ez azért kevés, ebből még nem lesz magától organikus kottagrafika. A "rendszer", vagyis a szimbólumok rendszerezése már megoldott, a probléma épp a kirajzolási mechanizmus optimalizálása. Más gondom nincs.

A vexflow egy nagyon ígéretesnek tűnő projekt, de nem Java, és nem egy interaktív canvast kezel.
19

Hát koncepciónak svg-ben elég

inf3rno · 2013. Szep. 16. (H), 14.58
Hát koncepciónak svg-ben elég annyi, hogy csinálsz két réteget. Az egyik álló, és a vonalakat tartalmazza, a másiknál meg hangjegy csoportokat adhatsz hozzá, illetve vehetsz el a dom fából, és közben mozgathatod őket, ahogy telik az idő. Sebességre fogalmam sincs, hogy ez mennyire lassú. De ha már minden más megvan, akkor nincs értelme foglalkozni vele.
28

Annyira azért...

Süsü · 2013. Szep. 16. (H), 17.43
Annyira azért nincs meg minden. Lényegében egy alap kalkulációs library van meg, és egy-két demo, amik sajnos eléggé hajlamosak belassulni. Úgyhogy lehet, hogy az SVG-vel is teszek egy próbát. Korábban már nézegettem is az SVG Salamandert, de nem tudtam, hogyan használhatnám föl. Most viszont fölmerült bennem, hogy az egész kirajzolt kép lehetne egy nagy SVG, talán épp erre gondolsz.
31

Ja, arra gondoltam, hogy egy

inf3rno · 2013. Szep. 16. (H), 20.03
Ja, arra gondoltam, hogy egy nagy svg lenne a kép, ami elkérné a szervertől az adatokat, esetleg már eleve tartalmazná őket. A szerverrel való kommunikációt később is bele lehet tenni, egyelőre azt érdemes próbálgatni szerintem, hogy össze tudod e hozni vele az animációt, amit akarsz. Ehhez js és svg tudás kell minimális. Ez a lib, amit ajánlani tudok a kirajzoláshoz, de még én sem nagyon foglalkoztam a témával: http://raphaeljs.com/

A java salamander nem tudom, hogy mennyire használható ilyen célra, vagy egyáltalán képes e js-t futtatni, vagy csak java-ból lehetne belenyúlni a kirajzolásba. Bonyolult téma, főleg úgy, hogy lövésem sincs androidhoz, még sosem fejlesztettem rá... http://stackoverflow.com/a/9333274/607033 Azt írjá, hogy android 3+ böngészők alapból támogatják svg-t, a 2.x-eseknél canvassal meg lehet oldani. Ugye jól gondolom, hogy ez böngészős alkalmazás lesz, és nem asztali? Ha asztali, akkor ez felejtős, mert szerintem a piacon lévő megjelenítők csak átkonvertálják swing vagy awt objektumokra az svg-t, amit kapnak, és úgy meg biztos, hogy lassabb lesz...

Nézegettem a salmandert, elvileg nem átfordítja más java lib-re, viszont nálam az animációk egyáltalán nem működtek benne, volt olyan, ami el sem indult, szóval én nem alapoznék rá. Ha nem böngészős dologról van szó, akkor felejtős, hacsak nem találsz valami jobbat, mint a salamander.
35

Sajnos nem

Süsü · 2013. Szep. 17. (K), 00.24
Mint a bevezető postban írtam, többplatforomos program lesz, az applet csak egy opció. A fő platform elsőkörben Android, bár előbb az alap API-t egyelőre asztali környezetben fogom tesztelni. Én a Salamanderrel elsőre nem láttam problémát, ennek ellenére nem az SVG lesz a nyerő. Egylőre maradok az eredeti elképzelésnél, azzal a fő módosítással, hogy a legnagyobb előrenderelt egység az AccordAmbit, azaz az akkord hangjaiból és minden módosító, kísérő jeléből álló objektumegyüttes lesz.
40

Ja, én is inkább ezt

inf3rno · 2013. Szep. 17. (K), 13.12
Ja, én is inkább ezt javaslom. Az svg csak felesleges mellékvágány lenne.
41

Azt írják, hogy max

inf3rno · 2013. Szep. 17. (K), 14.48
Azt írják, hogy max webview-ban működhetne a dolog androidon, a salamander biztos, hogy el sem fut rajta. Meg úgy általában az svg-s animációk nem fognak menni, mert gagyik a könyvtárak hozzá. Az "Android Canvas API" amit ajánlanak a témában, ahogy nézem te is azt használod.
7

Tervezés

vbence · 2013. Szep. 16. (H), 13.49
Egy egyszerű, általános intefészt tervezz meg. A cache-elés ennek nem kell hogy része legyen.

Ha használtál Javát biztos tisztában vagy a legtöbb népszerű tervezési mintával. Egy komponens cache-elésére (bitmap-ba) logikus választás például egy decorator pattern. Persze ez a dizájn nem akadályozza meg, hogy a komponensek cache-eljék önmagukat (ha úgy látják jónak).

Számomra első blikkre nem egyértelmű, mi jelent problémát a kirajzolásban (25% ellipszis, 60% egyenes vonal, 15% egyéb bezier-görbe). Memóriaproblémát sem látok abban, ha egy objektum mogatásakor lerendereled mi van alatta, mi van fölötte, aztán dinamikusan kompozitálod a 3 bitmapot (akár hardver-támogatással akár anélkül).
14

Interfész

Süsü · 2013. Szep. 16. (H), 14.27
Egy egyszerű, általános intefészt tervezz meg.

Teljes gőzzel ezen vagyok.

Egy komponens cache-elésére (bitmap-ba) logikus választás például egy decorator pattern.

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.
16

Cache

vbence · 2013. Szep. 16. (H), 14.39
"a lényeg, hogy minden kis objektumot rendereljek előre, ha lehet"


Ezt nem mondtam. A cache nem szerves része a feladatnak (kotta rajzolás), ez azt sugalja, hogy csak fölöslegesen bonyolítaná az interfészeket, ha egy szinten akarjuk megvalósítani a kritikus funkciókkal.

Az, hogy mindent külön bitmapban kell tárolni nem feltétlenül jó ötlet. 4 voanlat egyszerűbb rajzolni, mint bitmapokat kompozitálni (egy bizonyos méretnél).
18

Bitmapok

Süsü · 2013. Szep. 16. (H), 14.53
Értem, és elfogadom, amit mondasz. A tervezésnél igyekszem figyelni a megvalósítástól való erőteljes függetlenülésre. Bár már ezen a ponton is aggódtam amiatt, hogy ezirányú tapasztalatlanságomból kifolyólag olyasmit tervezek, ami az implementációt alapvetően nehézkessé teszi. Aki a grafikában nagyon otthonosan mozog, nyilván azt mondja: "tervezéskor nem gondolok az implementálás részleteire", valójában azonban (legalább tudat alatt) nagyon is előre számol a lehetséges implementálási nehézségekkel. Utóbbit én most nem tudom megtenni, és korrigálni is nehezebben fogok tudni. Ezért akarok előre tisztázni, amit csak lehet. "Előbb tanulok, aztán vadulok."

Egy téglalap vagy vonal kirajzolását nyilván nem érdemes cache-elni. Viszont akkor hol a határ? Tulajdonképpen pont ezt próbálom kipuhatolni. (Nyilván meg lehet ezt úgy is csinálni, hogy a cahe-elés skálázható legyen platform/beállítás szerint.)
22

Én szerintem először csináld

inf3rno · 2013. Szep. 16. (H), 15.01
Én szerintem először csináld meg a lehető legegyszerűbben, ahogy tudod, és csak utána foglalkozz az optimalizálásával. Gyorsabban jutsz így használható eredményre, és egyáltalán nem biztos, hogy szükséges plusz munkát befektetni a sebesség, vagy memória használat miatt.
27

Igaz

Süsü · 2013. Szep. 16. (H), 17.32
Bölcs tanács. Lehet, hogy így lesz.
23

Minél több az absztrakció,

Hidvégi Gábor · 2013. Szep. 16. (H), 15.10
Minél több az absztrakció, annál lassabb lesz. Én nem vacakolnék: első körben felderíteném, hogy az adott sorba hány ütem fér, aztán az ütemeken belül a hangjegyeket és a szüneteket. A sornak rajzolnék egy nagy fehér hátteret, meghúznám a csíkokat (vízszintes, függőleges), kirajzolnám a hangjegyek fejét, aztán a szárukat, aztán a zászlót, legvégül meg a szüneteket és a kacinfántokat. A hangjegyek feje meg vagy teli vagy lyukas, ennyit lehet catch-elni, meg a szüneteket.
26

Ez egy kicsit bonyolultabb...

Süsü · 2013. Szep. 16. (H), 17.29
Ez egy kicsit bonyolultabb, szerintem.

Előszöris, az ilyen szinten cache-elhető objektumok száma nem az üres és nemüres kottafejekre korlátozódik (khm. eleve négyféle általánosan használt kottafej van, plusz legalább egy tucat speciális, nem beszélve a kishangjegyekről), hanem kulcsokra, módosítójelekre, pontozásra, trillákra, arpeggiojelekre, pedáljelekre stb-stb.

Bizonyos jelek bizonyos szinteken egy jól megfogható csoportot alkotnak (akkordok a hozzá tartozó módosítókkal), amelyeket kívülről kizárólag a szárirány befolyásol, és így a környezettől függetlenül renderelhetők. Ezért gondoltam, hogy ezekhez is lehetne bitmapes cache-et rendelni. Az összekötött zászlók kirajzolása is bonyolult feladat, persze erre is megvannak az algoritmusaim.

Fontos, hogy bizonyos dolgokban nem akarok korlátozásokat. Ebben a filozófiám megegyezik a Lilypondéval. Tetszőleges számú szólam lehet. És ha belegondolsz, ezek összeillesztése nem egyszerű. Erre természetesen szintén megvannak a hagyományok és az algoritmusok, mindössze azt demonstrálom, hogy a kotta nem egy egyszerű dolog.

Nem lesznek sorok az interaktív módban, egyelőre legalábbis biztosan. Csak papíron van értelme a sorokba tördelésnek, a szerkesztés közben és lejátszáskor is sokkal jobb, ha csak egyetlen (tetszőlegesen) hosszú sor van (különösen mobil eszközön). Az, hogy hány ütem fér egy sorba, szintén nem egyszerű, egy kellően intelligens sortörési algoritmus kell hozzá. A kinyomtatás/PDF-gyártás más kérdés, ott már nem kell az interakcióval és a kirajzolás sebességével ilyen szinten foglalkozni. De arra meg azt mondom, inkább ott a Lilypond, amibe természetesen lehet majd exportálni.
32

Nézd meg amit linkeltél...

Pepita · 2013. Szep. 16. (H), 23.47
Én nem vacakolnék: első körben felderíteném, hogy az adott sorba hány ütem fér
Ezt már csak akkor tudod, ha kész a kotta. A hangjegyek számától függ, az pedig a dallamtól és az ütemtől.
Én első körben megrajzolnám az egész kottát szólamonként egy-egy hosszú sorban, és a legvégén foglalkoznék azzal (elejéről indulva), hogy melyik ütemek végén kell "sort törni", ott javítanék a szmájlikon, ha vannak.
17

Kompozitálás

Süsü · 2013. Szep. 16. (H), 14.41
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.
21

Pixel format

vbence · 2013. Szep. 16. (H), 15.01
Neked igazából grayscale elég (persze ha a platform támogatja). Alpha se kell, mert a papír tradícionáisan fehér. Nem vagyok túlságosan mívelt zeneileg, de én úgy látom, ha például "üres fejű" hangjegyet nyomtatnak, akkor azon keresztül "átlátszik" a kottavonal.
30

Nem értem

Süsü · 2013. Szep. 16. (H), 18.07
Természetesen nem is úgy terveztem, hogy a cél-canvas legyen áttetsző. Viszont a grayscale bitmapet hogyan teszem a vonalra, hogy átlátszódjon a vonal? Vagy arra gondolsz, hogy keverjem a csatornákat és a fehérség konvertálódjon átlátszóságba (mint az OpenGL-ben az ilyen transparency layer-szerűségek)?
38

Kompozitor

vbence · 2013. Szep. 17. (K), 10.11
Lehetnek korlátok a kompozitáláskor. A legegyszerűbb módszer, amikor kézzel másolod a bájtokat a cél-bitmapra mindneképpen megengedi ezt.

A kutatás fázisa nagyon fontos, amikor megkeresed az API-kat, amik kielégítik a követelményeidet, esetleg egy kisebb sebességtesztet is futtatsz a saját "hello world" kódjuk segítségével. - Ilyenkor megismerheted az egyes libraryk által használt modelt, ami segít a tervezésben.
24

Platformfüggetlenség

Hidvégi Gábor · 2013. Szep. 16. (H), 15.39
Az újabb böngészőkben már használják a hardveres gyorsítást: szerintem érdemes lenne kipróbálni, hogy ha ezt az egészet JS-ben készíted el, az milyen sebességet produkál.
25

Svg + ajax/socket.io-val

inf3rno · 2013. Szep. 16. (H), 16.42
Svg + ajax/socket.io-val szerintem néhány nap alatt össze lehetne dobni nulláról a megjelenítést és scrollozást, esetleg még hang alákeverést is... Azt hiszem be is rakom a hobbi projekt listámba, úgysem használtam még egyiket sem...
29

Gondoltam erre is, de...

Süsü · 2013. Szep. 16. (H), 18.01
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.