Quote:

All info has been sent to Peter & Andrew and we await their response.

It APPEARS that the other instruments are OK. What is needed is when a custom patch is used all of the CC & patch data is stripped out. What's happening now is the patch data is stripped but the MSB is not. The data for the GM instrument selected in the soloist is generated after the custom patch data so it resets the custom patch to a GM patch. That's why at this point set the soloist Inst. to "no change"


In case the PG group refers to this thread, I would make additional observations/suggestions (some of which I've communicated to Support in the past).

1. The "+" control is not synced with the spinners and does not reflect real time values of the cc 0 and 32 controllers after they have been saved with the song.

2. Make the GM settings for MSB and LSB configurable by user. (On my Kurzweil, the GM bank has MSB=0 and LSB=1.)

3. Re-examine each code module that can change a patch on any channel. Make sure the overrides and control hierarchy - style vs. song, etc. - are logical and simplify the interface to minimize user confusion as to just which element of the program will set the banks and patches for a given set of parameters and command sequence. Whenever a patch change is issued, by whatever element of the program, be sure the proper bank cc's are bundled with it (as appears to be the case in the latest version, at least for patches saved with the song.)

4. Reconsider UI design with respect to those new cc 0 and 32 spinners in the main window. Who chooses a HB patch by memorizing their patch map? Maybe Rain Man could, not this mere mortal. The interface ought to make it easy to use the patch map, not encourage even more mistaken assignments and consequent confusion. So I would suggest this: replace the spinners with a screen element that displays the the data in the "+" dialog. In real time. If some element of the program, even an embedded (F5) event, changes the patch, the display should reflect this.

I do appreciate the attempts made in the last couple of versions to improve HB implementation. I just think it should be examined more closely. My fantasy: Peter gathers his midi team. He says, "Look we've got a loyal sub group of users who go way back with midi. They think the RT stuff is cool, but they are also the ones who invested in expensive external hardware before virtual synth plugins were a gleam in Steinberg's eye. Heck, we sell such hardware ourselves (the Ketron). They run the gamut from desktop hobbyists to gigging professionals. They update frequently, but the frustrations with higher bank control continue. They shouldn't have to fire up the midi monitor all the time to determine the sequence of unexpected patch/bank changes and even then, not understand which features are firing them. They deserve a robust, reliable implementation, with clear, synchronized, realtime indicators in the interface. I commend your improvements in the last couple versions, but it needs more focus. So take a few weeks, redesign, get it right. Bounce it off the beta testers if you want."

Whew. I just did my morning exercise. Gotta relax on the treadmill. -Ron