#Cadencia

Сьогодні пост не про LLM! Я теж радий.

Я тут роблю застосунок для розбору пісень для танців. Кілька місяців тому зробив онлайн варіант, але зараз переробляю у вигляді мобільного застосунку. Традиційно, 80% зусиль пішло на аспект, який здавався мені тривіальною базою, яка сама по собі нікому й не потрібна.

Отже, в серці застосунку лежить те, що інтерфейс рухається в такт пісні. Насамперед рахує удари — як метроном. Для того ми визначаємо BPM - удари на хвилину, привʼязуємо перший удар, і потім в момент часу T нескладна математика каже нам, що грає удар N вісімки M, ну з цим проблем ніяких.

Але виявилося несподівано складно відтворити це в інтерфейсі. Здавалося б, будь-який програвач таке вміє. Не зовсім. Біт на екрані розповзався від звуків пісні. Я довгий час думав, що то в мене нема хисту визначити BPM та оскільки помітити десинхронізацію треба на око (та вухо), це було дуже важко підтвердити. Але без нормальної привʼязки до аудіо решту функцій можна було не будувати.

Першим чином я думав, що гальмує React Native? (Ну бо це те, з чим знайомий.) Трішечки такого ефекту було, але насправді біт в пісні це близько 500 мс, та ніякий RN настільки не гальмує. Звісно, оптимізувати було що, бо екран пісні, як бачите, жирний та весь його перемальовувати не гарно. Тут нічого особливого.

Друге — затримка аудіовиходу. Така затримка є, особливо якщо програвати через Bluetooth вона сягає 200 мс та більше… Але то теж навіть не один удар. Втім, дізнався, що принаймні в iOS є вбудована можливість дізнатися тривалість затримки поточного виходу. (Та звісно — в кожного виходу власна затримка.) Що й потрібно для того, щоб відповідно затримувати оновлення інтерфейсу. На щастя, це одноразове та автоматичне покращення, та хоч я зробив інтерфейс для редагування цієї затримки, базових налаштувань достатньо.

Справжні цікавинки почалися, як закопався у формат файлів. Власне, помітив, що на відміну від моєї замученої піддослідної пісні, інша грає та перемотується без жодних проблем. Між піснями знайшлася важлива технічна різниця. Отже: для точної перемотки потрібне кодування з CBR, тобто сталим бітрейтом, (а не VBR - змінним). Оскільки не бачу сенсу вимагати CBR від користувачів, впровадив перекодування в CBR на вході. Зберігав я у формат AAC.

(Змінний бітрейт суттєво ефективніше, я памʼятаю ще як перекодовував власну колекцію MP3, щоб більше влізло в плеєр. Суть його в тому, що простіші місця пісні будуть стиснуті більше.)

Перехід до CBR відразу зробив перемотку стабільною. Це був очевидний успіх. Але зʼявилася нова дивна річ: певні місця в пісні завжди перемотувалися неправильно. Ну, наприклад, в той час, як перемотуєш на другий удар, грає ще перший. Причому, тільки після певної перемотки! Якщо грати з початку пісні, такого не було.

Тут я дізнався ще один нюанс: файл AAC не “проіндексований”, це плаский потік даних. Тому, хоч перемотка і працювала стабільно, але не завжди вона була точною. (А мені, на відміну від типового програвача, потрібна ідеально точна перемотка.) Виявилося, що залишається загортати потік AAC в контейнер M4A. M4A як раз додає індекс, метадані тощо. От ніколи не думав про медіакодеки та медіаконтейнери, а довелося.

Та, о щастя, пісні в CBR M4A відтворюються так, як треба! База, про яку ніхто й не подумає, закріплена надійно.

Отже, на минулому пості мої пригоди з базовими потребами застосунку не закінчилися.

Помітив, що у фоні застосунок грає музику недовго, та зупиняється. А складно не помітити — бо я відразу почав використовувати його для власних тренувань. В застосунку є можливість зациклити певну частину пісні, що мені дуже спрощує життя. Тож вмикаю пісню, вмикаю камеру та практикую… от тільки недовго.

Отже, промучився трохи, та почав спостерігати. Заміряв, що застосунок виживає у фоні рівно одну хвилину. Це завело мене на стежку хибних гіпотез, які починалися із “є певний період, який iOS дозволяє тримати застосунок у фоні”.

Вирішив, що то мій застосунок недостатньо зрозуміло пояснює iOS, що він є програвачем музики та потребує тривалого існування у фоні. Нацькував на цю тему Cursor, він вже і так, і сяк пробує — а результат однаковий — 60 секунд і кінець.

(До речі: що LLM вміє робити дійсно потужно — так це читати та навіть змінювати код залежностей. Я сам майже ніколи так не робив, бо було складно та ризиковано. А LLM ставить patch-package та успішно патчить навіть код на Swift.)

