Официальный анонс это одно, а совсем другое — что после длительного прослушивания исключительно одного исполнителя (суммарно на 6-10 часов за несколько суток) он начинает преобладать над остальными.
Я столкнулся как раз с проблемой, что люди очень часто добавляют в «мои аудио» не совсем релевантную музыку — например, только смешные треки.
Именно поэтому и начал опираться на рекомендации.
Они не то чтобы сломаны, но да, смысл в ваших словах есть. На неделе поставлю ограничение на максимальное отклонение рекомендаций.
То, что я изучал про них — они запоминают треки, которые играли в ВК, и строятся на основе именно этого в первую очередь.
у API Вконтакте ограничение на количество запросов на пользователя, не на приложение :) Так что с этим не будет проблем.
У меня же вообще нет бэкэнда, только клиентсайд. Хабраэффект вызвал — о боже — нагрузку на сервер в 0.2 Мб/c в пике.
Насчет рекомендаций — все куда сложнее чем вы можете себе представить, сейчас настроена базовая логика. Судя по тому, как аудитория приняла проект — через 2-3 недели подключится более сложный алгоритм, который пока что отключен
это займет дофига времени: last.fm работает только поверх бэкэнда, а значит, нужно делать этот самый бэкэнд, начать запоминать пользователей, к тому же под авторизацию в last.fm придется уже делать полноценное меню. Сейчас на самом деле достигнут порог разработки, нужно довольно капитально рефакторить под дальнейшее развитие, если честно. Так что меню затянется.
автостарт есть — если зайдете по этой ссылке, например publicradio.io/?rock_music_on (взял то что сейчас играет просто, не долго думая), секунд через 5-7 оно начнет играть. Автостарта рандома не будет по понятным причинам, про сохранение последней игравшей станции — надо подумать, проще ссылку сохранить все-таки ведь.
По подсказкам — да, просто не успел допилить, постараюсь на неделе успеть. Это все-таки проект, который я в одиночку делаю по вечерам, 20 часов в неделю — это очень мало для качественного продукта, пришлось урезать функционал в угоду качеству.
Переключаться не будет, воспринимайте это как реальные радиостанции. У вас же радио с одной на другую не скачет?
По жанрам и так далее — если проект пойдет хорошо (10к пользователей хотя бы) и появится еще один человек, желающий и способный помочь, будет большое количество изменений в сторону персонализации опыта, в том числе «послушать определенный жанр», «послушать станции, похожие на...», «послушать все что похоже на такого-то исполнителя». Просто много времени надо на это. Сами понимаете.
Потерпите немного до поста про механизмы ранжирования :) Там и обсудим все эти вопросы, будет очень много интересных моментов прояснено в механике. Думаю, он вторым будет, в четверг или пятницу.
libastral опять сломалась :)
Да, тут дело в том, что в вконтакте очень часто у аудио стоит жанр 18 — other. И большинство композиций подпадают под него. В итоге — из ваших 20 композиций, вполне вероятно, с проставленным жанром всего 2-3.
К тому же жанр не всегда точно выставляется, понятное дело.
Вообще именно для построения рекомендательной системы для аудио у ВК очень мало возможностей, хотя с другой стороны — не будь хотя бы таких жанров, так хоть вешайся. Я пытался подключать musicbrainz, там стоит ограничение около 1 запроса в секунду, в итоге — это вообще превращалось в пошаговую стратегию. А так — при наличии стартовых данных более-менее приличных можно довольно неплохо рекомендовать.
Да, скорее всего. Я хотел про это одну из следующих статей, но если вкратце — у ВК есть 21 жанр музыки (из тех что можно использовать). Берутся последние 100 треков и 100 треков из рекомендованных аудиозаписей, из них извлекаются жанры, составляется массив с процентными соотношениями жанров. Что-то вроде [.25;.5;0;0;0;0;.33;.17]. Для группы берутся треки, которые будут играться (сейчас выходит до 400 треков на станцию, у тех, что сейчас показываются мне, в среднем 170 треков, минимум 20, максимум 340), для них считается такой же массив. Массивы сравниваются на похожесть.
Добавьте треков 30 еще хотя бы, и ранжирование должно начать работать довольно точно, я думаю.
Музыкальные паблики, в которых вы участвуете, пока что не участвуют в механизме ранжирования, но вообще этот функционал есть, временно выпилен — на данный момент избыточен, пересчет весов, от которого необоснованно скачут плитки, не очень хорошо смотрится. Собственно, об этом я и написал в UPD — если будет заранее подготовленная база весов, плитки не будут скакать первые 2-3 минуты после запуска Public Radio, и это будет достаточно хорошо смотреться, можно будет натравливать нейросеть на обучение по пабликам пользователя.
да я не спорю, сам задумался что так стоит делать :) но именно по простоте «снести папку» куда проще чем «снеси такие-такие-такие и такие файлы».
А, вот, сообразил, в чем есть ньюанс.
У меня периодически бывают подобные ситуации
src/tooltipster.css
src/style.sass
компилируются в
build/tooltipster.css
build/style.css
Все куда сложнее, но если вкратце — ситуация именно такая: есть неопределенный список расширений файлов на выходе, и если я собираю проект — я сношу их, в противном случае я хочу просто перезаписать. Объяснения дальше запутанные и сложные, но если вкратце — разносить по папкам типа assets/ не выйдет, постфиксы (типа style.sass.css) тоже не очень нравится как идея.
В понедельник постараюсь начать цикл статей про свое полноценное музыкальное backendless приложение, работающее поверх трех (если бы last.fm не были м***ми и сделали бы поддержку CORS — было бы четырех, видимо, для них придется городить-таки бэкэнд) различных апей.
Трафик жрет — мама не горюй, чисто запросов за данными (при повторной загрузке после уже заготовленного кэша indexedDB) — больше 20 Мб данных за первые пару минут. К сожалению, избыточность данных хрен понизишь.
А у вас фигня какая-то, а не backendless приложение. Абсолютно обычный web app поверх сделанного для себя самих же api, почти все приложения так работают, начиная от gmail и заканчивая кучей мелочевки на github.io. Просто с кроссдоменными запросами
Да, вот картинка того как я отлаживаю свою балалайку. Ну, то есть все эти запросы только от меня.
Я очень давно мучаюсь со следующей проблемой:
есть таск build, перед ним должен выполниться таск clean. А за ним все остальные сборщики запускаются. Это понятно, иначе он снесет папку с уже чем-то скомпиленным вполне вероятно.
А зачастую нужно собрать один конкретный файл.
Допустим логика такая:
build -> [build-scripts, build-styles, build-html]
build-scripts -> [clean], fn
build-styles -> [clean], fn
build-html -> [clean], fn
А как сделать так, чтобы иметь возможность запускать и билд, и отдельные сборщики (без снесения всей папки) — без малейшего понятия.
Вот это основная проблема галпа: он не предназначен для повторного использования тасков по большому счету.
Хотя лучше него ничего нет все равно.
Мне об этой проблеме уже неоднократно писали, но до сих пор даже не понял, что именно там происходит.
Я столкнулся как раз с проблемой, что люди очень часто добавляют в «мои аудио» не совсем релевантную музыку — например, только смешные треки.
Именно поэтому и начал опираться на рекомендации.
То, что я изучал про них — они запоминают треки, которые играли в ВК, и строятся на основе именно этого в первую очередь.
У меня же вообще нет бэкэнда, только клиентсайд. Хабраэффект вызвал — о боже — нагрузку на сервер в 0.2 Мб/c в пике.
Насчет рекомендаций — все куда сложнее чем вы можете себе представить, сейчас настроена базовая логика. Судя по тому, как аудитория приняла проект — через 2-3 недели подключится более сложный алгоритм, который пока что отключен
По подсказкам — да, просто не успел допилить, постараюсь на неделе успеть. Это все-таки проект, который я в одиночку делаю по вечерам, 20 часов в неделю — это очень мало для качественного продукта, пришлось урезать функционал в угоду качеству.
Переключаться не будет, воспринимайте это как реальные радиостанции. У вас же радио с одной на другую не скачет?
По жанрам и так далее — если проект пойдет хорошо (10к пользователей хотя бы) и появится еще один человек, желающий и способный помочь, будет большое количество изменений в сторону персонализации опыта, в том числе «послушать определенный жанр», «послушать станции, похожие на...», «послушать все что похоже на такого-то исполнителя». Просто много времени надо на это. Сами понимаете.
Да, тут дело в том, что в вконтакте очень часто у аудио стоит жанр 18 — other. И большинство композиций подпадают под него. В итоге — из ваших 20 композиций, вполне вероятно, с проставленным жанром всего 2-3.
К тому же жанр не всегда точно выставляется, понятное дело.
Вообще именно для построения рекомендательной системы для аудио у ВК очень мало возможностей, хотя с другой стороны — не будь хотя бы таких жанров, так хоть вешайся. Я пытался подключать musicbrainz, там стоит ограничение около 1 запроса в секунду, в итоге — это вообще превращалось в пошаговую стратегию. А так — при наличии стартовых данных более-менее приличных можно довольно неплохо рекомендовать.
Добавьте треков 30 еще хотя бы, и ранжирование должно начать работать довольно точно, я думаю.
Музыкальные паблики, в которых вы участвуете, пока что не участвуют в механизме ранжирования, но вообще этот функционал есть, временно выпилен — на данный момент избыточен, пересчет весов, от которого необоснованно скачут плитки, не очень хорошо смотрится. Собственно, об этом я и написал в UPD — если будет заранее подготовленная база весов, плитки не будут скакать первые 2-3 минуты после запуска Public Radio, и это будет достаточно хорошо смотреться, можно будет натравливать нейросеть на обучение по пабликам пользователя.
А, вот, сообразил, в чем есть ньюанс.
У меня периодически бывают подобные ситуации
src/tooltipster.css
src/style.sass
компилируются в
build/tooltipster.css
build/style.css
Все куда сложнее, но если вкратце — ситуация именно такая: есть неопределенный список расширений файлов на выходе, и если я собираю проект — я сношу их, в противном случае я хочу просто перезаписать. Объяснения дальше запутанные и сложные, но если вкратце — разносить по папкам типа assets/ не выйдет, постфиксы (типа style.sass.css) тоже не очень нравится как идея.
Трафик жрет — мама не горюй, чисто запросов за данными (при повторной загрузке после уже заготовленного кэша indexedDB) — больше 20 Мб данных за первые пару минут. К сожалению, избыточность данных хрен понизишь.
А у вас фигня какая-то, а не backendless приложение. Абсолютно обычный web app поверх сделанного для себя самих же api, почти все приложения так работают, начиная от gmail и заканчивая кучей мелочевки на github.io. Просто с кроссдоменными запросами
Да, вот картинка того как я отлаживаю свою балалайку. Ну, то есть все эти запросы только от меня.
есть таск build, перед ним должен выполниться таск clean. А за ним все остальные сборщики запускаются. Это понятно, иначе он снесет папку с уже чем-то скомпиленным вполне вероятно.
А зачастую нужно собрать один конкретный файл.
Допустим логика такая:
build -> [build-scripts, build-styles, build-html]
build-scripts -> [clean], fn
build-styles -> [clean], fn
build-html -> [clean], fn
А как сделать так, чтобы иметь возможность запускать и билд, и отдельные сборщики (без снесения всей папки) — без малейшего понятия.
Вот это основная проблема галпа: он не предназначен для повторного использования тасков по большому счету.
Хотя лучше него ничего нет все равно.