Just got a Minimoog XL. I’ve discovered that if I create a sound using all three oscillators (i.e., the Osc 3 Hi/Lo is set to Hi) and save that patch, restoring that patch via a Midi Program Change causes the Osc 3 Hi/Lo to be reset to Lo. If I select the patch through the front panel, everything is recalled properly.
This is 100% reproducible.
I’m noticing a few other parameters are not recalled properly as well. Has anyone else seen this? It’s very frustrating.
Thanks
David
FYI — on a call with tech support this morning, I was no longer able to reproduce this issue (sigh)
So I’m not sure if it was a “glitch” that got fixed after I power cycled the Moog or there’s some funky other behavior going on but I now need to investigate further to convince myself that there’s a real problem here.
Hi David,
not here on my Voyager 
Yeah, I know — per my last comment, after power cycling the moog, it became 0% reproducible ---- I need to do some more experiments to determine whether it was just me!
Hi David,
please let us know when it happens again.
How did you change the programs (computer or master keyboard)?
Have fun,
Rudi
I have found out what’s happening. For some reason (unknown to me, and I’ve posted the question in the Apple discussion groups), whenever I change a a patch in MainStage, it sends out CC80 and CC81 to all external devices, both with 0 values. It turns out that CC80 with value 0 causes the Minimoog to set the HiLo frequency range for Oscillator 3 to Low. Consequently, any patch that I have on the minimoog that uses Osc 3 in audio range gets screwed up.
Hi David,
that’s normal. The Controller number 80 controls the HI/LO switch for the frequency of oscillator 3 and number 81 controls the ext input switch.
Sigh — I understand that the Moog responds to those parameters. This certainly explains WHY I was having a problem.
The point is that Apple MainStage should not be SENDING those values out in the first place.
I wasn’t aware those values were being sent out which is why it seemed to me that the minimoog was not handling the patch change properly (per my original posting).
Anyone else using Apple MainStage with a Minimoog Voyager is going to run into this problem (which is why I felt it was worth posting this report now that I’ve figured out what’s going on).
I suppose it would be nice if the Minimoog OS could be “improved” to allow for incoming MIDI filtering capabilities but this is really an Apple MainStage bug.
Maybe in a later update, I guess.
Have fun,
Rudi
If the Voyager get more and more possibilities like Midi filtering and the different local off parameters, we will see more people having problems with “defect” units that are just set up wrong in one of the menus.
It would be nice to have some kind of scrolling text on the LCD’s main page to show the status of such filtering and a partly local off setting.
Or a kind of status page showing settings that are active and limit the full functionality of the Voyager.
And adding a feature just to get a workaround for a buggy software is a bit too much.
Yes, as a longtime software developer, I understand deeply the dilemma here.
It’s not an issue when the software comes from a small/unknown entity. But when it’s coming from someone like Apple, you end up with a situation where the user (me in this case) was absolutely convinced the problem was with the Minimoog — it just seemed more likely that there was a bug in the Minimoog OS and that was a bit of a turnoff…indeed, I seriously considered returning it when I ran into the problem. There are lots of examples where applications add in extra code to deal with other systems that don’t behave themselves properly.
For myself, now that I know what’s wrong, I’m probably going to just build a Max/MSP patch that I will insert into the MIDI chain and use that to just block those CC80s, while passing everything else through. But it’s a nuisance to have to do that.