BenLounsbury

Hey - Just to provide a specific answer for this issue you're having outside of "resetting all preferences" ANSWER/FIX: The audio drops when the track you're currently on is not record enabled. Reason being I would assume it takes the CPU a second to process the request and then continue with the desire to record. So, just make sure your track (or tracks) are all record enabled (flashing red, not standby-record where it's inverted/dark and ready if you want to record on a selected track but will still take a second to enable once you initiate "R", hence the audio "mute") - when record enabled you will be able to play and hit "R" whenever you want and it will begin printing new content. Hope that helps!

The Issue unfortunately has not been fixed with the latest update. Still shifts audio and bus routing all over the place at random when unpacking track takes and deleting un-wanted excess audio tracks, then creating new ones as your production or mix grows. So aggravating.

CaBuffalo, I'm not sure what the cause may be, but there is somewhat of a workaround / solution to resolve this bug, at least temporarily. This has just happened to my editing session and the selection based processing has auto-taken over my bus 1 send, and i only realized it when i went to create my first bus group and saw bus 1 labelled "selection based processing A". Somehow the selection based processing A channel has created bus 1 as it's input source, and is a solo safe channel, hence you having trouble with your soloing issues. To get rid of this, open up your midi environment window (Command 8) and find the 2 channels that have been created (Selection based processing A & Selection based processing B) and delete those channels, OR re-address their input source to something other than bus 1 (for A). I just deleted those 2 extra channels because i wasn't using any buses to begin with, and selection based processing shouldn't hold a bus input anyway is it is a temporary audio suite - like momentary audio editing tool, but i can see it being a little more complicated if i've had a session built up already with specific bussing and routing going on, and i would want to make sure that my bus 1 channel is still the right one as far as the inserts i had allocated to it... at that point i would just select no input on the selection based processing channels within the MIDI Environment window. Hope that helps!

Barefoot, I too have been editing/comping vocals in sessions this week and have encountered the issue in 2 of the 3 sessions so far. It's the unpacking of the take folders and then removing one of the audio channels that tends to randomly throw it out. The undo function does not contribute to the onset of this glitch/bug, it seems to intermittently glitch when removing an audio track, then creating another one (most commonly when unpacking take folders, then removing one or more tracks from those performances). The undo function cannot fix the issue either by just going back until before that damaging move was made, seems to not be useful in these cases. To 'question' - Yes, once a session is corrupted (in your case a template), that issue/bug will be present in all additional projects initiated from that template. However, a new session seems to start clean, and allow you to continue on without the bug (at least until it may or may not happen again). Which is why I mentioned that the only temporary solution for me is to start another fresh session, then import all of my 'bugged' session's channels and I/O and sends etc, then make sure everything is sending where it aught to be, and then continue working from there and the issue is no longer initially present. Unfortunately, a film with 50 projects seems to be a massive and scary headache trying to resolve by creating 50 new sessions and hoping all your imports go without a hiccup :/.... Hopefully there's a solution soon, cause this has really messed up some large mixing sessions i've had in the past, and the temporary resolutions are sometimes daunting and take so much unavailable time :/

My Name is Ben Lounsbury and I am having this issue as well, and have been encountering it at random for about 2-3 years now. My main cause that I have seemed to widdle down to over the years is: un-packing take folders (Let's say audio 1-5 [5 takes]), then removing one or two of the takes (lets say audio 2 & audio 4), then continuing on as usual using the 3 remaining takes as some form of a unison sound etc. Then, as I create new inst tracks, and new bus sends, then ultimately new AUDIO tracks, the creation of new audio tracks (in affected/bugged sessions) starts to push everything out of order when it reaches the CURRENT audio track that's next to use. So, sometimes the issue has already taken place long before you actually realize and are able to see/notice its' effects. So in this scenario when I initially recorded 5 audio takes into a take folder, then unpacked them & deleted audio 2 and audio 4 cause they were not the hottest takes, normally the next audio channel created would be audio 6 (after the 5 takes), but somewhere when Logic updated to their dynamic channel assignments (ever moving reserved audio 3 for preview channel, and inst 2 for click channel) to save space as it takes over any unused audio before it continues on with 'audio 6', the bug was born. So when you create another audio track it would be audio 2 first (the one you already deleted) and the next would create audio 4 (also already deleted) and your problem wouldn't surface just yet. Then, when you finally create your next track, that third track will be audio 6... at that point it shifts EVERYTHING out (Busses, Aux sends, Inst channels [including the dynamic re-assigning Click channel]), and you lose the ability to hear click, and all of your bus sends are now sending to the wrong effect strips and everything is out of whack and cannot be un-done except by creating a new un-bugged session and moving everything you can from your corrupted session to the new one, and the bug in the dynamic track assigning will be no more.... of course, until it randomly happens again :/. The environment window holds the details of the bug somewhere as the preview channel (for apple loop referencing in a project) is defaulted to a reserved audio 3 channel, until you start creating audio channels, then it should dynamically move three audio track numbers ahead of your current audio tracks created. The click channel, which defaults at inst 2 and dynamically moves appropriately to its one-slot-ahead reserved inst channel whenever you create new inst channels (e.g. if you have 3 active inst channels the click will be on reserved inst 4. if you have 5 active inst channels, the click will be on reserved inst 6, and so on...). The biggest issue with this is that it is Intermittent, and not caused by some mis-command, or improper use unfortunately. Trying to re-create the issue, I am probably successful once out of every 5-10 times, doing the same thing to cause it every time (unpacking take folders, then removing an audio channel, then creating [or importing] another audio channel, then working the audio track numbers up until the tipping point and throwing everything out). I currently have a case open with apple support regarding this, and their technicians and coders are even having difficulty identifying the origin of the bug. So I am in the process of remotely recording some sessions with them that include the issue so they can analyze it and hopefully find a solution for a future update.