On power up there are 16 MIDI SysEx Voice dumps sent out to "channel 0x11" #386
Comments
|
This should be a setting that can be enabled/disabled, I would think.
As you pointed out, when using an editor, the *editor* should control
things, and dumps should only be sent on request.
The spamming from a sequencer sending frequent voice change requests is
also concerning.
…On Fri, Dec 9, 2022 at 9:12 AM Kevin ***@***.***> wrote:
When a ProgramChange is initiated (either over MIDI or via the UI) then
the following happens:
- MiniDexed::ProgramChange is called
- which calls MidiDevice::SendSystemExclusiveVoice
- which calls MiniDexed::getSysExVoiceDump and then calls send() for
each attached MIDI Device with the resulting data.
getSysExVoiceDump builds a Yamaha specific systems exclusive message that
starts with the bytes: 0xF0 0x43 0x0c 0x00 0x01 0x1B where c is the MIDI
channel number (in 0 to 15 format).
This means that every time the program is changed, the current voice data
for the selected TG is sent out on all MIDI devices.
However, on power up, the initialisation in MiniDexed.cpp calls
ProgramChange (0, i) and then later on calls LoadPerformanceParameters
which also calls ProgramChange() again. Both of these calls happen before
LoadPerformanceParameters calls SetMIDIChannel to set the MIDI channel for
the TG from the performance.ini file.
This means that there are two occasions on power up, for each tone
generator, where the MIDI channel is still set to its initialised (i.e.
prior to reading the performance.ini file) value of "disabled". As the Enum
for MIDI channel is the following (mididevice.h):
enum TChannel
{
Channels = 16,
OmniMode = Channels,
Disabled,
ChannelUnknown
};
Then "Disabled" - 1 is 17 or 0x11. Which is indeed the value we see in the
16 instances of the SysEx voice dump sent out on startup.
Not quite sure what the fix is... something in this chain should probably
check for a disabled MIDI channel before dumping out voice data maybe? I'm
not sure. Also I guess if the MIDI channel for a TG is set to Omni then the
voice data will always show "channel 16" ("OmniMode=17" - 1).
I get why ProgramChange always dumps the voice data too, but I can't help
think that an editor, if it wants to refresh its data, ought to ask for it
rather than "spamming" all MIDI channels ever time a voice is changed...?
And what happens if a sequencer/MIDI file player/etc sends a load of PC
messages on all channels at the start? The worst case might be sending PCs
on all 16 channels when all 8 TGs are in Omni mode... Won't that cause 128
voice dumps to channel 16 over every MIDI OUT device!?
Thoughts?
—
Reply to this email directly, view it on GitHub
<#386>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNBVNHYW53SWUMBJS6272DWMM445ANCNFSM6AAAAAASZMPU24>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Another funny - from Line 206 in f32c0c9 It looks like this only tests for SysEx messages on channels 0 to 7...? |
|
Ok, for anyone interested, this is my proposed fix for all the above:
https://github.com/diyelectromusic/MiniDexed/tree/Issue386Fix I can't test the last one - I don't have anything that has used SysEx voice dumps... so if anyone would like to take a look and check that this is the right behaviour, that would be great! Kevin |
|
Please test MiniDexed_2022-12-09-1460571. |
|
Seems ok to me, but can someone who uses SysEx and voice editing check that the behaviour is as expected? I've only checked MIDI dumps in MidiOx. Especially for MIDI channels in both 1-8 and 9-16 ranges across all TGs. |
Ok, I've been trying to find out more about this. MiniDexed compares it to MIDI channel but the Yamaha SysEx Format describes it as a device ID and I've seen elsewhere that often manufacturers included a 7-bit device ID into their SysEx message formats. So maybe it should be & 0x07, but then if genuinely a device ID it would make more sense to compare it to the TG number than MIDI channel...? I've been playing with the PC Dexed version as a voice editor and even though you can specify an output MIDI channel, all SysEx dumps seem to come out with the status bit as 0x00 (i.e. Device ID = 0)... Although again in the Dexed code (see https://github.com/asb2m10/dexed/blob/11ae4d7ef597b2d52f45e59ab56b342252d0bd88/Source/PluginData.cpp#L269) it does seem to pull out the MIDI channel to put in the message... but I've not managed to see it "on the air" so far, so I don't know. Basically I'm still not sure, so if anyone actually knows how this is supposed to work, do let me know :) Kevin |
|
Ah, just found this in the "Advanced MIDI Applications": That seems to say (do you agree?) that the Device ID is 1..16 and simply maps onto a MIDI channel number... |
Turns out that is probably a bug in one specific screen that has a "send to DX7" option: asb2m10/dexed#370 Doing it from the main Dexed screen is fine. So yes, I can now show that sending to a specific MIDI channel does seem to send to a TG listening on that channel. So I think this is now all ok? Thoughts? |
|
Thank you very much 👍 Added documentation regarding |
When a ProgramChange is initiated (either over MIDI or via the UI) then the following happens:
getSysExVoiceDump builds a Yamaha specific systems exclusive message that starts with the bytes: 0xF0 0x43 0x0c 0x00 0x01 0x1B where c is the MIDI channel number (in 0 to 15 format).
This means that every time the program is changed, the current voice data for the selected TG is sent out on all MIDI devices.
However, on power up, the initialisation in MiniDexed.cpp calls ProgramChange (0, i) and then later on calls LoadPerformanceParameters which also calls ProgramChange() again. Both of these calls happen before LoadPerformanceParameters calls SetMIDIChannel to set the MIDI channel for the TG from the performance.ini file.
This means that there are two occasions on power up, for each tone generator, where the MIDI channel is still set to its initialised (i.e. prior to reading the performance.ini file) value of "disabled". As the Enum for MIDI channel is the following (mididevice.h):
enum TChannel
{
Channels = 16,
OmniMode = Channels,
Disabled,
ChannelUnknown
};
Then "Disabled" - 1 is 17 or 0x11. Which is indeed the value we see in the 16 instances of the SysEx voice dump sent out on startup.
Not quite sure what the fix is... something in this chain should probably check for a disabled MIDI channel before dumping out voice data maybe? I'm not sure. Also I guess if the MIDI channel for a TG is set to Omni then the voice data will always show "channel 16" ("OmniMode=17" - 1).
I get why ProgramChange always dumps the voice data too, but I can't help think that an editor, if it wants to refresh its data, ought to ask for it rather than "spamming" all MIDI channels ever time a voice is changed...?
And what happens if a sequencer/MIDI file player/etc sends a load of PC messages on all channels at the start? The worst case might be sending PCs on all 16 channels when all 8 TGs are in Omni mode... Won't that cause 128 voice dumps to channel 16 over every MIDI OUT device!?
Thoughts?
The text was updated successfully, but these errors were encountered: