Напомнило. Когда я защищал бакалавриат со мной сдавал ещё однокурсник. Его коллегия попросила пообещать, что он никогда не будет работать программистом где-то, от чего будет зависеть жизнь человека. И тогда они тройку всё же поставят.
Мне кажется, в байнде всё-таки не стоит вызывать DynamicColors.wrapContextIfAvailable(), потому что она тяжёлая, и будет вызываться каждый раз, когда система байндит этот элемент списка.
Может, лучше, сгенерить цвета заранее? Или через lazy {} сохранить цвет. Да хотя бы кэш сделать.
Выглядит как ошибка типичного невнимательного джуна
Именно такое впечатление произвёл Cursor.
Написал на нем простенький кликер за один вечер, были проблемы в том, что он не меняет цвет текста по аромату "поменяй цвет текста на другой", создавал общие стейты вместо отдельных для каждой кнопки. До сих пор там остался баг, что чтобы разблокировать следующую кнопку, нужно разблокировать кнопку идущую за ней. Не смотрел в код, но головой навскидку сложно понять, как это вообще связано. Наверное, где-то что-то неправильно добавляется в какой-то лист.
Да, кстати, это был котлин мультиплатформ. Так что кликер запускается как на Андроиде так и на iOS.
Пришёл к выводу, что ИИ как джун. Результат есть, но каким путём он к нему пришёл - это вопрос. Нужно контролировать, нужно перепроверять, нужно самому держать контекст проекта в голове, потому что иначе будет проект, но абы какой и при любых изменениях шанс того, что что-то/всё сломается только растёт (как и в целом с программистами, у которых мало опыта).
Это нормально.
Для себя я сделал вывод, что если каждые изменения (или группу изменений) коммитить и потом следить за тем, что курсор поменял на этот раз - следить за контекстом, изменениями и результатом будет намного проще.
Ну и да, скорость разработки точно быстрее. Как минимум, на определенных этапах.
Да и присоединяясь к другим комментариям, некоторые ошибки должны выстрелить, чтобы разработчик понял, что так делать не надо. Что-то может найтись на QA, что-то при бегом ручном тестировании другого разраба. Я не говорю, конечно, о том, чтобы ломать прод. Но иногда новый тикет для разраба для фикса его бага действует очень весомо.
У нас ещё тот, кто делает ревью, тоже отвечает за эти изменения, и спрос будет с обоих.
К тому же, большие фичи смотрят сениоры, мелкие - можно делегировать миддлам. Плюс иногда подключать мида/джуна, чтобы посмотрел на то, как написан код, что исправлено итд, тоже, чтобы чему-то новому научиться.
Получается, если мы в мысленном эксперименте возьмём фрактал с размерность 2 - например кривую Пеано, кривую Гильберта или другие - у нас будет одномерное время, вложенное в двумерное временное пространство. И, выходит, что перескакивание между соседними отрезками (как в примере перенесения муравья с края газеты на другой край газеты, если их соединить через тебе изменение) - это как раз движение во втором временном пространстве, которое ортогонально нашему обыкновенному текущему?
Если упростить - в версии о том, что время идёт по спирали (и является одномерным), перескакивание между витками и есть движение в том же втором временном пространстве.
А третье я бы уже отнёс к мультивселенной и вариативности.
Есть отличное старое видео, объясняющее предназначение 10 пространств в нашей вселенной, там говорится что-то подобное: https://youtu.be/HnFiAcMN4AM?si=l1YphawFBuyv4lS-
Спасибо большое!
Я этим занимаюсь параллельно с написанием своей музыки. Посмотрим, если хватит усидчивости довести проект до какого-то неплохого релиза. Увидим.
40%, потому что навскидку «чистые» тональности немного чаще используются.
Если выбирать из 12 полутонов — то потом всё равно нужно будет переводить их в буквенное обозначение, потому что в аудио сэмплах в названии файла именно буквы.
Плюс, могут потеряться «странные» тональности типа E# и B# (но это уже притягивание за уши).
Плюс нужно учитывать миноры-мажоры — и для правильного рандома нужно выбирать из 24х вариантов.
Для PoC я решил, что будет достаточно просто rand(A..G).map(/*add #*/).map(/*add m*/).
В первом шаге — никак не будет отличаться. Разница между числами вносят слишком сильный хаос в float значения.
С другой стороны, третий шаг (через шейдеры) как раз старается как можно меньше менять «высотное» отношение между количеством приходящих частиц каждую минуту.
И, как мне кажется, это уже не случайные числа, и какие-то погодные или сезонные изменения тоже есть.
Не буду отстаивать, что мои данные — не случайны. Это, всё же, значения за каждую минуту.
Хотя, в них прослеживается своего рода стабильность (особенно в высоких нотах).
Как-то давно наткнулся на интересное обсуждение этого вопроса на dirty.ru. Конкретно этот комментарий:
Выход из затруднения сего довольно трудный, ибо самоосознание и самоощущения в принципе единственное что мы по настоящему может называть своей реальностью которая дана нам, вообще. Притекающие извне ощущения, воспоминания и даже мысли происходят в его фоне. Но если всё дело просто в сложном автомате, то где самоосознание у дверного звонка, который «рецептором» кнопки порождает реакцию биения мембраны? Тут мы стоим перед двумя выборами — признать самоосознание иллюзией, как, например, считают буддисты, но это мне лично кажется глубоко неудовлетворительным, ибо повторяюсь, ничего более реального у нас в принципе нет. Либо считать это неотъемлемым свойством вообще материи как таковой, типа если взять треугольник, то кроме треугольника в конфигурации материи возникает что то еще, что то присущее треугольнику и существующее по меньшей мере в своей какой то реальности, физической или нет, но не менее реальной, чем материя из которой треугольник сложен. Возможно… даже более реальной.
На самом деле, он немного выхвачен из контекста (да и это не весь комментарий). Прочитав всю ветку (и, возможно, прилегающие) мысль автора будет яснее.
Напомнило. Когда я защищал бакалавриат со мной сдавал ещё однокурсник. Его коллегия попросила пообещать, что он никогда не будет работать программистом где-то, от чего будет зависеть жизнь человека. И тогда они тройку всё же поставят.
Я пользуюсь уже давно, с i3, и теперь на маке с Yabai.
Удобно, когда у меня ИДЕ на весь экран, рядом, на втором мониторе браузер с тикетами/документацией.
На первом мониторе два рабочих стола под ИДЕ, один под рабочий чат, один под саблайм, чтобы быстро логи открыть и проверить.
На втором переключаюсь между рабочим браузером и личным.
Всё на весь экран, всё тайлово, без окон, которые скрывают друг друга.
Плюс, при переключении рабочего стола на одном из мониторов, на втором ничего не меняется.
Мне кажется, в байнде всё-таки не стоит вызывать DynamicColors.wrapContextIfAvailable(), потому что она тяжёлая, и будет вызываться каждый раз, когда система байндит этот элемент списка.
Может, лучше, сгенерить цвета заранее? Или через lazy {} сохранить цвет. Да хотя бы кэш сделать.
Но идея хорошая!
Именно такое впечатление произвёл Cursor.
Написал на нем простенький кликер за один вечер, были проблемы в том, что он не меняет цвет текста по аромату "поменяй цвет текста на другой", создавал общие стейты вместо отдельных для каждой кнопки. До сих пор там остался баг, что чтобы разблокировать следующую кнопку, нужно разблокировать кнопку идущую за ней. Не смотрел в код, но головой навскидку сложно понять, как это вообще связано. Наверное, где-то что-то неправильно добавляется в какой-то лист.
Да, кстати, это был котлин мультиплатформ. Так что кликер запускается как на Андроиде так и на iOS.
Пришёл к выводу, что ИИ как джун. Результат есть, но каким путём он к нему пришёл - это вопрос. Нужно контролировать, нужно перепроверять, нужно самому держать контекст проекта в голове, потому что иначе будет проект, но абы какой и при любых изменениях шанс того, что что-то/всё сломается только растёт (как и в целом с программистами, у которых мало опыта).
Это нормально.
Для себя я сделал вывод, что если каждые изменения (или группу изменений) коммитить и потом следить за тем, что курсор поменял на этот раз - следить за контекстом, изменениями и результатом будет намного проще.
Ну и да, скорость разработки точно быстрее. Как минимум, на определенных этапах.
Да и присоединяясь к другим комментариям, некоторые ошибки должны выстрелить, чтобы разработчик понял, что так делать не надо. Что-то может найтись на QA, что-то при бегом ручном тестировании другого разраба. Я не говорю, конечно, о том, чтобы ломать прод. Но иногда новый тикет для разраба для фикса его бага действует очень весомо.
У нас ещё тот, кто делает ревью, тоже отвечает за эти изменения, и спрос будет с обоих.
К тому же, большие фичи смотрят сениоры, мелкие - можно делегировать миддлам. Плюс иногда подключать мида/джуна, чтобы посмотрел на то, как написан код, что исправлено итд, тоже, чтобы чему-то новому научиться.
Получается, если мы в мысленном эксперименте возьмём фрактал с размерность 2 - например кривую Пеано, кривую Гильберта или другие - у нас будет одномерное время, вложенное в двумерное временное пространство. И, выходит, что перескакивание между соседними отрезками (как в примере перенесения муравья с края газеты на другой край газеты, если их соединить через тебе изменение) - это как раз движение во втором временном пространстве, которое ортогонально нашему обыкновенному текущему?
Если упростить - в версии о том, что время идёт по спирали (и является одномерным), перескакивание между витками и есть движение в том же втором временном пространстве.
А третье я бы уже отнёс к мультивселенной и вариативности.
Есть отличное старое видео, объясняющее предназначение 10 пространств в нашей вселенной, там говорится что-то подобное: https://youtu.be/HnFiAcMN4AM?si=l1YphawFBuyv4lS-
Однозначно. С помощью JSyn достаточно только иметь список "дозволенных" частот — а это рассчитать несложно
Я этим занимаюсь параллельно с написанием своей музыки. Посмотрим, если хватит усидчивости довести проект до какого-то неплохого релиза. Увидим.
Если выбирать из 12 полутонов — то потом всё равно нужно будет переводить их в буквенное обозначение, потому что в аудио сэмплах в названии файла именно буквы.
Плюс, могут потеряться «странные» тональности типа E# и B# (но это уже притягивание за уши).
Плюс нужно учитывать миноры-мажоры — и для правильного рандома нужно выбирать из 24х вариантов.
Для PoC я решил, что будет достаточно просто rand(A..G).map(/*add #*/).map(/*add m*/).
MIDI — это отдельная большая тема. Я бы в ней покопался с обычной музыкой сначала, без процедурки, шейдеров и космоса :)
Тем более, вышел/выходит MIDI 2.0, и, например, его интересно было бы имплементировать на Ардуино как кастомный MIDI контроллер.
Дык, да, не спорю. В этом плане космос не сильно отличается от статистики на селе.
Если брать более конкретные и интересные данные — получится лучше. И из уже достаточно будет добавить в нужные массивы и все будет играть
Но я гляну, что это за VCV зверь такой и что с его помощью можно делать. Спасибо!
С другой стороны, третий шаг (через шейдеры) как раз старается как можно меньше менять «высотное» отношение между количеством приходящих частиц каждую минуту.
И, как мне кажется, это уже не случайные числа, и какие-то погодные или сезонные изменения тоже есть.
Не буду отстаивать, что мои данные — не случайны. Это, всё же, значения за каждую минуту.
Хотя, в них прослеживается своего рода стабильность (особенно в высоких нотах).
Заходят как-то в рудимент три кобчика и воробей...
А про дельфинов вы точно уверены?
На самом деле, он немного выхвачен из контекста (да и это не весь комментарий). Прочитав всю ветку (и, возможно, прилегающие) мысль автора будет яснее.
И прошу прощения за некромантию.