Оно компилируется, работает, и позволяет заглянуть в потроха MIDI файлов.
Правда, оно написано но новой модной версии С++, позволяющей удивительные (для старого меня) конструкции — см. рис. 1. И требующей установить компилятор clang.
Понятно, придётся всё это адаптировать к ардуиновскому С++. Но пока я считаю, что это самый короткий путь для меня чтобы получить код, сканирующий любой MIDI файл и позволяюший мне узнать про этот файл всё, что мне надо.
Отдельное удивление вызвал факт, что программа LMMS (которую я использую для создания MIDI файлов) задаёт темп воспроизведения не в заголовке MIDI файла (как я ожидал после изучения формата MIDI файлов), а с помощью МЕТА-команды. Это несколько усложняет дело, но уже хорошо, что я знаю, как там задаётся темп на самом деле.
Ну, в общем, худшие подозрения оправдались: там нет никакого такого поля в заголовке файла, в котором бы были указаны номера использованных каналов. В MIDI файлах хранится тупо поток MIDI команд, которые «как есть» отправляются в синтезатор. А номер MIDI-канала, как известно, является частью статус-байта каждой команды. Т.е. придётся перебирать все команды (точнее все статус-байты) в записанном потоке, чтобы составить список используемых каналов. Это всё для того, чтобы проверять, что MIDI-каналы, использованные в файле авто-аккомпанемента, не пересекаются с каналами, связанными с клавиатурами баяна. (В первой версии буду просто проверять, что всегда используется 10-й канал, т.е. стандартный канал ударных инструментов.)
Осталось либо найти готовую библиотеку чтение MIDI файлов, либо писать собственный сканер. Но поиск таких библиотек — это уже будет задача на следующий вечер.
И провёл натурные испытания этого самого ИБП: запитал от этой штуки Orange Pi Plus и посмотрел, что будет.
Задумка не сработала: аккумулятор разряжается быстрее, чем заряжается. Потребляемый ток я не измерял, что зато измерял напряжение на аккумуляторе. За несколько часов испытаний оно менялось от 4.17 вольт до 4.15. Т.е. мощности в 5 Ватт не хватает, чтобы и заряжать аккумулятор, и при этом ещё питать Апельсинку.
Заказал 15-Ваттную версию (на 2 аккумулятора). Корпус для неё буду клеить по той же технологии, из листового ПВХ. Окошко для светодиодов, кстати, сделано по супер технологии: прямоугольное отверстие вырезано ножом и залито термоклеем; получилось на удивление пристойно.
Алгоритм простейший: перебираем все 128 каналов по очереди, смотрим в каких каналах есть активность. Берём самое большое обнаруженное «окно» и выбираем канал, находящийся в самой середине этого окна. Само собой, всё происходит без участия человека.
Выбором канала будет заниматься передатчик (т.е. баян).
По моей задумке, после того, как канал для передачи выбран, передатчик начнёт в этом канале посылать спец-сигнал. А приёмник при включении будет сканировать все каналы в поисках этого сигнала. В результате должно получиться выбрать свободный канал и установить связь совсем без участия человека.
Особенно если вспомнить, что на самом деле означает термин «джазовый стандарт» и каким образом он вообще появился.
Просто «наши» стандарты (в отличие от «их» стандартов) не были переписаны в спец-книжечку в своё время. У наших песен даже аранжировку почти не надо подкручивать; многое уже в исходном виде звучит как надо.
Удивительным путём я пришёл к получению настоящего удовольствия от этих песен.
В общем-то, можно начинать писать прошивку приемника, который будет принимать байтики из баяна и отправлять их в MIDI порт.
И начать надо с алогритма поиска свободного канала (на стороне передатчика) и автоматического поиска передатчика на всех каналах (на стороне приемника). Не хочу вручную каналы связи задавать; пусть само трудится.
Те мелодии, которые встроены сейчас в прошивку v1.00, — это по сути последовательность миди-команд. Раз уж у нас будет контроллер, в котором дофига памяти, почему бы не читать MIDI-файлы с флешки?
Теоретически, можно будет вообще любые «минусовки» проигрывать, не только партию ударных.
Здесь показываю упомянутый ранее новый способ выбора инструмента.
В целом, этот экран повторяет тот же самый интерфейс, который используется в самом синтезаторе ATEMP. Можно перебирать группы инструментов, а потом выбирать инструмент внутри группы. Или же просто продолжая нажимать стрелки вправо-влево можно перебрать вообще все звуки, которые реализованы в синтезаторе.
Мне не нравится, как сейчас в текущей версии прошивки происходит выбор инструментов. Если для какого-то инструмента (номера программы в терминах MIDI) есть варианты звучания (разные «банки», переключаемые MIDI командой CC 0 vv), то надо сначала выбрать номер инструмента, а потом перебирать все доступные для него варианты звучания. И при этом видишь только номера инструментов и номера вариантов; очень много нажатий кнопок (даже в адаптированном к синтезатору варианте) и совершенно никакой наглядности.
Делаю экспериментальный вариант спец-экрана для выбора инструмента. Будет два селектора: «группа инструментов» (пианино, электронные пианино, органы, гитары, и т.п.) и «инструмент внутри группы». И чтобы перебирались не номера, которые фиг запомнишь, а нормальные названия групп и инструментов (текстом).
И беда пришла , откуда не ждал. Я, ни в чём себе не отказывая, добавил все названия всех групп инструментов на руссском, каждое название длиной до 20 символов (ширина экрана). И прошивка перестала влезать во флеш-память. 🙁 Там оставалось свободным примерно 6 килобайт флеш-памяти, и табличка с текстом заняла их все, и даже больше.
Пришлось утоптать тексты: ограничил длину названий 15-ю символами и, главное, перевёл всё обратно на английский. В результате осталось свободным примерно 2 килобайта флеша.
Этого достаточно для добавления поддержки одного синтезатора, но недостаточно для дальнейшего развития, когда понадобится поддерживать несколько синтезаторов. Ну и объём кода тоже наверняка увеличится ещё.
А значит надо менять платформу.
Изучив варианты, я думаю, что остановлюсь на RP2040-Zero (см. рис. 1). Там 2 процессора, 264 кб ОЗУ, 2 Мб флеша. И оно давно поддерживается средой Arduino IDE. У меня есть одна внешняя зависимость: библиотека подержки OLED экрана GyverOLED; так вот она, вроде, нормально компилится для RP2040 (работу пока проверить не на чем). Т.е. переход вполне реален. Надо заказать пару контроллеров и слепить прототипчик.
Там, правда, нет встроенной EEPROM памяти. И это жирный минус. Придётся лепить внешнюю микросхему AT24C256. Но это решаемо.
