Problem with MIDI Patch

[anonyrat]

Hi Colin,

Think I've found a "feature" in the MIDI patch module.

I have an external synth - the Roland JV-1080 - where it has multiple drum kits.
All drum kits are accessed on MIDI channel 10.
The first two kits are user defined and the first one is MSB 80 LSB 0 Program 1 and the second is Program 2
The next set is MSB 81 LSB 0 and programs 1&2
This is repeated three more times with the LSB number increasing by 1 (so the last is MSB 81 LSB 3)
I saved all ten variations under the save as option under each module.
When I recall any of the eight MSB 81 presets they come in as MSB 80

MSB Save 1.jpg (78.75 KiB) Viewed 2447 times

This shows the save as note MSB 81

MSB Save 2.jpg (74.94 KiB) Viewed 2447 times

This is showing the module just loaded from the Library and selecting the module preset

msb 3.jpg (16.75 KiB) Viewed 2447 times

This is showing the result of the load. Note MSB 81 has gone back to 80 ??

Cheers Peter

[ColinP]

Hi Peter,

I struggled a little with your description so ended up looking at the JV-1080 manual (page 79) so I now understand what you are dealing with.

JV1080Drums.png (52.3 KiB) Viewed 2441 times

Unfortunately, I've not been able to replicate the problem. If I save a preset with channel = 10, MSB = 81, LSB = 2, Program = 2 and then reload the preset the result is the same.

Could you possibly send me a .voltagepreset file that exhibits the problem.

[anonyrat]

Hi Colin,

I know I did it 10 times and they all worked. I even sent you screen shots of the result, so I know it happened. So I read your post last night and thought Colin knows what he is doing. So why are we getting different results?
So this morning I tried it again on my second machine (not the studio machine) and tried exactly what you had written, I got the same result as you...

... so I thought about it and decided to recreate the way I did it in the studio (more "Real World" ) and managed to recreate it. These are the steps.

1 Create a MIDI Patch, adding it from the library.
2 Setup Channel 10 -- MSB 80 -- LSB 0 -- program 1 save it as Test 80 0 1
(now this is where we differed because being lazy I didn't want to go through the whole setup over and over again)
3 CHANGE MSB to 81 and then save this preset as Test 81 0 1
4 Remove the MIDI Patch.
5 Load a new instance of MIDI Patch from the library and load the Module Preset Test 81 0 1 and you should get Test 80 0 1 QED

To be thorough I did a similar test on the MIDI Drum Kit module and that worked OK
Colin I hope this was helpful - remember in step 3 this is a change NOT a new instance of MIDI Patch.

Cheers Peter

[ColinP]

Hi Peter,

I have absolutely no doubt that there's a bug here but when I tried the test exactly as you described it works fine on my machine - coming back with 81 rather than 80.

The value is stored in an "invisible knob" as a floating point number so I suspect there might be some weird rounding error going on. Maybe your FPU gives a very slightly different result to mine. I can try coding it differently in the hope that a slightly different approach works but obviously won't be able to tell if it fixes the problem or not straight away.

One thing to help narrow things down - do you get the same problem if you put 81 in the LSB parameter instead of MSB?

[anonyrat]

Hi Colin,
Some extra info for you. It seems to me that the error lies in the "saving" of the preset.
You can follow exactly what i did in the GIF. Have included the Presets used. (Test 80 80 and Test 81 81)
Also a hex edit of the preset Test 81 81 in which you can clearly see 80 and 80 (preset Test 80 80 shows the info as OK, you can check Test 80 80.modpreset to see - have included)).
As shown in the GIF increasing 80 to 81 using the up arrow looks ok on screen but it is not updating the info to be saved.

MidiPatch1.gif (1.01 MiB) Viewed 2408 times

Test 81 81.jpg (39.05 KiB) Viewed 2408 times

Modpresets.rar

(438 Bytes) Downloaded 106 times

Hope this helps
Cheers Peter

[anonyrat]

Thanks Steve. Good to know it is reproduceable.
Cheers Peter

[ColinP]

Hi Peter,

The MSB and LSB values aren't explicitly saved, instead they automatically persist as the settings of invisible knobs and the values are floating point rather than integer.

I think the problem is almost certainly caused by a tiny rounding error in the floating point math and only shows on some CPU types which is why I can't reproduce it. I've made a small modification to the code that may fix this and I've submitted it for approval by CA.

This new build will be #16 and when it's published I'll post here again to let you know. Hopefully this will fix the problem. If not I'll rewrite the code to use integers that are saved explicitly.

I've also submitted a new version of the MIDI Drum Kit module with Solo buttons and hopefully both modules will be released at the same time. There's also a Stereo Fader module waiting to be released but there's some technical problem with the publishing process on this.

[anonyrat]

Thank you very much Colin.
That has made my Christmas - almost as good as thrashing the Poms...

[Steve W]

The MSB and LSB values aren't explicitly saved, instead they automatically persist as the settings of invisible knobs and the values are floating point rather than integer.

What about the Program Change Values? Are they treated the same way? Yesterday I did some tests with the module in question using different sets of values (Ch/MSB/LSB/PC) in variations. Ch/MSB/LSB returned; PC didn't.

Did more tests, this time also with Module Presets. In all tests Ch/MSB/LSB "persisted" or were saved/restored. In all tests PC persisted (and saved/recalled) as long as the value was 0-15 (1-16). Any PC > 0x0F persisted (or was saved/recalled) as 15 (16). I found this to be consistent.

I have absolutely no doubt that there's a bug here but when I tried the test exactly as you described it works fine on my machine - coming back with 81 rather than 80.

The value is stored in an "invisible knob" as a floating point number so I suspect there might be some weird rounding error going on. Maybe your FPU gives a very slightly different result to mine. I can try coding it differently in the hope that a slightly different approach works but obviously won't be able to tell if it fixes the problem or not straight away.

One thing to help narrow things down - do you get the same problem if you put 81 in the LSB parameter instead of MSB?

I think the problem is almost certainly caused by a tiny rounding error in the floating point math and only shows on some CPU types which is why I can't reproduce it. I've made a small modification to the code that may fix this and I've submitted it for approval by CA.

I am curious as to how people with different chips on their PCs can get different results. One person has issues with bank switching. Someone else has issues program changes. Someone else evidently doesn't have either of these. Most peculiar!! Hope you can sort this out.

[ColinP]

Hi Steve,

Thanks for that. I think you've uncovered another bug. And one that's related to the MSB, LSB one.

MIDI Patch was I think my very first VM module and I obviously messed up a bit. It all seemed to work fine but I only use the module rarely to talk to my Yamaha RM1X so it's not been as exhaustively tested as it should have been. I'm grateful to Peter and you for finding these problems.

What I think has caused these problems is a setting in the Voltage Modular Designer dialogs for the invisible knobs.

The invisible knobs are used as a quick mechanism for achieving persistence and have the advantage that they can be easily inspected and manually edited during the development phase.

There's a setting for the number of discrete steps for these knobs that was inadvertently set to 16 for the Program Change one. So I think that's what's causing the problem you've found.

For the MSB and LSB knobs it's slightly different as the values range from -1 to 127. -1 being the off setting. Then 0 to 127 for the 128 other possible settings. So the number of discrete steps for these invisible knobs was set to 129.

But these discrete settings are actually redundant so I've now set them all to zero which means that the floating point values should be read and written without any math being applied to nudge them to the nearest discrete values.

Floating point numbers can represent integers up to a certain size perfectly but when some maths is done - say dividing by 129 and then multiplying by 129 the result can be a tiny amount out.

So in this instance rather than 81 we might end up with say 80.9999999999999.

My theory is that the code inside the knob methods that were adjusting the floating point value to 129 discrete steps were (perfectly reasonably) producing a number that was like this but that different FPUs might treat such close to integer numbers differently. I could be completely wrong but that's my working hypothesis to explain why I can't seem to reproduce the problem on my laptop.

Anyway, once the new build is published my theory will be tested and if I'm wrong then I'll rewrite the persistence mechanism.