@james, as you know, I am using 2 MC8, one of them being the master, let’s call it A and the second a slave called B.
From A I send this midi sequence to B
Select bank 0
Engage preset A
Select bank 1
In B, the bank 0 contains preset A with following MSGs
1-Engage preset A in bank 10 using press
2-Engage preset C in bank 20 using press
3-Engage preset A in bank 1 using press
4-Engage preset E in bank 1 using press
Problem is that if the current displayed bank in B is bank 1, only preset 3 and 4 are executed when I send the midi sequence from A.
If the currently displayed bank on B is bank 0, I correctly get the 4 preset engaged.
I think this problem appeared with the last firmware, but not sure as I recently added the last ‘Select bank 1’ on A.
The problem seems to be that if B receives a midi command to select a different bank, the currently executing preset engaged by midi is perturbed in a strange way ???
What is very strange is that those engage presets, which are not executed, are not related to current display bank ??? Why the ‘currently displayed’ status get involved in this game ?
It seems to be a bug, I expect that the sync be respected if I engage a preset from A on B, I expect that it ends its execution on B before the incoming midi Change bank on B be executed.
I made some changes since my post to adapt to the problem, I removed the last bank select by midi on MC8-2, but the situation has not changed : depending on which bank is displayed on MC8-2, part of the engages fails.
MC8-1 bank controlling MC8-2 is the first, each preset should engage one preset on MC8-2, this MC8-2 preset itself engages several presets in various banks on MC8-2. This succeeds only if Songs part bank (first) is displayed on MC8-2.
In this version they are intended to work from A to P, A does some inital tasks and engage B, there is a play session where I can change current bank on MC8-2, then I press C, again play, then D, etc.
So connect your 2 mc8 by some USB host (IConnectivity on my side, channel 9 on each) then press preset A on MC8-1, change bank on MC8-2, then press C on MC8-1 and the related engaged on MC8-2 are only partially executed. Thanks.
I will do same recording to check I have similar results and report here, but just a thought, could it be the ‘Current bank’ usage which could be trying to run on a bad ‘current’ bank ? Because I use it intensively.
What I observe (and hear) : when I engage a preset (let’s say C) on mc8-1 and if MC8-2 is not displaying bank 1 which is the bank containing the presets I am engaging by midi from mc8-1, my korg synths, piloted by mc8-2, wont change to the sound preset as they ought to.
The midi PC sequence is not sent.
I verified all this using an external midi monitor.
But if, when I click on preset mc8-1 's preset C, the mc8-2 displays the bank containing the target presets, the Korgs synths receive their PC and change their sound according the PC.
On my external midi monitor I see that PC are sent.
One question : does the action line in the activity monitor is a proof that the reported action is effectively running OK ??? On an external midi monitor, what is sure is that the PC sequences are missing in one case.
But I will replay it using the MC8-2 activity monitor and report here, give me 2 hours.
Could you check the ‘Current bank’ ?
EDIT : moreover, could the fact that mc8-2 be under editor impacts the results ???
Unfortunately I can no more open in the editor a virtual midi port, it was ok some time ago.
So I can’t use the routing of the MC8-2 port 1 to my PC.
So I can’t use the activity monitor in MC8-2 to trace, but here are pictures in chronological order.
First is a picture of the 2 MC8 before I press preset C on mc8-1
You can see that some of the PC are not sent in the second trace, channels 7, 10 and 13 which are the Korgs ones.
EDIT : I just realized that the monitors are receiving the output of my 2 MC8, so the first midi activity, up to the channel 11, is related to MC8-1, the end is MC8-2 so in second report mc8-2 is sending nothing.
Hi @james , any news on this ?
The more I think to this the more it appears as a sync problem, the original order of messages being not respected, the change bank coming after the engage.
I have seen another recent thread with similar problem.
This is a serious limitation when we try to manage MCxx by midi from the external sider.
You can replace mc8-1 by midi-Ox or any midi generator pgm, same result when sending the midi PC to select bank and then midi CC to engage preset.
EDIT : I still hope a solution, all my midi command system depending on this feature running Ok ???
It is clear that midi implementation does not respect the order of received PC and CC, the PC0 to select first bank beeing slower because it redraws the screen, the following CC to engage a preset in first bank becomes its execution before end of bank being selected.
I see several solutions, the easier would be to have several midi messages which engage a preset in a dedicated bank for a selected action,
engage for press : CC n1, bank, preset
engage for release : CC n2, bank, preset
engage for noaction: CC n3, bank, preset
What do you think ?
Another option would be one NRPN ?