Я и написал, не было там особенного улучшения качества распознавания речи. Думал на базе этого делать большую систему для клиентов, но отказался в силу описанных причин.
У меня vosk работает на андроид. База голоса 50мбайт. Запускал полноценную на пк, не понравилось, распознавание речи так себе. Лучше Алису настроить на это дело.
У меня ноут закрыт постоянно. Все на внешний монитор и внешнюю клаву с мышкой. Монитор с ноутом подключен постоянно к zeegbee розетке. Алиса отключает ее и все переходит в сон.
Кейкапы стучат , особенно когда все спят. В ноутах ставят ножничные клавиатуры - продвинутые мембранные. Аналогичные есть и внешние А4 и logitech. Весь остальной китайский дешевый хлам - мимо.
Однозначно сегодня ноут наилучшее решение. Системники берут в основном игроманы, так как там необходимо ставить башни кулеров с водяным охлаждением для нормально так поиграть на максималках. Мне, как разработчику по, вполне хватает ноута с 12 ядрами на i5 и 32 гиг оперативки.
Ерунда написана. У меня на ноуте hdmi1.4. на внешнем мониторе 34" картинку выводит в режиме 2k 75гц и hdr режиме. Клавиатуру для работы нужно брать либо ножничную, либо механическую. Все эти дешевые мембранные быстро выходят из строя. Это касается и беспроводных мышек.
Представьте себе, на тв приставку можно подключать беспроводную мелкую клавиатуру и даже аэромышь, еще у нее есть HDMI выход и нормальный современный быстрый процессор. И зачем ковыряться в этом глючном старье ?
Если есть желание сделать себе некий спец. контроллер, то для этого существуют процессоры esp32 с дисплеем со своей ос за копейки. И , кстати, старые игры в режиме эмуляции на нем тоже работают. На этот процессор можно ставить разные эмуляторы, в том числе linux.
Esp серия обычно программируется через среду esp-idf в vscode. Еще можно использовать спец. графическую среду без "ручного" такого написания кода. Да использование устаревшего 8266 не самое удачное решение. Есть мини платы esp32c6 , например, с поддержкой зигби. Это более интересное решение.
Похожая система "строилась" одним пинком в конце 80 годов прошлого века на пк при помощи MSM, где каждый компьютер хранил свою часть базы со своей номенклатурой , а в сети это было представлено общей базой. Все это было еще до эпохи всеобщего интернет и работало в виде распределенной системы хранения данных в локальной сети конкретной крупной организации. Эта технология до сих пор поддерживается в иеархических СУБД типа cache от intersystems. Проблема тогда, как и сейчас, была в нормальных средствах разработки приложений для пользователя для таких СУБД.
Писал выше, не латать старую систему, а потратить время на ее замену новой, современной с минимальным количеством времени на ее разработку и внедрение используя готовые, современные решения. Есть опыт , когда наем и 30 разработчиков, не помогает в "латании" таких устаревших или "неправильно написанных изначально" системах.
Весь минус "самописанных" по своим "стандартам" систем заключается в том, что кроме самого "писателя" часто никто не может разобраться в написаном и надежность работы таких "самописанных" систем крайне низкая. Поэтому бизнес сейчас и покупает 1С, где нет проблем с сопровождением и поддержкой их работы.
Оду как раз и есть orm с надстройкой на postgresql. Работает с данными через свой кэш, т.е. все пользователи работают с кэшем данных. Никто не заставляет использовать оду как ерп систему. Главное там есть orm и готовая система безопасности доступа пользователей к данным и формам их представления, а также система распределения данных одной базы между разными организациями. За 20 лет там много чего сделано разработчиками и в двух словах всего не опишешь. Здесь минимальным количеством трудозатрат можно в короткий срок запустить проект на любой "вкус и цвет". А "костылить" свое - это как раз путь в никуда, так как предполагает большие трудозатраты с непредсказуемым финалом. Сейчас на рынке вполне много готовых различных продуктов с готовым решением, на которые потрачены годы на разработку и десятки миллионов долларов. Главное взять его на "вооружение" и быстро показать заказчику готовое решение.
А если , все же, есть желание выпустить свой "уникальный" продукт, то придется найти богатого спонсора для наема 1000 индусов и потратить ни один год на разработку для создания хотя бы примерно конкуретного на рынке продукта.
Почему нельзя было взять готовую orm систему с нормальной субд типа postgresql и не придумывать все это? MySQL явно не та база для большой бизнес системы. Есть, например, odoo с хорошим orm движком, который "отлаживают" уже лет 20 1000 индусов. Работает быстро, пишутся модели "одним кликом", поиски работают мгновенно. И ошибка автора была в том, что он пытался "ремонтировать" хлам старой системы, на которую были ранее потрачены большие ресурсы и деньги. Это "известная история" не только в данной компании. В данном случае нужно было , скорее всего, брать другую, современную orm систему и быстро запускать на ней новый проект.
Зачем все это вспоминать? Таким занимались в конце 80 и начале 90, когда не было современных средств разработки и других процессоров.Сам писал на ассемблере драйвера под разные устройства. Сейчас все это в прошлом и давно забыто.
Я и написал, не было там особенного улучшения качества распознавания речи. Думал на базе этого делать большую систему для клиентов, но отказался в силу описанных причин.
У меня vosk работает на андроид. База голоса 50мбайт. Запускал полноценную на пк, не понравилось, распознавание речи так себе. Лучше Алису настроить на это дело.
У меня ноут закрыт постоянно. Все на внешний монитор и внешнюю клаву с мышкой. Монитор с ноутом подключен постоянно к zeegbee розетке. Алиса отключает ее и все переходит в сон.
Кейкапы стучат , особенно когда все спят. В ноутах ставят ножничные клавиатуры - продвинутые мембранные. Аналогичные есть и внешние А4 и logitech. Весь остальной китайский дешевый хлам - мимо.
Ноутбук может быть постоянно закрыт при внешнем мониторе.
Однозначно сегодня ноут наилучшее решение. Системники берут в основном игроманы, так как там необходимо ставить башни кулеров с водяным охлаждением для нормально так поиграть на максималках. Мне, как разработчику по, вполне хватает ноута с 12 ядрами на i5 и 32 гиг оперативки.
Стоимость ноута сравнима с пк. Взял последний honor с 32гиг памяти и i5 на 12 ядрах, экран 2к 120гц. Для разработчика по лучше всякого пк.
Ерунда написана. У меня на ноуте hdmi1.4. на внешнем мониторе 34" картинку выводит в режиме 2k 75гц и hdr режиме. Клавиатуру для работы нужно брать либо ножничную, либо механическую. Все эти дешевые мембранные быстро выходят из строя. Это касается и беспроводных мышек.
Esp32 - это не Ардуино, поэтому в среде Ардуино Вы никогда не напишите 100% "нормально" работающий код для этого чипа.
Почему примеры не в esp-idf ? Очень странный подход в разработке кода для не Ардуино микропроцессора.
Представьте себе, на тв приставку можно подключать беспроводную мелкую клавиатуру и даже аэромышь, еще у нее есть HDMI выход и нормальный современный быстрый процессор. И зачем ковыряться в этом глючном старье ?
Если есть желание сделать себе некий спец. контроллер, то для этого существуют процессоры esp32 с дисплеем со своей ос за копейки. И , кстати, старые игры в режиме эмуляции на нем тоже работают. На этот процессор можно ставить разные эмуляторы, в том числе linux.
ZX Spectrum - Ok'
CP/M 2.2 - Ok'
IBM PC 8086 (80286) on ESP32 - Ok'
CP/M 86 - Ok'
FreeDOS - Ok'
MS-DOS - Ok'
Linux ELKS 8086 - Ok'
Купите обычную тв приставку на Аrm и поставьте на нее armbian и будет Вам счастье. А это все пустая трата времени.
Esp серия обычно программируется через среду esp-idf в vscode. Еще можно использовать спец. графическую среду без "ручного" такого написания кода. Да использование устаревшего 8266 не самое удачное решение. Есть мини платы esp32c6 , например, с поддержкой зигби. Это более интересное решение.
Похожая система "строилась" одним пинком в конце 80 годов прошлого века на пк при помощи MSM, где каждый компьютер хранил свою часть базы со своей номенклатурой , а в сети это было представлено общей базой. Все это было еще до эпохи всеобщего интернет и работало в виде распределенной системы хранения данных в локальной сети конкретной крупной организации. Эта технология до сих пор поддерживается в иеархических СУБД типа cache от intersystems. Проблема тогда, как и сейчас, была в нормальных средствах разработки приложений для пользователя для таких СУБД.
Писал выше, не латать старую систему, а потратить время на ее замену новой, современной с минимальным количеством времени на ее разработку и внедрение используя готовые, современные решения. Есть опыт , когда наем и 30 разработчиков, не помогает в "латании" таких устаревших или "неправильно написанных изначально" системах.
Весь минус "самописанных" по своим "стандартам" систем заключается в том, что кроме самого "писателя" часто никто не может разобраться в написаном и надежность работы таких "самописанных" систем крайне низкая. Поэтому бизнес сейчас и покупает 1С, где нет проблем с сопровождением и поддержкой их работы.
Оду как раз и есть orm с надстройкой на postgresql. Работает с данными через свой кэш, т.е. все пользователи работают с кэшем данных. Никто не заставляет использовать оду как ерп систему. Главное там есть orm и готовая система безопасности доступа пользователей к данным и формам их представления, а также система распределения данных одной базы между разными организациями. За 20 лет там много чего сделано разработчиками и в двух словах всего не опишешь. Здесь минимальным количеством трудозатрат можно в короткий срок запустить проект на любой "вкус и цвет". А "костылить" свое - это как раз путь в никуда, так как предполагает большие трудозатраты с непредсказуемым финалом. Сейчас на рынке вполне много готовых различных продуктов с готовым решением, на которые потрачены годы на разработку и десятки миллионов долларов. Главное взять его на "вооружение" и быстро показать заказчику готовое решение.
А если , все же, есть желание выпустить свой "уникальный" продукт, то придется найти богатого спонсора для наема 1000 индусов и потратить ни один год на разработку для создания хотя бы примерно конкуретного на рынке продукта.
Почему нельзя было взять готовую orm систему с нормальной субд типа postgresql и не придумывать все это? MySQL явно не та база для большой бизнес системы. Есть, например, odoo с хорошим orm движком, который "отлаживают" уже лет 20 1000 индусов. Работает быстро, пишутся модели "одним кликом", поиски работают мгновенно. И ошибка автора была в том, что он пытался "ремонтировать" хлам старой системы, на которую были ранее потрачены большие ресурсы и деньги. Это "известная история" не только в данной компании. В данном случае нужно было , скорее всего, брать другую, современную orm систему и быстро запускать на ней новый проект.
https://alphacephei.com/vosk/android
https://www.youtube.com/watch?v=i8SJv4Ezhhg. Делал себе для электровела. Все работает offline безо всяких аи и интернета. Есть режим обучения на русском языке.
Зачем все это вспоминать? Таким занимались в конце 80 и начале 90, когда не было современных средств разработки и других процессоров.Сам писал на ассемблере драйвера под разные устройства. Сейчас все это в прошлом и давно забыто.