Vizualizace hudby na Futuro Cube

18.9.2013 22:59 | Přečteno: 1300×

Ze zvědavosti jsem si pořídil Futuro Cube, snad jediný český výrobek na ThinkGeeku. Zalíbila se mi existence SDK (které mi po několika emailech dokonce poskytli i pro Linux ) a prostorovost jednotlivých "her", reakce lidí "co to sakra je" jsou taky fajn . Když už mám SDK, tak jsem se rozhodl si trochu pohrát a napsat pro Futuro Cube jednoduchý prográmek pro vizualizaci hudby. Trochu jsem narazil, když jsem zjistil že Futuro Cube nemá mikrofon, ale i tak se nakonec povedlo ...

Nejdříve ukázka o co vlastně jde: krátké video. A pro úplnost: github projektu.

Kolega doporučoval ať zneužiju akcelerometr, ale tak nahlas mi hudba zas nehraje (a i tak si sousedi občas stěžují...). Raději jsem se podíval na dokumentaci k SDK a zjistil, že se dají LEDky ovládat pomocí správných příkazů přes USB emulaci sériového portu (USB CDC ACM). Samozřejmě, nevýhoda tohoto přístupu je, že kostka musí být připojená přes USB k počítači. Výhoda je, že to funguje.

Musím přiznat, že jsem na začátku vzal *.pyc z SDK, pustil na ně uncompyle2 a pohrál si s takto dekompilovanýma "zdrojákama" dokud kostka nedělala co jsem chtěl . V takovémto stavu jsem projekt nechal poslední dva měsíce, než jsem si vzal včera sick day. Tady bych se trochu pozastavil nad tím, že je SDK distribuováno jako python bytecode a ne zdrojáky, vždyť není problém z bytecodu zdrojáky jednoduše dostat a navíc python negarantuje kompatibilitu bytecode ani mezi minor verzemi.

V neděli jsem se vrátil z jednoho z mých výletů do Dublinu, o kterých jsem tady nedávno psal . Tenhle víkend byl takový emocionální roller coaster, že jsem si v útery raději vzal volno. V teamseeru (správa absencí) už jsem pomalu registroval můj "heart-break" jako "sick/cardiac", ale o extra vysvětlování v práci jsem fakt nestal a změnil důvod na "sick/headache or migraine" . Každopádně celý den na posteli (sám :'( ) byla idealní příležitost dodělat tenhle projektík. Tak jsem začal od začátku, konečně se podíval jaká data SDK vlastně kostce posílá a naimplementoval vše co je potřeba od začátku nad pyserial a pyudev (+forknutý impulse pro získání a zpracování dat z PulseAudio). Nakonec se vše vešlo pod 300 řádků pythonu: zdrojáky na githubu.

Instalace je přímočará:

# instalace závislostí (na Ubuntu)
sudo aptitude install git gcc make python-dev fftw-dev libpulse-dev python-serial
# clone git repa, kompilace
git clone https://github.com/luv/impulse-cube.git
make

A teď uz stačí zapojit kostku a pustit:

./impulse-cube.py

       

Komentáře

[Ivorne]

Lze pro ni vyvíjet i v něčem jiném, než v pythonu (např. C++)?

Tedy zkusil jsem spustit to sdk a hned to padlo na tom, že v cestě, ze které to spouštím je použit znak mezery. Binární soubory v adresáři compiler jsou jenom 32 bitové. Do adresáře doc/license nacpali texty všech možných licencí (gpl, apache, mit, bsd), ale zdrojáky tam nikde nejsou.

TLDR: moc důvěry to ve mě zatím nevzbuzuje. Na první pohled to vypadá spíš jako zase další softwarová spatlanina, která kašle na jakákoliv práva uživatele i vývojářů a jakékoliv vývojářské konvence. Fakt nevím, co si o tom mám myslet.

[smazáno]

Normalne se pro kostku vyviji v Pawn. Ten muj python je nezavisli hack

[Igor Bodlák]

Chtěl bych především reagovat na vaši námitku ohledně licencí. Balík SDK neobsahuje nic, co by bylo pod GPL licencí. Tudíž tím, že nepřikládáme zdrojáky, neporušujeme ničí práva. Informace ohledně použitých knihoven jsou v souboru 'license.html'. Všechno je licencováno pod LGPL, MIT, BSD a podobnými licencemi, které poskytnutí zdrojáků nevyžadují. Pravda, je trochu matoucí, že v adresáři licence je uveden i text GPL, ale ten je tam jen proto, že na něj jako referenci, odkazují jiné licence. Navíc, balík pro linux je dodáván bez knihoven, které se musí nainstalovat z distribuce, takže v tomto případě bychom ani nemuseli texty licencí uvádět. Ohrazuji se tedy vůči nařčení z porušování něčích práv.

Co se týče ostatních výtek, uznávám, že na nich něco je. Přiložené binárky jsou pouze 32 bitové, struktura adresářů v SDK skutečně neodpovídá linuxovým zvyklostem, a že to spadne na mezeře v názvu adresáře rozhodně není dobře. Ale po doinstalování správných knihoven lze SDK spustit na 64bitovém stroji (což je uvedeno i v instalačním návodu), linuxovou strukturu adresářů, dle mých zkušeností, nedodržuje většina proprietárního SW a i dost open-sourcového, a tu mezeru jsme neotestovali, což byla chyba.

Pokud výše uvedené podle vás postačuje na označení spatlanina, nelze vám to rozmlouvat. Minimálně náznaky tu jsou. Osobně bych to spíš nazval kompromisem, který nás stál tak málo sil, že jsme byli z komerčního pohledu vůbec schopni obhájit vznik linuxové verze. Pro informaci, interně jsme diskutovali i to, že bychom spustili vlastí PPA pro Ubuntu, a SDK distribuovali jako deb balíček, ale minimálně prozatím to bylo zamítnuto.

(Igor Bodlák, vývojář z Princip a.s.)

[Ivorne]

Díky za košatou odpověď. Ten kompromis v rozvoji Linuxové verze SDK chápu a jsem vděčný za alespoň nějakou podporu Linuxu. Mohu se ještě dodatečně zeptat, proč pro SDK nezvolíte také nějakou open-source licenci? Předpokládám, že váš zisk není založen na distribuci SDK, takže větší rozšíření SDK (díky otevřenější licenci) by vám jedině pomohlo.

[Igor Bodlák]

Proč neudělat SDK pod open-source licencí? Budu mluvit za sebe, ne za firmu. Také upozorňuji, že sám na kostce ani SDK nepracuju. Popravdě mě napadá ještě více přínosů, než jste vyjmenoval. Proč to tedy neděláme? Myslím, že je to hodně ze zvyku, ostychu a také proto, že v open-source je skryt jistý závazek. Jak něco otevřete, špatně se to bere zpět. Zaručte se kolegům na poradě, za to, že to třeba v budoucnu nebude nějakému obchodnímu partnerovi vadit. Také bychom pak cítili povinnost poskytovat veřejně k projektu podporu a programátorskou dokumentaci, což bere čas. Já jsem dlouholetý linuxák a moje vidění těchto otázek je tím jasně ovlivněno ve prospěch open-source, ale pro někoho zvyklého na filosofii windows není přechod na open-source tak přirozený.

Tedy ve zkratce. Normálně děláme uzavřený SW a nikdo zatím nerozhodl udělat to v případě SDK pro FuturoCube jinak. Třeba se to změní.

[Ivorne]

Třeba se to změní.

Snad ano.

To, že je open source závazek je častý argument, ale vydávat closed-source je také závazek. Jen už si většina lidí zvykla na to, že close source projekty na tyto závazky často kašlou, takže na něj nejsou takové nároky. Uživatelé jsou pak vývojářům vděšní už za to, že jednou za čas vydají novou verzi.

Programátoři jsou na svůj kód kolikrát až přehnaně žárliví a nechtějí jej nikomu dávat. Potom v oteřvení svého kódu vidí jen ty nevýhody (jako jistou ztrátu kontroly a komplikace při potenciální snaze kód zase uzavřít) a vůbec si neuvědomují ty zásadní výhody. Vždyť Futuro Cube je produkt, který si o open-source a budování komunity přímo říká. Chcete aby si lidé o kostce říkali navzájem a aby sdíleli programy, které pro kostku vytvořili. Myslím si, že právě investice do budování SDK a komunity je to, co může kostku někam posunout a vydělat.

Ono se mi to mluví, když nenesu tu zodpovědnost . Možná se pletu ve své představě o tom, co Futuro Cube je a nemyslím si, že něco změním jedním příspěvkem. Ale Futuro Cube mě na první pohled hodně nadchlo. Taková hračka je snad snem každého programátora.

[Igor Bodlák]

Open-source kabátek by kostce určitě slušel, o tom asi nikdo nepochybuje. Doopravdy si o to říká. Na druhou stranu si nejsem jistý, že by SDK někoho skutečně zajímalo jako projekt, do kterého by chtěl přispívat. Jde přeci jen o pracanta, který pouze přesouvá data z místa A do místa B, což je vcelku nuda. Zajímavější by pro komunitu možná byla podrobnější dokumentace API, aby se nebylo nutné hledat informace v kódu (nebo byte-kódu :}). I když bych se nedivil, pokud by právě tohle byla výzva, která donutila autora článku pustit se do práce :}.

