Безумие. Фото и образец голоса станут ключами от королевства?
Ну фото — это вообще без комментариев — надо значит срочно удалять себя из всех соц. сетей и вообще.
Голос. А как будет происходить сопоставление с эталоном? Четкого совпадения-то никогда не будет. Кроме того — частота дискретизации, качество микрофона и еще миллион параметров. Т.е. даже качественное аудио — это информация с очень низким «разрешением». Значит можно будет забрутфорсить систему.
Ну и к этому можно добавить существенные успехи в технологиях генерации изображений и аудио с использованием нейросетей.
Т.е. больше варантов идентификации по ИЛИ = больше вариантов кражи денег. Вот если бы по И — тогда да, тогда я бы еще согласился. Введи пароль, пришли фото, скажи фразу в микрофон — тогда может и пустим. Но по ИЛИ — безумие. А на сколько я понял — предлагается внедрить именно этот вариант.
QML. QQuickPaintedItem. На подложке QPainter'ом рисуются шкалы, а сверху для вывода серий накладываются QImage с кешем отрисованных серий. Сами серии рисуются параллельно в фоновых потоках, перерисовка инициируется при изменении положения вьюпорта. В итоге получается эффект, что при увеличении масштаба на графике на какое-то время появляется «мыло», которое заменяется более четким изображением по мере перерисовки серий. Типа как при увеличении масштаба в картографических приложениях.
Самое главное, что в график «засовываются» источники «сырых» потоков семплов с простым интерфейсом а ля QFuture read(DateTime start, DateTime end, const std::function<void(Sample*, size_t)>&), а весь хардкор с кешированием, ресемплингом, распараллеливанием и т.д. уже реализован в графике. А самих источников обычно много разных видов. Архив такой, архив сякой, адаптер для внешних систем и т.д.
Знаю, что QQuickPaintedItem — это очень плохо, но рисовать шкалы на SceneGraph API это то еще удовольствие. Так же был тестовый вариант в котором данные серий считались как буфера точек, а выводились через QSGGeometryNode + GL_LINE_STRIP, но от этого варианта пришлось отказаться, т.к. требовался еще отключаемый вывод точек, меток, поддержка стилей пера (точка, тире). На Scene Graph это всё можно, но уж больно много геморроя. А профита не так уж и много, т.к. все равно требуется время CPU на подготовку буферов геометрии, upload на GPU и т.д. Может когда нибудь дойдут руки перевести на него, но на удивление даже при использовании софтверной отрисовки производительность очень хороша, благодаря мат. обработке и параллелизму, а учитывая тенденцию по наращиванию количества ядер CPU…
QtCharts не поддерживает виртуализацию данных. В сериях просто хранятся вектора семплов. И от этого на практике толку от него мало. Потому что обычно в источнике мноооооого семплов и что бы график работал быстро, надо узнать видимые диапазоны времени / значений по шкалам, выбрать соответствующие семплы и произвести их мат. обработку на стороне источника — понизить sample rate, схлопнуть накладывающиеся участки, добавить сглаживающий пост-фильтр и т.д. Еще хорошо бы иметь кешированные потоки семплов под разный LOD (Level Of Detail) с предфильтрацией. А уже потом можно быстренько нарисовать. В общем система получается навороченной. И в архитектуру без поддержки виртуализации вписывается очень плохо. Можно закостылить перехватом изменений положения вьюпорта и запускать асинхронную подготовку данных серий, где-то рисовать что, мол, грузим, подождите и т.д. Все равно придется постоянно спамить передачей векторов семплов в график. В общем решение несерьезное. У нас (команды) тоже были размышления на тему использования QChart в нашем продукте, но по вышеназванным причинам решили делать свой контрол. О чем не жалеем.
Т.е. это для того, что бы отсортировать коллекцию «на лету»? Вы добавили штуку под названием карта индексов (index map). Это по сути «ленивая» сортировка коллекции. Вы платите вектор индексов и косвенную адресацию, за то, что не вызывали std::sort. Ну в принципе да, если элементы натикивают в список один за другим неторопясь, то решение полезное. А если приходит пачка данных, а потом с ней идет работа, я бы перешел на std::vector/std::array + std::sort. Сортировать конечно же 1 раз после получения пачки данных.
Я юзаю такую структурку при наложении фильтров на список элементов (сообщений в списке сообщений и т.д.). Чем перечитывать блок данных с фильтром, куда проще пройтись по уже прочитанному и сформировать вектор индексов элементов, прошедших фильтр. И работает очень быстро. А еще можно распараллелить.
В общем у вас получился уже не двусвязный список. Это вектор с индексной картой. При этом:
— Можно использовать индексную адресацию. Совершенно нет причин делать интерфейс только последовательного доступа. Вектор-то уже всё равно есть.
— Зачем использовать 2 индексных карты (2я для prev_)? 1 вполне достаточно.
— А как же resize? На практике ситуация с известным максимальным размером списка крайне редка.
— В чем профит объединения 2х векторов индексов в 1 (indirection)?
— next_ и prev_ никогда не переприсваиваются. Зачем хранить их как поля? В виде inline функций будет не медленнее.
Я бы это назвал lazy_vector, или как-то так. Можно было бы добавить метод arrange, который бы раскидывал элементы в правильном порядке и вырубал бы косвенную адресацию.
Не пойму. Это статья троллинг? Как предусмотрительно вы не стали писать remove.
У вас получился вектор, ухудшенный в 3 раза. Основное назначение списка — быстрая вставка в середину ценой памяти и скорости итерации. А реверс, как написали выше, решается элементарно std::reverse_iterator.
P.S. Не знаю как у других, но на моей практике в 99.9% всех случаев, когда нужен линейный контейнер, лучше всего подходит вектор, т.к. львиная доля операций с ним — операции чтения данных. Бывает, конечно, что приходится и удалять из середины, но я обычно борюсь
с этим поддержкой «дырок», параллельным вектором индексов и т.д. уловками, когда это возможно.
Flash, серверлат (Silverlight), XBAP (Wpf Browser Application). Все это уже было. Идея ооооочень не нова, а точнее очень стара. В современном мире гораздо актуальнее становятся технологии тонких клиентов (а ля WebGL), о чем тут уже все, кому было не лень, поведали. Называть «браузером» простой лоадер QML я бы лично не отважился.
Ну надо же! Спасибо за такие развернутые ответы! Узнал много нового и интересного! Да, я замечал что довольно часто в музыке в старых играх мелодии были с закосом под рок/металл. Мне больше всего запомнилось вступление из Robocop 3 :) Позже я даже удивился, когда узнал, что оно совсем не японское.
Большое спасибо! Да, подозревал что это арпеджио, но не думал, что настолько быстрое :) Да, эффект получается очень интересный. На таких скоростях, думаю, в дело вступает уже латентность слуха. Получается что хотя в один момент времени звучит одна нота, из-за задержки восприятия слышно несколько. Типа как с электронным лучом на ЭЛТ. Но при этом слышно, что «что-то меняется». Это, я так понимаю, пошло от того, что хотелось сделать пэды с одновременно звучащими несколькими нотами, но аппаратура не позволяла?
Вопрос конечно не совсем в тему, но близко. Меня уже давно интересует, из чего «состоит» специфический чиптюновый звук. С него начинается композиция в указанном видео. Или этот звук слышно тут в первой паре секунд и далее местами: lukhash.bandcamp.com/track/eighties-remaster Мне интересно что это в музыкальном плане. Ясно, что это какая-то последовательность очень быстро меняющихся нот, но у меня не хватает слуха и что бы распарсить слышимое. Я имею в виду, как бы это выглядело, если бы было нарисовано в piano roll'е из элементарных составляющих. Может где-то можно почитать про всякие фишки звукогенерации той эпохи в доступном виде.
Нда, бывает (это я про себя) :) КДПВ — Картинка Для Привлечения Внимания. На работе я вижу, что ряды черепов скошены налево. А дома — что направо. Похоже, ключевую роль играет угол, под которым смотришь на монитор.
Нда, теперь еще надо дождаться, когда кто-нибудь додумается загружать автосгенерированный мусор в Steam. Может тогда Valve начнет хоть немного шевелиться. Хотя, надо сказать, даже в таком случае лента игр не сильно изменится.
Да, я тоже в первый раз, когда попробовал написать что-то на QML малость прифигел.
До сих пор интересует вопрос, какому гению пришла в голову идея в качестве базы для QML выбрать JS? И это во фреймворке на C++, где типизацией пронизано буквально всё, а в QML её особо нет, даже если захочется. Порог вхождения во фреймворк по этому получился просто астрономическим. Нужно не только уметь мыслить «по ООП-шному», но еще и по JS-ному. При чем и то и другое нужно уметь делать одинаково хорошо…
Раз уж тут про Сбер, добавлю еще 5 копеек.
Очень сильно раздражает, что в СМС об операциях по карте мне присылают баланс…
А до конца отключить СМС пока нельзя, т.к. тот же Сбер Онлайн не выдает push уведомления, например, о снятии денег через банкомат. Да, да, можно/нужно ставить блок на телефон и т.д. Но все равно, не известно кто и когда внезапно может увидеть что у меня на экране. В том же метро.
Да, золотые были времена. Один неловкий щелчок по ссылке в IE6, и у тебя сразу открывается 100500 закладок с «порнухой» (на самом деле с дорвеями и ссылками и малвар), миллион алертов с предложениями увеличить член, ускорить работу компьютера и «удалить вирусы». В фоне заботливо скачивается и запускается дроппер адвара, малвара, троянов и браузер хайджекеров, и прописывает все это дело в автозагрузку :) Если особо повезет, можно было словить что-нибудь экзотическое, сразу стирающее таблицу разделов с диска, без лишних вопросов.
Ну фото — это вообще без комментариев — надо значит срочно удалять себя из всех соц. сетей и вообще.
Голос. А как будет происходить сопоставление с эталоном? Четкого совпадения-то никогда не будет. Кроме того — частота дискретизации, качество микрофона и еще миллион параметров. Т.е. даже качественное аудио — это информация с очень низким «разрешением». Значит можно будет забрутфорсить систему.
Ну и к этому можно добавить существенные успехи в технологиях генерации изображений и аудио с использованием нейросетей.
Т.е. больше варантов идентификации по ИЛИ = больше вариантов кражи денег. Вот если бы по И — тогда да, тогда я бы еще согласился. Введи пароль, пришли фото, скажи фразу в микрофон — тогда может и пустим. Но по ИЛИ — безумие. А на сколько я понял — предлагается внедрить именно этот вариант.
Самое главное, что в график «засовываются» источники «сырых» потоков семплов с простым интерфейсом а ля QFuture read(DateTime start, DateTime end, const std::function<void(Sample*, size_t)>&), а весь хардкор с кешированием, ресемплингом, распараллеливанием и т.д. уже реализован в графике. А самих источников обычно много разных видов. Архив такой, архив сякой, адаптер для внешних систем и т.д.
Знаю, что QQuickPaintedItem — это очень плохо, но рисовать шкалы на SceneGraph API это то еще удовольствие. Так же был тестовый вариант в котором данные серий считались как буфера точек, а выводились через QSGGeometryNode + GL_LINE_STRIP, но от этого варианта пришлось отказаться, т.к. требовался еще отключаемый вывод точек, меток, поддержка стилей пера (точка, тире). На Scene Graph это всё можно, но уж больно много геморроя. А профита не так уж и много, т.к. все равно требуется время CPU на подготовку буферов геометрии, upload на GPU и т.д. Может когда нибудь дойдут руки перевести на него, но на удивление даже при использовании софтверной отрисовки производительность очень хороша, благодаря мат. обработке и параллелизму, а учитывая тенденцию по наращиванию количества ядер CPU…
Я юзаю такую структурку при наложении фильтров на список элементов (сообщений в списке сообщений и т.д.). Чем перечитывать блок данных с фильтром, куда проще пройтись по уже прочитанному и сформировать вектор индексов элементов, прошедших фильтр. И работает очень быстро. А еще можно распараллелить.
В общем у вас получился уже не двусвязный список. Это вектор с индексной картой. При этом:
— Можно использовать индексную адресацию. Совершенно нет причин делать интерфейс только последовательного доступа. Вектор-то уже всё равно есть.
— Зачем использовать 2 индексных карты (2я для prev_)? 1 вполне достаточно.
— А как же resize? На практике ситуация с известным максимальным размером списка крайне редка.
— В чем профит объединения 2х векторов индексов в 1 (indirection)?
— next_ и prev_ никогда не переприсваиваются. Зачем хранить их как поля? В виде inline функций будет не медленнее.
Я бы это назвал lazy_vector, или как-то так. Можно было бы добавить метод arrange, который бы раскидывал элементы в правильном порядке и вырубал бы косвенную адресацию.
У вас получился вектор, ухудшенный в 3 раза. Основное назначение списка — быстрая вставка в середину ценой памяти и скорости итерации. А реверс, как написали выше, решается элементарно std::reverse_iterator.
P.S. Не знаю как у других, но на моей практике в 99.9% всех случаев, когда нужен линейный контейнер, лучше всего подходит вектор, т.к. львиная доля операций с ним — операции чтения данных. Бывает, конечно, что приходится и удалять из середины, но я обычно борюсь
с этим поддержкой «дырок», параллельным вектором индексов и т.д. уловками, когда это возможно.
Так и задумано?
До сих пор интересует вопрос, какому гению пришла в голову идея в качестве базы для QML выбрать JS? И это во фреймворке на C++, где типизацией пронизано буквально всё, а в QML её особо нет, даже если захочется. Порог вхождения во фреймворк по этому получился просто астрономическим. Нужно не только уметь мыслить «по ООП-шному», но еще и по JS-ному. При чем и то и другое нужно уметь делать одинаково хорошо…
Очень сильно раздражает, что в СМС об операциях по карте мне присылают баланс…
А до конца отключить СМС пока нельзя, т.к. тот же Сбер Онлайн не выдает push уведомления, например, о снятии денег через банкомат. Да, да, можно/нужно ставить блок на телефон и т.д. Но все равно, не известно кто и когда внезапно может увидеть что у меня на экране. В том же метро.