Но при работе с маской дракона мне пришлось надевать респиратор
Респиратор вообще не защищает от паров, а только от пыли и взвеси. Работа с растворителями либо на открытом воздухе, либо с вытяжкой (что в домашних условиях малореально).
Ужас. Такое ощущение, что человеком, который совершенно не в курсе, надёрганы произвольные куски с разных сайтов, прогнаны через какой-то автопереводчик, сокращены в меру понимания и в таком виде выложены в виде статьи. Сумбур, пропуск ключевых слов и т.д. и т.п. :(
Из тех проблем, что не были упомянуты - сделайте человеческий интерфейс для товаров без штрих-кода. Как реализовано сейчас:
мне надо купить 5 круассанов
надо сперва нажать кнопочку "ввод количества" и нажать там 5
затем нажать кнопочку "поиск товара" и на экранной клавиатуре набрать название. Опечатка - получаешь сообщение, что товар не найден и начинай всё сначала (включая ввод количества)
Логика, что количество должно быть введено до сканирования/поиска товара - она очень программистская и очень неочевидная. Почему не сделать кнопочки +/- прямо в списке покупок - непонятно.
Ну и из мелкого - таймаут при оплате по СБП. Если у вас в процессе оплаты по СБП телефон что-то задумался, то на кассе произойдёт тайм-аут и она вылетит в изначальное меню оплаты. То, что оплата по СБП уже произошла ей как-то пофиг. Я как-то раз так попал и что-то порядка недели ждал возврата денег.
В больших супермаркетах Лента уже давно так. Берёшь сканер с памятью на входе и всё, что кладёшь в корзину, сканируешь. На выходе считываешь сканер и платишь, всё
Но проблема в том что ПРЕПОДАВАНИЕ имеет другую цель. А именно - НАУЧИТЬ -МАКСИМАЛЬНОЕ количество детей!
А, зачем, извините? Какая реальная потребность в людях со знанием verilog и умением создавать реальные устройства на fpga или asic? И чем это знание лучше, чем глубокое знание ML, например? Или синтеза органических соединений?
Субдискретизация насыщенности — High 4:2:2 level 4.1
Эээээ. Что?
Интересно, а реально есть примеры использования Orbox в продюсерских компаниях, а не только в телекомпаниях? Так как типичный сценарий общения "У нас есть мастера нужного вам сериала в таком-то формате, монтажера у нас сейчас нет, видеоинженера у нас отродясь не было. Берёте?"
Я обращаюсь. Так как у меня тупо нет времени для поиска среди десятков сервисов "полноценного". И сидящий там мальчик мне честно говорит - нет, это не мой уровень, не смогу. Либо сами ищите сервис, который сможет, либо я его возьму и отправлю в Питер, где у нас главная мастерская. И меня это вполне устраивает.
И с моей точки зрения (как технаря, представляющего себе как работает любой саппорт/сервис) это наиболее рабочая схема - первая линия минимально квалифицированных людей натренированных на стандартные случаи и передачу сложных случаев на вторую линию. Вторая линия, решающая основной массив сложных случаев.
Сейчас таких практически нет. Большинство матриц имеют 16 строк сканирования (в стандарте HUB75 на скан отведено 4 линии, а в стандарте HUB75E - 5 линий). При заказе на али надо смотреть в параметрах матрицы scan в виде 16S. Вот это и будет количество линий сканирования.
Почему это? На линии адреса строки отдаём выход АЦП. На линию данных раз в длину строки выставляем единицу. Загрузку выходного регистра делаем на каждый клок. Выход постоянно разрешён. И всё - слева направо бежит точка, и высота этой точки (номер строки) напрямую определяется выходом АЦП. Идеальный осцилл :)
Задумался. Теоретически можно взять стандартную китайскую панель с интерфейсом HUB75 и задвигать туда данные в соответствии с уровнем. Получится не чистый осциллограф, а что-то типа стробоскопического осциллографа. Зато легко получить большой красивый экран за копейки :)
Любопытная схема. Надо будет помоделировать - пока не изучал детально, поэтому что-то не очень понимаю как считать коэффициенты и насколько устойчив будет алгоритм к самовозбуждению (особенно при использовании коэффициентов).
Этот подход плохо работает когда частота дискретизации не слишком велика. Например, 1633Гц при частоте дискретизации 32кГц даст всего 20 семплов на период. То есть фактическая частота сгенерированного сигнала будет 32/20=1.6 кГц. В случае DTMF это не критично, но метод табличного синтеза с интерполяцией не сильно сложнее вычислительно, но даёт куда более точное значение синтезированной частоты.
А вообще, вы уже чуть-чуть прикоснулись к ЦОС (DSP)
Задумался, кстати, а какой спектр получится в результате проделанной тс операции - вырезания просчитанного куска на примерно 10 мс и его бесконечного повторения. В голове крутится что-то типа свёртки спектра прямоугольного сигнала частотой 100Гц (то есть sinc) и спектра исходного двухтонального сигнала, так как проделанное чем-то похоже на фазовую модуляцию. Но вот как это аналитически посчитать - ума не приложу. Разве что численно в вольфраме или матлабе считать. Нет идей? :)
Если мы говорим о вашем алгоритме "в лоб", то вам нужно считать ровно столько же таблиц. Только если хранить в памяти только участок 0-90 градусов, то требования к памяти можно уменьшить в 4 раза.
Если же говорить об алгоритме синтеза по таблице, то предпросчитанная таблица к частоте дискретизации не привязана никак вообще. От частоты дискретизации зависит только величина инкремента аккумулятора. Поэтому таблица всего одна для любой частоты.
Надо воспроизвести тестовый звук. Что-нибудь предельно простое, например синус функцию. Затем измерять частоту и сравнить измеренную частоту с воспроизведенной частотой. Если значения совпали, то значит акустическая система воспроизведения работает четко
Генерируемая частота и её значение зависят только от микроконтроллера, который её генерирует. "Акустическая система воспроизведения" на это никак не влияет.
Вот таблица предварительно рассчитанных в RAM памяти микроконтроллера PCM семплов
А если бы вспомнили школьный курс, то достаточно было бы хранить в 4 раза меньше семплов. Так как достаточно хранить только половину полупериода - вторая половина полупериода точно такая же, а второй полупериод в точности равен первому, только с другим знаком.
Если решение и есть, то период уходит далеко в века
Как уже было справедливо указано - все частоты целые, поэтому период в любом случае не может быть больше 1 сек
В микроконтроллере по-любому не хватит никакой памяти, чтобы сохранить дорожку размером в период для суммы синусов с разрешенными частотами
16 вариантов по 1 сек. При частоте семплирования 32кГц и разрядности 16 (дикий оверкилл, на самом деле) получаем 1МБ. А если вспомнить, что вторая половина каждого записи ровно симметрична первой половине, до 512кБ. Для современных контроллеров вполне терпимо.
Но. В любом случае это решение в лоб и так не делают. А делают синтез по таблице.
То есть имеем одну единственную таблицу для значений синуса от 0 до 90 градусов. Как показывает практика обычно 64 точки более чем достаточно. То есть получаем 256 точек на период.
Для каждой генерируемой частоты имеем аккумулятор, который для каждого следующего выходного семпла увеличивается на величину:
генерируемая частота / частоту дискретизации * количество семплов в таблице
Тогда целая часть этого аккумулятора будет номер семпла в таблице, а дробная - определяет с какой пропорцией надо взять этот и следующий семплы для интерполяции. Синус - функция гладкая, поэтому вполне достаточно линейной интерполяции.
Повторяем для всех частот, которые надо сгенерировать, суммируем полученные значения и выдаём на выход.
Спасибо. Я просто вбил всё одной строкой и поменял в data одиночные кавычки на двойные - насколько я помню они транслируются в одиночные. Но попробовал и ваш вариант. Получил Webhook is already set. Но всё равно ничего не работает.
Проверил статус через getWebhookInfo. Всё выглядит правдоподобно:
"result":{"url":"https://xxx.apigw.yandexcloud.net","has_custom_certificate":false,"pending_update_count":13,"last_error_date":1697555723,"last_error_message":"Wrong response from the webhook: 405 Method Not Allowed","max_connections":40,"ip_address":"xx.xx.xx.xx"}
Респиратор вообще не защищает от паров, а только от пыли и взвеси. Работа с растворителями либо на открытом воздухе, либо с вытяжкой (что в домашних условиях малореально).
Ужас. Такое ощущение, что человеком, который совершенно не в курсе, надёрганы произвольные куски с разных сайтов, прогнаны через какой-то автопереводчик, сокращены в меру понимания и в таком виде выложены в виде статьи. Сумбур, пропуск ключевых слов и т.д. и т.п. :(
Из тех проблем, что не были упомянуты - сделайте человеческий интерфейс для товаров без штрих-кода. Как реализовано сейчас:
мне надо купить 5 круассанов
надо сперва нажать кнопочку "ввод количества" и нажать там 5
затем нажать кнопочку "поиск товара" и на экранной клавиатуре набрать название. Опечатка - получаешь сообщение, что товар не найден и начинай всё сначала (включая ввод количества)
Логика, что количество должно быть введено до сканирования/поиска товара - она очень программистская и очень неочевидная. Почему не сделать кнопочки +/- прямо в списке покупок - непонятно.
Ну и из мелкого - таймаут при оплате по СБП. Если у вас в процессе оплаты по СБП телефон что-то задумался, то на кассе произойдёт тайм-аут и она вылетит в изначальное меню оплаты. То, что оплата по СБП уже произошла ей как-то пофиг. Я как-то раз так попал и что-то порядка недели ждал возврата денег.
В больших супермаркетах Лента уже давно так. Берёшь сканер с памятью на входе и всё, что кладёшь в корзину, сканируешь. На выходе считываешь сканер и платишь, всё
А, зачем, извините? Какая реальная потребность в людях со знанием verilog и умением создавать реальные устройства на fpga или asic? И чем это знание лучше, чем глубокое знание ML, например? Или синтеза органических соединений?
Эээээ. Что?
Интересно, а реально есть примеры использования Orbox в продюсерских компаниях, а не только в телекомпаниях? Так как типичный сценарий общения "У нас есть мастера нужного вам сериала в таком-то формате, монтажера у нас сейчас нет, видеоинженера у нас отродясь не было. Берёте?"
Я обращаюсь. Так как у меня тупо нет времени для поиска среди десятков сервисов "полноценного". И сидящий там мальчик мне честно говорит - нет, это не мой уровень, не смогу. Либо сами ищите сервис, который сможет, либо я его возьму и отправлю в Питер, где у нас главная мастерская. И меня это вполне устраивает.
И с моей точки зрения (как технаря, представляющего себе как работает любой саппорт/сервис) это наиболее рабочая схема - первая линия минимально квалифицированных людей натренированных на стандартные случаи и передачу сложных случаев на вторую линию. Вторая линия, решающая основной массив сложных случаев.
Сейчас таких практически нет. Большинство матриц имеют 16 строк сканирования (в стандарте HUB75 на скан отведено 4 линии, а в стандарте HUB75E - 5 линий). При заказе на али надо смотреть в параметрах матрицы scan в виде 16S. Вот это и будет количество линий сканирования.
Почему это? На линии адреса строки отдаём выход АЦП. На линию данных раз в длину строки выставляем единицу. Загрузку выходного регистра делаем на каждый клок. Выход постоянно разрешён. И всё - слева направо бежит точка, и высота этой точки (номер строки) напрямую определяется выходом АЦП. Идеальный осцилл :)
Задумался. Теоретически можно взять стандартную китайскую панель с интерфейсом HUB75 и задвигать туда данные в соответствии с уровнем. Получится не чистый осциллограф, а что-то типа стробоскопического осциллографа. Зато легко получить большой красивый экран за копейки :)
Любопытная схема. Надо будет помоделировать - пока не изучал детально, поэтому что-то не очень понимаю как считать коэффициенты и насколько устойчив будет алгоритм к самовозбуждению (особенно при использовании коэффициентов).
Этот подход плохо работает когда частота дискретизации не слишком велика. Например, 1633Гц при частоте дискретизации 32кГц даст всего 20 семплов на период. То есть фактическая частота сгенерированного сигнала будет 32/20=1.6 кГц. В случае DTMF это не критично, но метод табличного синтеза с интерполяцией не сильно сложнее вычислительно, но даёт куда более точное значение синтезированной частоты.
Задумался, кстати, а какой спектр получится в результате проделанной тс операции - вырезания просчитанного куска на примерно 10 мс и его бесконечного повторения. В голове крутится что-то типа свёртки спектра прямоугольного сигнала частотой 100Гц (то есть sinc) и спектра исходного двухтонального сигнала, так как проделанное чем-то похоже на фазовую модуляцию. Но вот как это аналитически посчитать - ума не приложу. Разве что численно в вольфраме или матлабе считать. Нет идей? :)
Если мы говорим о вашем алгоритме "в лоб", то вам нужно считать ровно столько же таблиц. Только если хранить в памяти только участок 0-90 градусов, то требования к памяти можно уменьшить в 4 раза.
Если же говорить об алгоритме синтеза по таблице, то предпросчитанная таблица к частоте дискретизации не привязана никак вообще. От частоты дискретизации зависит только величина инкремента аккумулятора. Поэтому таблица всего одна для любой частоты.
От этого генерируемая частота не изменится. Максимум появятся гармоники.
Да, я знаю, что аккумулятор может быть целочисленный и так даже удобнее.
Просто не стал уже вдаваться в детали :)
Генерируемая частота и её значение зависят только от микроконтроллера, который её генерирует. "Акустическая система воспроизведения" на это никак не влияет.
А если бы вспомнили школьный курс, то достаточно было бы хранить в 4 раза меньше семплов. Так как достаточно хранить только половину полупериода - вторая половина полупериода точно такая же, а второй полупериод в точности равен первому, только с другим знаком.
Как уже было справедливо указано - все частоты целые, поэтому период в любом случае не может быть больше 1 сек
16 вариантов по 1 сек. При частоте семплирования 32кГц и разрядности 16 (дикий оверкилл, на самом деле) получаем 1МБ. А если вспомнить, что вторая половина каждого записи ровно симметрична первой половине, до 512кБ. Для современных контроллеров вполне терпимо.
Но. В любом случае это решение в лоб и так не делают. А делают синтез по таблице.
То есть имеем одну единственную таблицу для значений синуса от 0 до 90 градусов. Как показывает практика обычно 64 точки более чем достаточно. То есть получаем 256 точек на период.
Для каждой генерируемой частоты имеем аккумулятор, который для каждого следующего выходного семпла увеличивается на величину:
генерируемая частота / частоту дискретизации * количество семплов в таблице
Тогда целая часть этого аккумулятора будет номер семпла в таблице, а дробная - определяет с какой пропорцией надо взять этот и следующий семплы для интерполяции. Синус - функция гладкая, поэтому вполне достаточно линейной интерполяции.
Повторяем для всех частот, которые надо сгенерировать, суммируем полученные значения и выдаём на выход.
Всё, простейший табличный синтез.
Побочный вопрос. В тексте функции я вижу прописана
model="gpt-3.5-turbo"Есть ли смысла переходить на 4.0 и если есть, то как это сделать - просто поменять имя модели в функции на gpt-4.0 ?
Всё, с помощью автора разобрался, мой косяк - забыл исправить get на post в конфигурации шлюза. Работает
Спасибо. Я просто вбил всё одной строкой и поменял в data одиночные кавычки на двойные - насколько я помню они транслируются в одиночные. Но попробовал и ваш вариант. Получил Webhook is already set. Но всё равно ничего не работает.
Проверил статус через getWebhookInfo. Всё выглядит правдоподобно:
"result":{"url":"https://xxx.apigw.yandexcloud.net","has_custom_certificate":false,"pending_update_count":13,"last_error_date":1697555723,"last_error_message":"Wrong response from the webhook: 405 Method Not Allowed","max_connections":40,"ip_address":"xx.xx.xx.xx"}
Похоже проблема где-то до этого