Jenže do čeho se autoři mají pustit dřív, když mají hlavu plnou dalších nápadů? Nicméně je budu informovat o vašich názorech, pokud to už nečetli, což asi ano.

[Jendа]

Na druhou stranu si nejsem jistý, že by SDK někoho skutečně zajímalo jako projekt, do kterého by chtěl přispívat.

Jde o to, že za pár let přestanete tuhle kostku podporovat, a za dalších pár let už třeba nebude možné provozovat Python 2 nebo nějaké ty libky, na kterých je to (binárně) závislé. Takže kdo si koupil kostku, bude mít těžítko. Stejně, jako se staly těžítkem grafické karty vyjmenované dole na této stránce. Zatímco z Linuxu je podpora pro hardware odstraňována více než 20 let po zastarání a v době, kdy ten HW fakt už opravdu nemá využití, closed-source vendoři klidně dropnou pár let starý produkt - ať už proto, že je to „nebaví“, zkrachují nebo chtějí zákazníky donutit, aby si koupili novou verzi.

Dále samozřejmě takové věci jako provoz na ne-x86 architektuře (RPi, mobil) nebo prostě svoboda zkoumat a vylepšovat. Já jsem třeba desetinásobně zrychlil Krakena a nesmím to dát dál, protože kokotská licence.

[Igor Bodlák]

Chyba spuštění, je-li v cestě mezera, bude opravena ve verzi 0.9. Díky za upozornění.

[retroslava]

Soundtrack: B-Complex - Beautiful Lies

[skywaker]

mam na predaj LED Cube 5x5x5, zelene ledky pripojene na STM32F0, predavam spolu s STM32 kedze to mam zadrotovane. pridam aj jednoduchy priklad "blink" je to super na hranie ak ma niekto zaujem, neviem ako by som to ale poslal postou kedze je to urcite krehke. aj ked drzi to pohromade dobre. LED Cube 5x5x5 with STM32F0 ARM cpu