-
Notifications
You must be signed in to change notification settings - Fork 0
vesko summary.md
Хей хей, йо,
Рап summary четеш, малко котенце решеш,
взимаш ноз, палиш бос, дебъгваш codez
кликаш на бутона и ѝ влизаш в панталона
римите редиш, lines of code броиш,
бараш се по сървъра, пускаш pull request
цъкаш generate - бийч, айм ди бест
Окей, whatever, след този жалък опит за фрийстайл ще обобщя с какво се сблъсках през този спринт.
Сред една от многото идеи за развитие на рап генератора беше автоматично "изпяване" на генерираните от компютъра рап рими. Казах си - какво толкова, ще ползваме някой Text to Speech (tts накратко) сървис, ще го пуснем малко по-бързо и ще се получи. В крайна сметка има няколко аспекта, които може да представляват проблем. Напоследък излизат все повече tts сървиси, библиотеки и т.н. Това най-вероятно е породено от "нуждата" от лични асистенти в мобилни и не-мобилни устройства, за нашият use case това звучи идеално. Изпробвах няколко такива сървиса, като таих големи надежди на Watson. Това, което пропусках обаче беше, че много от любимите ни изпълнители (Дж-но. и К-ьо.) пеят на български, съответно текстовете на песните трябваше да са на български, а Text to Speech сървисите на големите играчи в сферата (IBM, Google, Microsoft) поддържат много малко езици, в които не е включен българския. От text to speech engine-ите, които поддържаха български, най-разпространеният беше Espeak Проекта изглежда piece of code от 90те, и това е, защото е стартиран тогава, но пък е доста популярен в community-то. Има GitHub форк / mirror на sourceforge кода (https://github.com/rhdunn/espeak), в който community-то е решило да надгради някои от функционалностите. Espeak има супер роботизиран глас, но поддържа български, инсталира се сравнително лесно като binary dependency на windows/linux/mac и работи доста добре. Позволява опции за контрол на pitch/speed и разни такива за гласа, ако не ви хареса нещо по произношението в езика имат на пръв поглед интуитивен начин за изграждане на езиците (някакъв техен фонетичен синтаксис, с който можеш да опишеш какъв текст как се произнася и да имплементираш например клингонски tts). Във въпросното Github репо е засегнат и проблема с роботизирано звучащият глас, не успях да го изпробвам, но изглежда обещаващо. За нуждите на нашият рап gangsta генератор използваме Espeak.
За целите на рап генератора трябваше да можем да комбинираме записа с гласа на потребителя с rap бийтове. Когато добавиш бийта към звука се получава наистина драматичен ефект, колкото и фалшиво да пеем. За обработка на аудио файловете използвахме PyDub (http://pydub.com/). Доста готина, активно поддържана python библиотека за аудио обработка. Де факто отново има binary модул, върху който това е python wrapper, но това е повече плюс отколкото минус. Библиотеката използва като dependency ffmpeg или libav библиотеките. [https://github.com/jiaaro/pydub#getting-ffmpeg-set-up](More info.) Добрата новина е че те поддържат енкодиране и декодиране на повечето (всички?) audio и видео стандарти. Съответно когато Chrome изпрати webm (което е нещо като mkv (матрьошка) формата - може да съдържа в себе си видео и аудио с най-различни encoding-и) encode-нат с VP8 кодека на chrome, FFMPEG нямаше никакъв проблем с декодирането и прочитането на файла. (Имаше проблем, първоначално отказваше да чете VP8 енкодинг, оказа се че съм сложил по-стара версия на FFMPEG, обнових го и всичко беше ток и жица..). С pydub и помощта, която той получава от FFMPEG направихме комбинирането на аудио/видео/рапбийт потоците.
За да звучи добре гласът имахме идея да се опитаме да го направим да звучи като Криско. Това се оказа не толкова лесна задача, колкото звучи (you don't say). За разлика от image манипулациите за audio има много малко готови решения за манипулиране на звук, добавяне на ефекти към него и т.н. Това най-вероятно се дължи на липса на demand, но повечето неща, на които попаднах позволяваха само много low level манипулация на аудио потока. Това разбира се звучи супер, можем да приложим наши алгоритми за изкривяване на звука и да се опитаме да докараме някакъв резултат, но основната насока на задачата щеше да се измени и крайният резултат щеше да бъде непредвидим. Дори и да се постигне резултат най-вероятно ще има много променливи, които ще трябва да се коригират ръчно за всяка ситуация и автоматизирането на обработката на звука ще бъде тегав процес.
Попаднах на едно open source решение - библиотека за autotune (https://github.com/ederwander/PyAutoTune), която е главно реализирана на C++ и е от своя страна базирана на ladspa (https://en.wikipedia.org/wiki/LADSPA) плъгин - http://tombaran.info/autotalent.html Идеята на библиотеката е да направи 2 стъпки в обработката на звука - pitch detection (в каква тоналност пееш?) и pitch correction (айде да пееш в правилната, а?). Проблемът с нея, както можете да видите и от repo-то е, че последната активност е била преди повече от 5 години, а autotune плъгина, на който е базиран е направен като мини проект. Quote от сайта: Over a week at the end of May 2009 I had a go a writing a real-time pitch correction plugin. За жалост имаше доста outdated код в него и не успях да го подкарам. Успях да подкарам Emscripten порт на C++ кода към Javascript (https://github.com/maxogden/autotune.js) (главно защото беше прекомпилиран), където обаче също няма активност и в описанието на repo-то пише че е: slow and broken at the moment - твърдение, което беше абсолютно правилно.
Теорията за autotune е интересна, има комерсиални/платени решения в професионалните софтуери за аудио обработка, а при интерес може и да се опитаме да разпишем такава функционалност.
За целите на audio манипулатора (миксиране на аудио+видео+бийт), листване на бийтове и генериране на Text to Rap беше необходимо API, с което да комуникира фронтенда. За целта реших да реализирам API компонента в проекта на Django фреймуърка. Предвид, че нямах никакъв опит с Django и задачата, за която беше използван тук е сравнително елементарна фийдбека ми за него няма да е пълен, но въпреки това го споделям.
Като цяло останах доволен от нещата, които видях в Django. Обяснения и примери за малкото неща, които се опитвах да направя бяха лесно намерими в Google и добре обяснени пример и пример . Ако търсите от къде да започнете - в официалната документация на Django има доста добри getting started туториали - https://docs.djangoproject.com/en/1.10/intro/.
В конкретния ми use case имах малко време да имплементирам няколко много прости POST request-а, всички уроци, които видях използваха форми за задачата. Във формите се описват входящите параметри, типовете им, валидации и т.н., като със създаването на form обект той верифицира GET/POST параметрите и ни дава достъп до филтрирания user input. Този подход ми се виждаше една идея по-сложен, от това, което исках да направя, но предвид, че повечето статии онлайн го използваха реших да не си губя времето в търсене на по-прост вариант и да имплементирам форми. Tук има малко инфо за формите от което skip-нах само HTML частта, понеже правих API. В крайна сметка имах няколко файла повече, не бях загубил много време в лутане и имплементация, но пък бях получил валидация и можех без усилия да render-на HTML, с които да тествам формата си (input-и за полетата, които ползвам). Предвид, че не съм писал тестове за проекта този вариант на ръчно тестване беше много по-лесен отколкото ръчното тестване през Postman. Ако се опитам да сравня формите в laravel с тези в Django - там липсват, а тук са готини.
Routes - отново съм ползвал много малко и наблюденията ми са доста бегли. Описват се route-овете, като най-просто казано се мачва regex към функция в контролера, има си параметри и т.н. Поддържа групиране, middleware и всичко останало. (https://docs.djangoproject.com/en/1.10/topics/http/urls/)
Вдигането на локален development сървър става с една команда идваща наготово при генериране на django проект. Сървъра следи промени по файловете и се рестартира (при добавяне на файлове може да се наложи да го рестартирате ръчно). Ако не сте се сблъсквали отблизо с python - при вдигане на сървъра файловете се четат и прекомпилират (не като в php), един процес обработва по един request at-a-time (не като в nodejs) и интерпретираният код не върви във виртуална среда (не като в java). С две (4?) думи Python "does its own thing". За Production environment може да се използва uwsgi модул и nginx More info, който реално да обработва повече request-и.
Организацията на кода в Django е ясно дефинирана, но може да се надгражда. Кода е организиран в отделни модули (като bundles в symfony 2). От по-интересните django неща, които не съм използвал в проекта е ORM-а, за него и за останалите аспекти на Django нямам по-подробни наблюдения, но определено бих разцъкал повече в бъдеще.