I hope I’m not jumping the gun here, but I just installed the 2.1.2 update and now seem to be having an issue where everything works normally for a bit, and then eventually MIDI stops being received at the patch level. As in, the global MIDI monitor (from the ‘window’ menu) sees the appropriate MIDI signals, but a MIDI monitor hooked to an OMNI block inside a patch sees nothing. I’m not sure of the steps to reproduce this as it’s been seemingly random so far, but I’ll update if I figure out how to make it happen.
Is the OMNI block bypassed by any chance?
Sorry it’s taken me a while get back, I hadn’t seen the behavior again until just now.
No, it’s not bypassed. I bypassed and re-enabled to make sure. No difference.
Two questions.
-
Are you using scripting?
-
When this happens again, can you please open your options, switch to the Audio I/O section, and then just close the options dialog. Does it work now?
Hey David,
I haven’t tried the scripting function yet, but I’m looking forward to trying it out in the future.
I will give those steps a shot and let you know what I find out.
As always, thank you for the prompt support.
-M.
I was just trying to eliminate things.
Please let us know if/when this happens again and if it gets fixed by the steps above. This seems to be something VERY obscure but we’d still like to figure it out.
What audio driver are you using?
Okay, got a chance to test your prescription today, and sure enough it did fix the problem.
As for the audio driver, Core Audio if I understand correctly. The device I’m using is an aggregate device comprised of a Roland Octa-capture and two separate virtual audio pipes generated by Rogue Amoeba’s Loopback.
It seems that you can reliably reproduce this issue. We will need a bit of help figuring it out so so move faster - I will be contacting you directly.
Thanks.
I never ran into this issue on my main rig, a Windows box. I am responsible to maintain a MacBook rig for my church and this problem reared its ugly head over the weekend.
The laptop had version 2.0.18 installed. When I got it to work on the first thing I did was to install version 2.3.0. When I got to rehearsal it wasn’t playing any sounds. I found that I could play music using standalone versions of my instruments so I knew it was something with GP. I created a patch from scratch and it worked fine.
The problem comes when I close GP and come back to it – no sound. I debugged and found that no MIDI was being sent to the instrument plug. I put a MIDI Monitor in between the MIDI In and the instrument and there was no traffic. Meanwhile I opened a global MIDI Monitor window from inside GP and it showed all the traffic.
I ended up uninstalling GP and reinstalling version 2.0.18 and all is good again. I was just about to enter a bug in the tracker when I saw this thread.
Sounds like the audio engine died and there could be a number of reasons. Were you able to reliably reproduce this? In other words, if you quit Gig Performer and then opened it again, did it work? You kind of did that except you downgraded as well, so several variables changed at the same time.
Also, you can reset the audio engine simply by opening the options window, switch to the audio setup view and then just close the options.
Does that help?
Yes, easily reproducible with v2.3.0 (and possibly 2.1.2 based on the title of this thread):
- Start with a new gig and an empty rackspace
- Add an instrument and connect the OMNI In and the Audio Out
- Play something to confirm it works
- Export the rackspace, save the gig
- Close Gig Performer and reboot the MacBook
- Open the gig and/or import the rackspace
- Attempt to play and you’ll get no sound. The MIDI light in the upper right will light. Note appear in the global MIDI Monitor but they are not actually sent to the virtual instrument
Restarting GP did not help. Also, for me going into audio setup did not help – I did this several times while I was attempting to debug because at first I assumed it was the audio engine and had not yet observed the MIDI notes were not being passed. Possibly a separate issue or connected but in fact GP quit several times when I was in the audio options, especially when I tried to choose “None” for audio input. (I submitted a few crash reports and included my rackspace)
That was with v2.3.0. After many, many attempts to get things working I finally decided to downgrade to 2.0.18 and immediately the exact same rackspace and gig worked fine!
Ok, you added yet another wrinkle, importing rackspace. Let’s get back to basics. If you create a gig with a rackspace, and it works, and then you SAVE that gig, quit and then restart gigperformer with that SAME gig, does it work?
Root cause identified. I did what you asked and it worked fine. So then I decided to slowly reconstruct my patch that had failed so consistently. As I added effects to the audio chain the problem appeared when I added the TAL-Chorus-LX plug (v1.2.0).
There is some incompatibility between that version of the TAL plug, and GP versions 2.1.2 and greater, and my MacBook Pro (13-inch, Mid 2009) running El Capitan 10.11.6.
I installed the latest TAL-Chorus-LX plug and everything works fine. The TAL release notes say:
Version History
Backward compatibility to OSX 10.7, 10.8, 10.9 restored (v 1.3.1)
Possible AAX crash fixed (v 1.2.1)
Framework update. Fixes UI performance issues on some OSX hosts with VST (v1.2.0)
AAX Pro-Tools support. OSX 10.5 not supported anymore. (Version 1.03)
Bypass issue when loading plugin fixed. (Version 1.02)
Not sure if there is anything that concerns you about that, but now I am happy. My rackspaces tend to be complex and with that plug update I can run all my rackspaces with no problems.
One other piece of information, I didn’t catch it earlier, but my Windows rig runs TAL-Chorus-LX v1.2.1 so that could be the reason I never saw any problems on my Windows box but I did on the Mac.
Yeah, it’s really important to be very methodical when trying to track down a problem. Thanks so much for taking the time to track that issue down and I’m certainly glad it’s not a GP issue.