нет. имел в виду что если на столе, например, у музыканта лежит MIDI клавиатура с крутилками/слайдерами или у видеомонтажера применяет MIDI контроллер для работы, то часть контролов этого имеющегося девайса можно использовать для вышеупомянутого MIDI Mixer, при этом остальные будут использоваться по прямому назначению
да, соглашусь, но это 1 - это готовый девайс. 2 - можно использовать имеющийся девайс, или даже часть (архитектура midi позволяет использовать часть контролов в одном программе, часть в другой)
мне комфортнее работать под определенную музыку вместо рандомного окружающего звука. и да, если в таком ключе рассуждать, то все мы сами создаем себе проблемы. а если посмотреть с другой стороны, то я создал себе комфортную обстановку для работы и стремлюсь ее улучшать.
ну так это для вас. для меня регулярный (музыка играет фоном всегда, периодически приходится смотреть видео от заказчиков вслушиваясь что они там за кадром и ветром говорит)
Я тоже подумал что наверно стоило бы имитировать MIDI + костыль в виде бриджа MIDI<->WinAPI. Это позволило бы использовать MIDI пульты и использовать девайс в софте поддерживающем MIDI ввод
ну не сценарии не ограничены играми. мне, например, часто приходится приглушать музыку во время просмотра видео. еще некоторые приложения любят перехватывать события от кнопок изменения громкости, что при фоновой музыке скорее мешает чем помогает.
в целом я к тому что не всегда проблема искусственно создана. возможно для автора это вполне себе типичный юзкейс.
Там всегда 2 системных ползунка + один на каждое приложение с выводом звука. пример скорее всего утрированный но 5-6 набираются легко.
По поводу того что можно вызвать микшер проще. После появления макропада с энкодером я однозначно могу сказать, что аппаратная крутилка громкости намного удобнее даже по сравнению с клавишами регулировки громкости на клавиатуре. Ну и это просто красиво
так он и используется через pywin32. я думаю автор просто в очередной раз намекнул на ректальные подходы в winapi вызывающие конкретное желание больше туда не лезть
При правильном подборе обвязки выделенные RTC дают намного более стабильные результаты. По моему опыту случаи, когда была необходима калибровка хода единичны и были вызваны жесткой экономией (или ноунейм микросхемы rtc или кварцы)
Встроенные же генераторы в МК не имеют повторяемости даже в рамках партии, да еще и часто нестабильны в режимах с пониженной энергией генерации
Вообще для этого достаточно одного мк с двумя ацп. Те же STM позволяют их синхронизировать.
Аесли копнуть чуть глубже то есть специализированные микросхемы АЦП которые не только все как надо измерят, но еще и посчитают так, что МК останется только считать готовый результат
Одновременное семплирование как минимум тока и напряжения на одной фазе позволяет измерить сдвиг фазы тока относительно напряжения, что позволит оперировать уже комплексной мощностью
Вся прелесть задумки сводится на нет из-за одной мелочи. Казалось бы, есть измерение напряжения по трем фазам, есть 16 токовых входов, хоть по трем фазам мощность считай, хоть по каждому потребителю отдельно. Но для полноценного измерителя нехватает синхронного измерения тока и напряжения. Без синхронного измерения, увы, получится полноценно измерить мощность только на активной нагрузке от идеального источника питания. Любое искажение формы напряжения и любая реактивная нагрузка исказят измерения до бесполезных значений.
организовать групбай, как с клавиатурами
Меня больше смущают копролиты в апи, которые как бы не легаси, но с доисторических времен не менялись.
Совместимость это конечно хорошо, но не с софтом 90 года же...
нет. имел в виду что если на столе, например, у музыканта лежит MIDI клавиатура с крутилками/слайдерами или у видеомонтажера применяет MIDI контроллер для работы, то часть контролов этого имеющегося девайса можно использовать для вышеупомянутого MIDI Mixer, при этом остальные будут использоваться по прямому назначению
не понял вопроса.
да, соглашусь, но это 1 - это готовый девайс. 2 - можно использовать имеющийся девайс, или даже часть (архитектура midi позволяет использовать часть контролов в одном программе, часть в другой)
MIDI контроллеры разные бывают. можно взять какой нибудь nakeboard mc-8
мне комфортнее работать под определенную музыку вместо рандомного окружающего звука. и да, если в таком ключе рассуждать, то все мы сами создаем себе проблемы. а если посмотреть с другой стороны, то я создал себе комфортную обстановку для работы и стремлюсь ее улучшать.
ну так это для вас. для меня регулярный (музыка играет фоном всегда, периодически приходится смотреть видео от заказчиков вслушиваясь что они там за кадром и ветром говорит)
не в питоне дело, а в самом WinAPI. не знаю как у вас, но у меня всегда стойкое желание обходить его стороной когда это возможно
Я тоже подумал что наверно стоило бы имитировать MIDI + костыль в виде бриджа MIDI<->WinAPI. Это позволило бы использовать MIDI пульты и использовать девайс в софте поддерживающем MIDI ввод
ну не сценарии не ограничены играми. мне, например, часто приходится приглушать музыку во время просмотра видео. еще некоторые приложения любят перехватывать события от кнопок изменения громкости, что при фоновой музыке скорее мешает чем помогает.
в целом я к тому что не всегда проблема искусственно создана. возможно для автора это вполне себе типичный юзкейс.
Там всегда 2 системных ползунка + один на каждое приложение с выводом звука. пример скорее всего утрированный но 5-6 набираются легко.
По поводу того что можно вызвать микшер проще. После появления макропада с энкодером я однозначно могу сказать, что аппаратная крутилка громкости намного удобнее даже по сравнению с клавишами регулировки громкости на клавиатуре. Ну и это просто красиво
так он и используется через pywin32. я думаю автор просто в очередной раз намекнул на ректальные подходы в winapi вызывающие конкретное желание больше туда не лезть
где то встречал что обновление платформы по цене сравнимо как раз таки с ценой нового ноутбука от других производителей.
При правильном подборе обвязки выделенные RTC дают намного более стабильные результаты. По моему опыту случаи, когда была необходима калибровка хода единичны и были вызваны жесткой экономией (или ноунейм микросхемы rtc или кварцы)
Встроенные же генераторы в МК не имеют повторяемости даже в рамках партии, да еще и часто нестабильны в режимах с пониженной энергией генерации
Сценариев много. Спмые очевидные
1 - отсутствие доступа к ntp
2 - таймстамп нужен сразу после подачи питания, а не когда получит данные от ntp
3 - отсутствие необходимости делать корректировку хода часов во время работы.
Искажения трансфорсаторов постоянные и компенсируются калибровкой.
Подобные микросхемы конечно хороши, но тоже не из дешевых.
Вообще для этого достаточно одного мк с двумя ацп. Те же STM позволяют их синхронизировать.
Аесли копнуть чуть глубже то есть специализированные микросхемы АЦП которые не только все как надо измерят, но еще и посчитают так, что МК останется только считать готовый результат
Одновременное семплирование как минимум тока и напряжения на одной фазе позволяет измерить сдвиг фазы тока относительно напряжения, что позволит оперировать уже комплексной мощностью
Вся прелесть задумки сводится на нет из-за одной мелочи. Казалось бы, есть измерение напряжения по трем фазам, есть 16 токовых входов, хоть по трем фазам мощность считай, хоть по каждому потребителю отдельно. Но для полноценного измерителя нехватает синхронного измерения тока и напряжения. Без синхронного измерения, увы, получится полноценно измерить мощность только на активной нагрузке от идеального источника питания. Любое искажение формы напряжения и любая реактивная нагрузка исказят измерения до бесполезных значений.