Прориву ми досягли, коли нарешті здогадалися додати вичерпне журналювання. Причому відразу! З першої же ж спроби.

(Тут теж LLM здатна прорватися туди, де я не знаюся: пояснила, де читати журнали застосунку з iPhone та власне потім сама ці журнали й проаналізувала.)

І що знайшли? Та досить очевидну в ретроспективі річ. Застосунок споживав надто багато CPU. Виявляється, в iOS є правило: якщо застосунок у фоні споживає понад 80% CPU, його зупиняють.

(А 60 секунд - це вікно оцінювання.)

Мій застосунок безтурботно ганяв анімацію React Native Animation - яка й керувала відтворенням аудіо. Зокрема, в режимі зациклювання я додав fade in/out - от він і був головною причиною.

Поки що вистачило зупиняти анімацію та трохи збільшити інтервал зміни гучності. Але також дізнався, що є готові API для автоматичного fade in/out - це було б ідеально.

Загалом бачу що в майбутньому треба весь рушій аудіо переписати на нативний, щоб React Native туди не лазив аж зовсім. Втім, для MVP піде й так.

Яка тут мораль: та класична. Спочатку зрозумій, у чому проблема, та доведи це, а потім вже починай виправляти. Це залишається правдою з LLM чи без.

В моїй програмі для музичності](https://cadencia.dance) багато завʼязано на темп пісні, тобто на її BPM. Практика показує, що автоматичні засоби визначення BPM помиляються. Окрім того, мені також треба знати, де “раз”, тобто де починається вісімка (бо, взагалі-то, як мінімум бачата та сальса для танцівників складаються з вісімок.)

Отже, розповідь про дві ітерації інтерфейсу для цього… з їхніми недоліками.

На початку я зробив варіант “тепай на 1”. Тобто ти задаєш послідовність “разів”, та з неї програма обчислює частоту тактів. Помилився — починай наново.

(Що робити в разі помилки — це одне з головних питань. Причому як до дизайнера, так і до користувача.)

Проблемою цього варіанту було те, що точок даних було замало. А значить, дрібні помилки в тепах сильно впливали на результат. Тож тепати доводилося довго… що дедалі збільшувало шанс помилки, бо не завжди легко той “раз” почути — дійдеш до якогось брейкдауну і сиди вгадуй.

Тоді я спробував зробити більше точок: тепати на кожний рахунок, а не тільки на “раз”. Будь-який танцівник вже вміє крокувати на кожний рахунок, тож, в теорії, тепати теж вийде?

Як би не було, а “тепати в рахунок” на досвіді виявилося незручніше. Впевненість субʼєктивно просіла помітно. Шанс на помилки теж зріс: бо тепер тепати треба не раз на 4 секунди (приблизно), а 2 рази на секунду.

Здається, тепер я зрозумів, у чому річ: чіткий рахунок не так вже й легко почути. Коли танцюєш, мати варіативність кроку не тільки дозволено, але й може бути музично та гарно. Підтримувати стабільний ритм — задача більше для барабанника, ніж танцівника.

Отже… що робити? Як отримати BPM від користувача — в ідеалі так, щоб навіть не називати слово BPM?

Успішною стала третя ітерація, але про неї завтра.

Отже… як же ж його допомогти користувачу визначити темп пісні?

Я залишив модель “теп на раз”, але з ключовою різницею.

Перша ітерація бачила послідовність тепів як сигнал, який ми перетворюємо на BPM. Більше тепів — краще сигнал… це якщо тепи чіткі. Але більше тепів — більше шансів на помилку. Особливо тому, що пісня — це не бій метронома, та не кожний “раз” ти почуєш однаково.

Оскільки характер пісні змінюється, фактично в нас є шанс задати чітку послідовність, тільки поки грає куплет чи приспів, чи інша рівномірна частина. Розумієш — в моделі “послідовність тепів” є практична стеля якості.

Тому я знайшов іншу модель. Пісня містить послідовність “разів”, та наша задача — її викрити. Тепати можна в будь-який “раз” - не обовʼязково в кожний. Всі “рази”, який відмітить користувач, додають інформації: між двома “разами” завжди є кратний проміжок.

Тоді користувач вільний обрати ті “рази”, де їх добре чути. І від того сигнал стає чистішим!

Ба більше, виходить, що формула впевненості значно виграє, якщо в нас є тепи з початку та з кінця пісні. Бо та ж похибка на великому проміжку значить менше! А оце вже зовсім інший досвід!

Бо раніше було навпаки: навіть маленька похибка в тепах могла протягом цілої пісні повністю зсунути ритм. Тоді доводилося старатися та бути чіткіше. І це я розумів, а як пояснити простому користувачеві?

Можливо, я ще перероблю цей UI, щоб більше спрямовувати користувача до правильних дій — як-от визначення “раз” на початку та кінці пісні. Але в цілому — вже задоволений.