1) MIDIIN VB5
Это код, с которого все началось. ВВОД и ВЫВОД MIDI с использованием только VB5.
Этот код надежен и никогда не ломается.
2) MIDIIN В VB6
Это точно такой же код, как и в приведенном выше коде VB5, только скомпилированный с помощью VB6.
Это НЕ РАБОТАЕТ! Я твердо убежден, что MIDI-вход в VB6 просто невозможен
Я был бы очень признателен, если бы кто-нибудь смог выяснить, почему этот код работает нестабильно!
...Похоже, что код просто не работает, если скомпилирован в VB6. Программа работает от 1 до 30 секунд, а затем вылетает. Подозреваю, что VB5 фиксирует структуры данных в памяти и не позволяет сборщику мусора перемещать их. Поскольку MIDI IN требует логики обратного вызова для сохранения указателей на эти структуры данных, необходимо, чтобы память не перемещалась. (As MIDI IN requires callback logic to maintain pointers to these data structures, it is necessary that the memory is not relocated.)
3) Это VB.NET используется VS 2010. Код надежен как скала - он никогда не ломается.
Преобразование этого кода из VB5 было настоящей пыткой
- пришлось отключить сборку мусора и использовать GlobalAlloc!
Подумалось: может, эти же "пытки" применить к проекту на VB6... но автор бы так и сделал. Значит, не вышло. И если про GlobalAlloc ещё вроде понятно, то как в vb6 отключить сборщик мусора?..
Сам я когда-то нашёл OCX-контрол "MidiIn", кажется, от Marby, но и с ним программа падала. (Даже очень простая программа, где падать было толком нечему.)
Тогда я перешёл на навороченный движок BASS.dll + BASSMIDI.dll - но и такой миди-вход тоже приводит периодически к падениям, в разное время, абсолютно бессистемно. И я думаю, именно по той же таинственной причине, с коей столкнулся Mike Le Voi. Наверняка и Bass.dll просто обращается к winmm.dll. Если миди-вход не включён, падений нет.
Варианта два:
1) Исправить эту нестыковку миди-входа с VB6 (мне это не под силу) - тут вопрос: может, вы с этим сталкивались и выход известен?
2) Сделать отдельную программу для миди-входа на VB5, законно используя winmm.dll и код Mike Le Voi, и наладить сообщения между процессами по принципу IPC (основной проект перевести на VB5 вряд ли возможно, там очень много всего). Тут вопрос: разумно ли компилировать на VB5, не будет ли конфликтов в новых системах (помимо необходимости устанавливать Msvbvm50.exe)? На моей Win7x64 VB5-й миди-тест запустился легко (стоило лишь подложить к программе msvbvm50.dll). Хотя сама среда VB5 не ставится, требует Win32 (но это не проблема). Win10 у меня нет, а win11 даже ни разу не видел - не будет ли там БОЛЬШЕ проблем с процессом, скомпилированным на VB5, чем с программой на VB6?
Спрашиваю потому, что есть запасной вариант - я могу сделать процесс-посредник не на vb5, а на AutoHotKey. Это мне посложней будет, но справлюсь, прецеденты есть.
В приложении проект Mike Le Voi, который на VB5 работает отлично, на VB6 - с таинственными падениями, а на VB-Net вновь с трудом прилажен:
