A new build (#18) of the MIDI Patch module should now be available.
Hopefully this fixes the problems discussed here - viewtopic.php?f=36&t=2058 but please let me know if there are still any issues.
MIDI Patch update
Re: MIDI Patch update
Thanks for the fix!!!! I just saw this as I was shutting down for the night and used several of my external gear test patches. So I did a quick (< 15 minute) test. What worked for me before still works (CH/MSB/LSB) and now PC successfully saves/restores values from 0 to 127. I tweaked/added some VM MIDI Patch module variations as well as internal module presets. So far as I can tell, it fixes the issues I had and works quite nicely. Again, thanks!!
Re: MIDI Patch update
Sorry Colin but still not fixed. This is NOT a floating point what's it - it has everything to do with the changes by arrow.
In this 1920's silent movie, I will explain what is going on.
See if you can recreate...
1) Instantiate a new MIDI Patch (version # 18)
2) Change the two "OFF's" to 80 80 by direct entry
3) Save as preset "80 80"
4) Repeat above and directly enter 81 81
5) Save as Preset "81 81"
******* Important step
6) Change 81 81 to 80 80 by clicking on DOWN arrow
7) It now shows 80 80 and save the preset as "New 80 80"
8) Remove MIDI Patch (to eliminate any other factors)
9) Instantiate a new MIDI Patch
10) Load Preset "New 80 80" and it comes in as "81 81"
************************
Now what I haven't shown in this gripping drama is that the original presets "80 80" and "81 81" are saved OK and come in when reloaded.
Also not shown but in the directors cut..
If you repeat step 6) and also using the up arrow, change the program number to 2 and save as "New 80 80 2"
Upon recall you will notice that the "81 81" goes back to "80 80" as above (10) however the program Number HAS been saved by using the arrow keys.
Hope this long explanation helps Colin.
Cheers Peter
In this 1920's silent movie, I will explain what is going on.
See if you can recreate...
1) Instantiate a new MIDI Patch (version # 18)
2) Change the two "OFF's" to 80 80 by direct entry
3) Save as preset "80 80"
4) Repeat above and directly enter 81 81
5) Save as Preset "81 81"
******* Important step
6) Change 81 81 to 80 80 by clicking on DOWN arrow
7) It now shows 80 80 and save the preset as "New 80 80"
8) Remove MIDI Patch (to eliminate any other factors)
9) Instantiate a new MIDI Patch
10) Load Preset "New 80 80" and it comes in as "81 81"
************************
- MidiPatch1.gif (1.39 MiB) Viewed 1830 times
Also not shown but in the directors cut..
If you repeat step 6) and also using the up arrow, change the program number to 2 and save as "New 80 80 2"
Upon recall you will notice that the "81 81" goes back to "80 80" as above (10) however the program Number HAS been saved by using the arrow keys.
Hope this long explanation helps Colin.
Cheers Peter
Re: MIDI Patch update
Thanks for the feedback on the Program Change fix Steve.
And thanks for your very patient explanations Peter. Love the 1920's GIF animations by the way - what tool are you using to create these?
Anyway the good news is that after very carefully following your instructions I have finally been able to reproduce the problem. It's not obvious from the code what's causing it but now I can reproduce it, I should be able to fix it.
It seems what you call the "direct entry" method is not meshing properly with the up and down (with shift key acceleration) method. I wasn't happy with the way the "direct entry" method worked anyway as I couldn't get full control of focus. That's why it's an undocumented feature. But nonetheless it ought to work even though it's slightly inelegant (requiring the extra mouse click).
I'll post an update as soon as I've had time to track down this pesky bug.
And thanks for your very patient explanations Peter. Love the 1920's GIF animations by the way - what tool are you using to create these?
Anyway the good news is that after very carefully following your instructions I have finally been able to reproduce the problem. It's not obvious from the code what's causing it but now I can reproduce it, I should be able to fix it.
It seems what you call the "direct entry" method is not meshing properly with the up and down (with shift key acceleration) method. I wasn't happy with the way the "direct entry" method worked anyway as I couldn't get full control of focus. That's why it's an undocumented feature. But nonetheless it ought to work even though it's slightly inelegant (requiring the extra mouse click).
I'll post an update as soon as I've had time to track down this pesky bug.
Re: MIDI Patch update
Interesting. I used the up/down buttons, not the direct entry method. I also started with variations before trying the module presets. I will have to try those methods, too. Thanks for the silent movie.
Re: MIDI Patch update
Thanks guys I await the Oscar in the mail...
The program I use is Licecap - brilliant if you have head lice.
Only windows. You can resize the capture window to just encompass what you need to show and cut down on file size.
You can download here https://licecap.en.softonic.com/
Cheers Peter
The program I use is Licecap - brilliant if you have head lice.
Only windows. You can resize the capture window to just encompass what you need to show and cut down on file size.
You can download here https://licecap.en.softonic.com/
Cheers Peter
Re: MIDI Patch update
Hi Peter,
Thanks for the info on LICEcap. A very unfortunate name but a nice little utility to have in the tool bag.
Also just to let you know, I've not given up on trying to fix the bug. I've just been busy with other things lately.
I've found that as well as the bug only happening in very limited circumstances it also only occurs the first time the preset is loaded. Load the preset again and the problem goes away. Very peculiar behaviour but perhaps a clue for me to follow.
Thanks for the info on LICEcap. A very unfortunate name but a nice little utility to have in the tool bag.
Also just to let you know, I've not given up on trying to fix the bug. I've just been busy with other things lately.
I've found that as well as the bug only happening in very limited circumstances it also only occurs the first time the preset is loaded. Load the preset again and the problem goes away. Very peculiar behaviour but perhaps a clue for me to follow.
Re: MIDI Patch update
I've finally discovered that the problem was caused by VM sending an unexpected Label_Changed event when a preset is first loaded. This made my code think that the user had re-entered the old data value again.
The same problem was present in MIDI Patch, MIDI Compensator and MIDI Drum Kit.
I've changed the code to ignore the Label_Changed event altogether so it now takes an extra return press to get out of the direct entry edit field. It's not perfect and at some point I might write my own data entry code to improve the UI behaviour but at least the mod fixes the main problem.
I've submitted new builds of the three modules and hopefully they'll be approved fairly quickly.
The same problem was present in MIDI Patch, MIDI Compensator and MIDI Drum Kit.
I've changed the code to ignore the Label_Changed event altogether so it now takes an extra return press to get out of the direct entry edit field. It's not perfect and at some point I might write my own data entry code to improve the UI behaviour but at least the mod fixes the main problem.
I've submitted new builds of the three modules and hopefully they'll be approved fairly quickly.
Re: MIDI Patch update
Thanks Colin,
I read your penultimate email last night and thought WHAT? that is bizarre.
So this morning I retested and indeed what you said was correct.
I retested and it is only on the middle two numbers that things go awry. It is only when I manually enter the numbers that it remembers and forgets the arrow numbers.
e.g. manually entered 1 1 1 1 save then arrow up 2 2 2 2 save. close. load 2 2 2 2 it comes in 2 1 1 2.
Then I went in to post this and see that you have found a fix - that is great well done.
The only thing I cannot get my brain around is why is the code different in positions 1 and 4 to positions 2 and 3 ?
Cheers Peter
I read your penultimate email last night and thought WHAT? that is bizarre.
So this morning I retested and indeed what you said was correct.
I retested and it is only on the middle two numbers that things go awry. It is only when I manually enter the numbers that it remembers and forgets the arrow numbers.
e.g. manually entered 1 1 1 1 save then arrow up 2 2 2 2 save. close. load 2 2 2 2 it comes in 2 1 1 2.
Then I went in to post this and see that you have found a fix - that is great well done.
The only thing I cannot get my brain around is why is the code different in positions 1 and 4 to positions 2 and 3 ?
Cheers Peter
Re: MIDI Patch update
Hi Peter,
Yeah it struck me as slightly bizarre behaviour but on reflection it makes sense as the widget I'm using for the text entry is I think intended as a permanent part of a module rather than just a data entry mechanism. So the preset load restores the data in the widget and sends an event to indicate the fact. I just didn't anticipate this and it was difficult to track down as the problem can't be created inside the debugger.
In an ideal world the digital counter would have an Edit Value functionality built in (similar to how the VM knobs work) but alas not. So my effort to implement data entry was a bit of an after thought. And it doesn't work very elegantly either. That's why I left it as an undocumented feature as it is reasonably easy to enter a value using the up and down arrows with the shift key as an accelerator. I also found that in practice the main thing I did was increment values searching for particular sounds rather than know in advance what I wanted.
On your 2 2 2 2 behaviour observation the Channel setting doesn't have a text entry facility (as it's only got 16 states) so that's why the problem didn't arise there and I suspect that because the Program setting defaults to 1 you didn't actually use the text entry facility on that.
So perhaps only the MSB and LSB settings would have been changed to arrive at the 1 1 1 1 state. Then when you incremented everything to 2, saved and reloaded then only the MSB and LSB setting would have gone back to their old values - resulting in 2 1 1 2.
Anyway the problem is fixed now although not particularly elegantly. I'll post here again when the three modules involved are approved.
Thanks for your valuable feedback and patience. It's been a rather subtle bug to fix. Hey, who knows, you may discover it's not really fixed!
Yeah it struck me as slightly bizarre behaviour but on reflection it makes sense as the widget I'm using for the text entry is I think intended as a permanent part of a module rather than just a data entry mechanism. So the preset load restores the data in the widget and sends an event to indicate the fact. I just didn't anticipate this and it was difficult to track down as the problem can't be created inside the debugger.
In an ideal world the digital counter would have an Edit Value functionality built in (similar to how the VM knobs work) but alas not. So my effort to implement data entry was a bit of an after thought. And it doesn't work very elegantly either. That's why I left it as an undocumented feature as it is reasonably easy to enter a value using the up and down arrows with the shift key as an accelerator. I also found that in practice the main thing I did was increment values searching for particular sounds rather than know in advance what I wanted.
On your 2 2 2 2 behaviour observation the Channel setting doesn't have a text entry facility (as it's only got 16 states) so that's why the problem didn't arise there and I suspect that because the Program setting defaults to 1 you didn't actually use the text entry facility on that.
So perhaps only the MSB and LSB settings would have been changed to arrive at the 1 1 1 1 state. Then when you incremented everything to 2, saved and reloaded then only the MSB and LSB setting would have gone back to their old values - resulting in 2 1 1 2.
Anyway the problem is fixed now although not particularly elegantly. I'll post here again when the three modules involved are approved.
Thanks for your valuable feedback and patience. It's been a rather subtle bug to fix. Hey, who knows, you may discover it's not really fixed!