Velocities Scale 0-100 or 0-127

[Banana71]

The DX7 works internally with velocities values between 0-100, but midi controllers output values is between 0-127. It doesn't matter at all with self-programmed sounds, but sometimes you need an original preset sound. For me, the sound difference and the playing feel is very different.
I have uploaded an audio sample where you can hear very clearly what I mean. I used the Original Preset DX7ii FullTines.
A: Velocity 0-100; B: Velocity 0-127 (Headphones recommended)
In Cubase it is possible to adjust the scaling (4/5) using keystroke compensation. A switch in each TG that toggles the scaling would solve the problem. Would that be possible in miniDexed?

Dexed.Velocities.AB.mp4

[dcoredump]

Exactly this behaviour is implemented in MicroDexed and MicroDexed-touch. Should not be a big problem for MiniDexed...

[probonopd]

The DX7 used 0-100 whereas the MIDI standard specifies 0-127. I assume that the DX7 II and subsequent models used 0-127, and so does MiniDexed, and this is a good thing. Or am I wrong?

@dcoredump do you know what we'd need to do to satisfy the idea of the original poster?

[dcoredump]

You only need to multiply the velocity value with 100.0/127.0. For MicroDexed we have implemented a switch to enable/disable this behaviour.

[probonopd]

Likely such a switch would be good for MiniDexed as well, wdyt?

[Banana71]

The internet does not agree on the velocities problem.
The values that are output via MIDI Out are different between the two models DX7 Mark 1 and DX7 Mark 2. With which values the instruments work internally is uncertain (maybe 0-100). In order to avoid any discussion I would prefer a Velocities multiplier in the Performance.ini for each TG.

Example in Performance.ini:
VelocityScaleFactor1=100 # 0 .. 127, 100 is recommended for original DX7 patches, normal 127

Personally, I could live with a switch that toggles between 100 and 127

[Banana71]

I think it's a good idea to import the original TX816. Unfortunately, without processing, the sounds are very harsh and wiry. The adjustment is very time consuming and not always with good results. The simplest solution would be to adjust the velocity in miniDexed. It would be great if one of the developers could take a look.
My thoughts:
The transfer of 2 parameters each TG would be sufficient. This would make it possible to adapt to your own midi controller and new doors would also open up for sound design. The parameter values must be entered in the range of 0 - 127.
The following parameters should be added to the Performance.ini:
VelocityScaleMax1:
VelocityScaleOffset1:
VelocityScaleMax2:
VelocityScaleOffset2:
....
VelocityScaleMax8:
VelocityScaleOffset8:

Explain:

Velocity Calculator			DX7	DX7II	User
max. V		127	109	119	3
offset V.		0	16	6	127
X=Velocity Input from MIDI
1		1	17	7	126
2		2	17	8	125
9		9	23	14	118
22		22	32	26	106
32		32	39	34	96
44		44	48	45	84
56		56	57	56	72
64		64	63	63	65
78		78	73	75	51
96		96	86	91	33
112		112	98	106	18
120		120	104	113	10
125		125	108	117	5
126		126	108	118	4
127		127	109	119	3
Formel: X/127*(max.V-offset V)+offset V

Here is a video by Hedge777 on the subject: https://youtu.be/ojOiok2CRmw

AB comparsion of TX816 Piano: A=MIDI Data unfiltered, B=Midi Velocity scaled to 80% with Cubase

Velocity.AB.mp4

[dcoredump]

That would be great!

Do you mean ist like that: Mode 0: No Effekt, Velocity ist taken from Midi Controller Mode 1: Scale of the DX7 Mode 2: Scale of the DX7II Mode 3: User defined,

I thought about three additional methods:

void setVelocityScale(uint8_t offset, uint8_t max);
void getVelocityScale(uint8_t* offset, uint8_t* max);
void setVelocityScale(uint8_t setup);

which "feed" the private vars uint8_t velocity_offset and uint8_t velocity_max. Inside Dexed::keydown() the velocity scaling (=> "your" formula) will be used.

The last of the methods is for using a default setup:

enum {
MIDI_VELOCITY_SCALING_OFF,
MIDI_VELOCITY_SCALING_DX7,
MIDI_VELOCITY_SCALING_DX7II
};

This is only for convinience, you can also set the values by your own.

I took the values ​​from the video (DX7 16-109 & DX7II 6-119) and should first prove themselves.

The different default values can be easily changed if they are not fully correct. I will give it a try and will come back if I added this functionality.

Regards, Holger

[dcoredump]

Answering myself: that was easy :) Here is the patch:

diff --git a/src/dexed.cpp b/src/dexed.cpp
index 81dfdda..6c34634 100644
--- a/src/dexed.cpp
+++ b/src/dexed.cpp
@@ -74,6 +74,8 @@ Dexed::Dexed(uint8_t maxnotes, int rate)
   xrun = 0;
   render_time_max = 0;
 
