-
Notifications
You must be signed in to change notification settings - Fork 106
MIDI messages for MiniDexed Performance parameters #915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Build for testing: |
SysEX bytes are 7 bits, so I don't think this will work in this way. |
|
How on earth can you be so quick to figure this stuff out? |
|
Build for testing: |
|
The Performance Editor in https://github.com/probonopd/MiniDexed_Service_Utility/releases/tag/continuous should now work with this. Still a bit rough around the edges but it is a start. |
|
On a real DX, you have two methods for signed values:
SysEx are 7-bit just because the bit 8 is reserved for status byte. The bit 8 must not occur in data/values. Every occurrence of bit 8 will be a start of a new message for every device in the chain. |
I've seen a few sysex messages in the sysex-controls project :) Have you seen how MIDI encodes the 14-bit signed Pitch-bend values with translation? The encoding could be similar here. |
|
@soyersoyer do you think using that scheme would have advantages over what I have described above? |
|
Build for testing: |
I think yes, consistency is better. @diyelectromusic What do you think? |
To be honest, there is quite a lot to digest here and seems a bit of a change of heart from previous discussions where such things didn't seem to be wanted. With regards to the specific comment re 14-bit MIDI values that is a standard MIDI way of doing things. We see it in pitch bend and with LSB/MSB pairing of bank numbers, and with LSB/MSB splits of CC messages, so that definitely ought to be the first option for anything more than 127 in my view. With regards to this general idea - there are many options for this kind of thing and I'm a little nervous about apparently inventing yet another. The DX7II I think has the various SysEx options already. Some relevant previous discussions: #702 #604 #496 (comment) #504 As I recall things, the DX7 SysEx format has options for setting parameters and options for simulating DX7 button presses; and at some point it may be that using NRPNs makes more sense... And I have to admit I still quite liked my simple extension idea that allowed the UI TG messages to be passed over MIDI (more here) but that is not quite the same thing as this I think? In short, I'd need to think about it a bit - but are we sure there aren't already existing mechanisms in the specs, even if not in MiniDexed at the moment? :) Kevin |
|
Thanks for your feedback @diyelectromusic. The way I see it, "MiniDexed Performances" are their own thing that have no direct Yamaha equivalent. Hence there is no single, consistent Yamaha way to edit the parameters in them. Yes, you can set/get some values, but not all in a consistent way. This is why I thought of the above. The whole NPRN thing I must admit I don't fully understand yet. I don't think "MiniDexed Performances" must stay the only type of performances we support. I recently implemented the sysex for TX816 performances. And who says that no one will implement DX7II style and maybe even TX802 style performances as well one day, too? If so, we should use their native SysEx and in-memory format for them. |
|
Well the thinking behind my SysEx proposal that I used to extend the UI across devices was that we already had messages floating around the system for communicating TG and GLOBAL parameters around, so I just implemented a relatively simple mapping of them onto MIDI. That way, whenever a new parameter is added they are automatically recognised. I don't know if that allows you to do everything you're proposing here, but it does have the advantage of allowing full remote control of anything settable in the MiniDexed UI over MIDI. And whilst we have parameters not in the original spec for our MiniDexed performances, there is (as I recall) a fair bit of expandability built into the existing SysEx messages to add things rather than reimplement a new system. But I've not looked at it for a while so would probably need to check again... Kevin |
|
For the time being, we may consider the |
|
Build for testing: |
UPDATE: Proposed MiniDexed Performance SysEx Message FormatWhere:
To request a dump of the corresponding value, leave the To request a dump of all global parameters: The response to this get request will be in the format: To request a dump of all parameters of TG The response to this get request will be in the format: Table 1: Global Parameters (Non-Tone Generator-Specific)
Table 2: Tone Generator-Specific Parameters
Notes:
|
|
Build for testing: |
|
Build for testing: |
|
Build for testing: |
|
So, this is how the sysex maps to the ini: MiniDexed Performance Parameter SpecificationGlobal (Non-TG) Parameters
Tone Generator (TG) Parameters(Each TG: 1–8, INI keys are suffixed with TG number, e.g.
Encoding Notes
Encoding for signed values:
SysEx Command Format
Example: Set TG1 Volume to 127 (TG index is zero-based in SysEx.) Example: Get all global parameters |
|
Considerations on future-proofing:
|
Can any MIDI device send data in such encoding? |
|
Oops, that was a leftover from an earlier discussion. Fixed it. |
Did you take a look my original rejected change I referenced above that exposed the internal global and TG parameters into a SysEx message? I think that approach could be made to do everything you're doing here, if I'm understanding you correctly, without adding another place where TG and global parameters are defined and have to be kept in sync. It already includes TG number/global indication as it is just extending what is already there, not duplicating it. It was only originally designed for single parameter updates, in response to the UI, but I see no reason why it couldn't be a string of updates in a single message if required, which I think is what you're suggesting here? Most of the work is in these two functions: https://github.com/diyelectromusic/MiniDexed/blob/16TGExpander/src/minidexed.cpp#L2097 And if you're worried about future-proofing, I ought to mention there seems to be a lot of duplicating information across several files (MIDI handling, MIDI transports, minidexed, performance and the new performance sysex files) which is going to make maintaining the code "fun" pretty quickly I'd imagine... I'm not clear why this requires changes in the MIDI transports themselves for examples. Don't they all already pass SysEx handling into the MIDI parser? Kevin |
|
Build for testing: |
So far, MiniDexed Performances were not entirely editable via MIDI commands.
To change this, and to allow for interactive ways to change the performance parameters in user interfaces like this, we need MIDI commands.
Proposed MiniDexed Performance SysEx Message Format (still subject to change)
Where:
F0andF7are the start and end of the SysEx message.7Dis the Manufacturer ID reserved for prototyping, test, private use and experimentation.XX10is the get (dump) command ID for MiniDexed global performance parameter request.11is the get (dump) command ID for per-TG performance parameter request.20is the set (write) command ID for MiniDexed global performance parameter change.21is the set (write) command ID for per-TG performance parameter change.ppis the parameter number.vv vvis the parameter value (or empty if requesting a dump).pp pp vv vvmay be repeated as often as needed if more than one parameter shall be set.To request a dump of the corresponding value, leave the
vv vvaway.To request a dump of all global parameters:
The response to this get request will be in the format:
To request a dump of all parameters of TG
nn:The response to this get request will be in the format:
Table 1: Global Parameters (Non-Tone Generator-Specific)
vv vv)F0 7D 10 00 00 F7(get) /F0 7D 20 00 00 vv vv F7(set)00 00(off) ..00 01(on)F0 7D 10 00 01 F7(get) /F0 7D 20 00 01 vv vv F7(set)00 00(off) ..00 01(on)F0 7D 10 00 02 F7(get) /F0 7D 20 00 02 vv vv F7(set)00 00(0) ..00 63(99)F0 7D 10 00 03 F7(get) /F0 7D 20 00 03 vv vv F7(set)00 00(0) ..00 63(99)F0 7D 10 00 04 F7(get) /F0 7D 20 00 04 vv vv F7(set)00 00(0) ..00 63(99)F0 7D 10 00 05 F7(get) /F0 7D 20 00 05 vv vv F7(set)00 00(0) ..00 63(99)F0 7D 10 00 06 F7(get) /F0 7D 20 00 06 vv vv F7(set)00 00(0) ..00 63(99)F0 7D 10 00 07 F7(get) /F0 7D 20 00 07 vv vv F7(set)00 00(0) ..00 63(99)Table 2: Tone Generator-Specific Parameters
vv vv)F0 7D 11 nn 00 00 F7/F0 7D 21 nn 00 00 vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 01 F7/F0 7D 21 nn 00 01 vv vv F700 00(0) ..00 1F(31)F0 7D 11 nn 00 02 F7/F0 7D 21 nn 00 02 vv vv F700 00(0) ..00 0F(15),00 10(omni),00 11(off)F0 7D 11 nn 00 03 F7/F0 7D 21 nn 00 03 vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 04 F7/F0 7D 21 nn 00 04 vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 05 F7/F0 7D 21 nn 00 05 vv vv F73F 1D(-99) ..00 63(99) 7-bit noteF0 7D 11 nn 00 06 F7/F0 7D 21 nn 00 06 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 07 F7/F0 7D 21 nn 00 07 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 08 F7/F0 7D 21 nn 00 08 vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 09 F7/F0 7D 21 nn 00 09 vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 0A F7/F0 7D 21 nn 00 0A vv vv F73F 38(-24) ..00 18(24) 7-bit noteF0 7D 11 nn 00 0B F7/F0 7D 21 nn 00 0B vv vv F700 00(0) ..00 7F(127)F0 7D 11 nn 00 0C F7/F0 7D 21 nn 00 0C vv vv F700 00(0) ..00 0C(12)F0 7D 11 nn 00 0D F7/F0 7D 21 nn 00 0D vv vv F700 00(0) ..00 0C(12)F0 7D 11 nn 00 0E F7/F0 7D 21 nn 00 0E vv vv F700 00(off) ..00 01(on)F0 7D 11 nn 00 0F F7/F0 7D 21 nn 00 0F vv vv F700 00(off) ..00 01(on)F0 7D 11 nn 00 10 F7/F0 7D 21 nn 00 10 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 11 F7/F0 7D 21 nn 00 11 vv vv F700 00(off) ..00 01(on)F0 7D 11 nn 00 12 F7/F0 7D 21 nn 00 12 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 13 F7/F0 7D 21 nn 00 13 vv vv F700 00..00 07F0 7D 11 nn 00 14 F7/F0 7D 21 nn 00 14 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 15 F7/F0 7D 21 nn 00 15 vv vv F700 00..00 07F0 7D 11 nn 00 16 F7/F0 7D 21 nn 00 16 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 17 F7/F0 7D 21 nn 00 17 vv vv F700 00..00 07F0 7D 11 nn 00 18 F7/F0 7D 21 nn 00 18 vv vv F700 00(0) ..00 63(99)F0 7D 11 nn 00 19 F7/F0 7D 21 nn 00 19 vv vv F700 00..00 07Notes:
For get (dump) requests: Leave the
vv vvfield empty. For example, to get theCompressorEnablestatus:The system will respond with:
indicating the value is
00 01(on).For set (write) requests: Include the
vv vvfield to specify the value. For example, to set theCompressorEnabletoon:This writes the value
00 01(on) to theCompressorEnableparameter.7-bit note: For signed values (Detune, NoteShift), use 2's complement (2 bytes across two 7-bit bytes), split into two MIDI-safe 7-bit bytes:
3F 1D(-99) ..00 63(99)3F 38(-24) ..00 18(24)For boolean values,
00 00= off/false,00 01= on/true.For MIDI Channel:
00 00(0) ..00 0F(15),00 10(omni),00 11(off).nnin the SysEx command is the Tone Generator (TG) number, not the MIDI channel.For unknown or unsupported parameter numbers, or malformed SysEx messages, the system should simply ignore the message and take no action.