+  setVelocityScale(MIDI_VELOCITY_SCALING_OFF);
+
 #ifndef TEENSYDUINO
   compressor = new Compressor(samplerate);
 #endif
@@ -210,6 +212,8 @@ void Dexed::keydown(int16_t pitch, uint8_t velo) {
     return;
   }
 
+  velo=uint8_t((float(velo)/127.0)*velocity_diff+0.5)+velocity_offset;
+
   pitch += data[144] - TRANSPOSE_FIX;
 
   int previousKeyDown = lastKeyDown;
@@ -1665,6 +1669,39 @@ void Dexed::getName(char* buffer)
   buffer[10] = '\0';
 }
 
+void Dexed::setVelocityScale(uint8_t offset, uint8_t max)
+{
+  velocity_offset = offset & 0x7f;
+  velocity_max = max & 0x7f;
+  velocity_diff = velocity_max - velocity_offset;
+}
+
+void Dexed::getVelocityScale(uint8_t* offset, uint8_t* max)
+{
+  *offset = velocity_offset;
+  *max = velocity_max;
+}
+
+void Dexed::setVelocityScale(uint8_t setup = MIDI_VELOCITY_SCALING_OFF)
+{
+  switch(setup)
+  {
+    case MIDI_VELOCITY_SCALING_DX7:
+      velocity_offset=16;
+      velocity_max=109;
+      break;
+    case MIDI_VELOCITY_SCALING_DX7II:
+      velocity_offset=6;
+      velocity_max=119;
+      break;
+    default: // default setup
+      velocity_offset=0;
+      velocity_max=127;
+      break;
+  }
+  setVelocityScale(velocity_offset, velocity_max);
+}
+
 #ifndef TEENSYDUINO
 void Dexed::setCompressor(bool enable_compressor)
 {
diff --git a/src/dexed.h b/src/dexed.h
index 2b7afca..a248b93 100644
--- a/src/dexed.h
+++ b/src/dexed.h
@@ -175,6 +175,9 @@ class Dexed
     uint16_t getRenderTimeMax(void);
     void resetRenderTimeMax(void);
     void ControllersRefresh(void);
+    void setVelocityScale(uint8_t offset, uint8_t max);
+    void getVelocityScale(uint8_t* offset, uint8_t* max);
+    void setVelocityScale(uint8_t setup);
 #ifndef TEENSYDUINO
     void setCompressor(bool comp);
     bool getCompressor(void);
@@ -354,9 +357,18 @@ class Dexed
     void getSamples(int16_t* buffer, uint16_t n_samples);
     void compress(float32_t* wav_in, float32_t* wav_out, uint16_t n, float32_t threshold, float32_t slope, uint16_t sr,  float32_t tla, float32_t twnd, float32_t tatt, float32_t trel);
     bool use_compressor;
+    uint8_t velocity_offset;
+    uint8_t velocity_max;
+    float velocity_diff;
 #ifndef TEENSYDUINO
     Compressor* compressor;
 #endif
+
+    enum {
+      MIDI_VELOCITY_SCALING_OFF,
+      MIDI_VELOCITY_SCALING_DX7,
+      MIDI_VELOCITY_SCALING_DX7II
+    };
 };

Default is velocity_max=127 and velocity_offset=0 - so no changes as default.

I added the commit to Synth_Dexed. Now it only has to be added to the UI of MiniDexed.

[donluca]

I can tackle this next, as soon as we figure out what's wrong with the engine selection.
I have no idea how the UI works, but I can definitely add this to the configuration file.

[Banana71]

that would be great🥳

[donluca]

Bear in mind that I have zero clue about how to set it up for each TG separately, so it's going to be a "one setting for all", at least for now.

Maybe in the future then someone can pick this up and configure in a way that it's exposed in the UI and can be set per TG separately.

[probonopd]

So the conclusion is that contrary to popular belief, Yamaha didn't misinterpret the MIDI spec to use 0-100.

The DX7 keyboard may only send a maximum velocity of slightly above 100 due to what might well be some hardware limitation, but the sound engine inside can respond up to 127.

So the conclusion seems to be that Yamaha wanted to have up to 127, and we should hence use up to 127.
If you want to play stock DX7 patches and have them sound as close as possible to the first DX7, you might want to limit the output to 100 before the MIDI signal goes into MiniDexed.

Can you follow my logic?

[Banana71]

In order to be as close as possible to the original sound, you have to adjust the velocity curve to the instrument on which the sound was programmed. The TX816 factory sounds were probably programmed with a DX7. Ultimately, it affects every sound that was programmed on the instruments of that time. Depending on the programming, the effect can be heard more or less.

[pik33]

Add a velocity scale parameter for each TG. Make default=100. Multiply the velocity from the midi input by this scale parameter before sending this to the synth. (synth_vel := (input_vel*scale) div 100) This will enable the user to combine the patches created for different machines/velocity ranges in one performance. 100 as default, 80 for DX7, the rest (0..127) for users to fine tune the performance.

[probonopd]

If one thinks about it, wouldn't "add a velocity scale parameter for each voice" what is actually needed?

[Banana71]

I thought it was clear that this is required for each TG.
One parameter is not enough. The offset is needed because otherwise some DX7 sounds are much too quiet at low velocities.

[donluca]

I'd like to throw my 2 cents in this.

Dexed (and all the various projects born from it) has always had the goal of emulating the DX7 Mk1 with the utmost accuracy.
If you look at the issue tracker and discussion on Dexed, you'll see that the author himself is not interested much into adding support for DX7 Mk2/DX7s or TX816 (DX7 mk2 patches are not supported in Dexed)

MiniDexed does things a bit differently, because it gives the user the possibility of using up to 8 TG just like the TX816 so we could say that, contrary to the goal of Dexed, the focus of MiniDexed could be trying to reproduce the behavior of a TX816 as closely as possible.

The TX816 is basically a modular DX7 Mk1, with 8 slots to have up to 8 DX7 "modules" working together.

The keyboard Yamaha produced to use the TX816 is the Yamaha KX88 which has the exact same "limitation" of the original DX7 Mk1 in Velocity range: it goes from 15 to 110, as reported by this user so even if MiniDexed is aiming at reproducing the behavior of a TX816 (+KX88 keyboard), then it should still keep the velocity range of 15-110 (or 16-109 as already implemented).

Of course, giving the possibility of having the full 0-127 range is a nice addition which should definitely stay, but I'd say that, for consistency reason, the same velocity setting should be applied to all TGs.

[Banana71]

Of course, giving the possibility of having the full 0-127 range is a nice addition which should definitely stay, but I'd say that, for consistency reason, the same velocity setting should be applied to all TGs.

First of all, thank you very much for your good work👍🏼

It depends on what velocity range was used when the sound was programmed. e.g. the new sounds that I programmed with the help of Dexed sound dull and boring in "DX7" mode, the highs are simply missing. The velocity scale must be adaptable to the respective sound.

By the way, I suspect that Yamaha has adapted the behavior of the keyboard to the sound engine. e.g. the offset of 16: With values ​​below 16, the sounds may be barely perceptible. *There are also fewer operator level increments than the 0-99 that can be set. Yamaha certainly would have been able to make their keyboards MIDI compliant in 1983, but I don't think it would have made sense for the DX7. The engineers at Yamaha certainly knew what they were doing.

*EDIT: I must have confused a few things with the SY99. Correct is: I must have confused a few things with the SY99.
Correct is: With the Yamaha SY99 the setting range for the operator output level is 0 - 127. These are then scaled to 0 - 99, as usual with the DX7

[donluca]

Oh you're right, you've brought up a point I completely missed: new user made patches which have probably been made either on Dexed or other derivatives which, obviously, give the full 0-127 range.

My mind was stuck on factory patches/old patches made back then when there weren't alternatives to the original hardware.

In that case then yes, I agree, there should definitely be separate settings for each TG.

[donluca]

@dcoredump can you kindly follow the same convention used to set the engines for setVelocityScale() at dexed.cpp

so that it becomes:

void Dexed::setVelocityScale(uint8_t setup)
{
  switch(setup)
  {
    case MIDI_VELOCITY_SCALING_OFF:
      velocity_offset=0;
      velocity_max=127;
      break;
    case MIDI_VELOCITY_SCALING_DX7:
      velocity_offset=16;
      velocity_max=109;
      break;
    case MIDI_VELOCITY_SCALING_DX7II:
      velocity_offset=6;
      velocity_max=119;
      break;
    default: // default setup
      velocity_offset=0;
      velocity_max=127;
      break;
  }
  setVelocityScale(velocity_offset, velocity_max);
}

I know it's the same, but it just makes me feel safer seeing the same structure so that I know that MIDI_VELOCITY_SCALING_OFF = 0 without having to go and check in dexed.h for the enum.

[donluca]

Great test, thanks!

It is strange though that the DX7 scale sounds louder considering that it can only go up to velocity 109 vs DX7II 119.

I think that a test with a very simple sine wave as a sound could have been more precise.

No surprises at 0-127, and a falloff in loudness at DX7II is to be expected, but I'm still baffled by the result of the DX7.

I've doublechecked the code (both mine and Synth_Dexed) just to make sure I didn't mix up DX7 and DX7II but they are correct.

[Banana71]

You did a good job. The code is correct. I just wanted to point out that the displayed volume is not meaningful. FM synthesis often does unexpected things. If the output level of the carrier is increased, the bass component in the sound can become quieter and affects the volume display.
But in the sound example you can clearly hear the differences.

[donluca]

All credit goes to @dcoredump , I just hooked it up to MiniDexed :)

[Banana71]

All credit goes to @dcoredump , I just hooked it up to MiniDexed :)

You worked well together, many thanks

[dcoredump]

Thanks to you for the accurate examination. I have only converted your realizations into code :)