alexe

Whenever I try to use the keyboard shortcut Option-Enter to queue a cell, I get the error message "Command not available because the selected cells are muted.". But the selected cell(s) are not muted (see attached screenshot). When I select any of the cells shown in the screenshot and hit Option-Enter, the error message appears. What am I doing wrong?

Will do! But can by any chance explain what the expected behavior is regarding Live Loops quantization and the length of the regions within cells? I mean, I get that a cell doesn't have an inherent playback length, but if the Quantize Start value is set to any multiple of bars, e.g. 2 bars, and a cell contains a region that is just under 4 bars long, isn't Logic smart enough to know that when the playback of that cell repeats, the region is obviously supposed to start playing back on the beat? In other words, is it required that I make sure that all regions in cells have the proper length (e.g. exactly 2, 3, 4, etc. bars) in order for the cells to loop in a rhythmically meaningful way? If the quantization is set to e.g. 4 bars, I thought it would make sense that Logic treats a region that is 3.8 bars long as a 4-bar region, or a region that is 4.1 bars long as a 5-bar region, such that things stay in sync as the cells loop. But that doesn't seem to be the case. Or can I configure that somehow?

I have a simple Live Loops grid with a few software instrument cells that contain 4-bar regions and one audio cell. The audio cell contains an audio region that is slightly less than 4 bars long. Now if I play back all of these cells with the cycle range set to 4 bars, all the software instrument cells play back fine, but the audio cell is only in sync with the other cells for the very first play back. After that, the more often it repeats, the more out of sync it gets with the other cells. I'm confused for multiple reasons: 1. Even if the audio region has an "odd" length, meaning it doesn't divide the cycle range, shouldn't it always stay in sync on repetitions, just as it would if the simply looped the same regions over 4 bars in the Tracks area instead? 2. Since the audio region being slightly shorter than 4 bars was my only guess for why that cell might get out of sync with the others on repeated playback, I selected that cell and extended the audio region to a full 4 bars in the Track editor at the bottom. This, however, did not solve the issue. The cell still gets out of sync from the others. I appreciate any suggestions regarding what the problem might be. Also happy to provide more information if needed.

Ah, if I select only all the individual tracks and export those (i.e. omit any summing tracks), then the delay and reveb aux tracks export correctly (i.e. only contain the signals they are supposed to contain). It's still weird why this doesn't work if I export the summing tracks as well.

I'm experiencing a weird issue: I have a project with a number of summing tracks and would like to export all of the tracks. I also have a number of auxiliary channels for reverbs and delays for which I created tracks with empt MIDI regions spanning the entire tracks such that I can export these effects as well, nicely separated from the dry tracks. I used the method to select all tracks in the project and then export "X Tracks as Audio Files", not "All Tracks as Audio Files". The individual exported tracks are all as expected, but some of the summing and aux track exports are corrupted: They contain signals of tracks that don't even feed into them, and there are strange timing issues. For example, I have a summing track for all drums (bus 1) and one for all vocals (bus 2). The summing track export for the drums is fine: It contains a sum of all the drums and nothing else, as expected. The summing track export for the vocals, however, is corrupted: It contains both the vocals and the drums, and the vocal are too slow, as if they had been slightly time-stretched. The reverb and delay tracks are corrupted as well: I have three delay aux tracks, and even though ONLY the vocal tracks send to these delays, the exported delay tracks weirdly contain the drum signal as well. Same withe a vocal hall aux track: Only the vocal tracks send to it, but it contains the drum signal as well. Has anybody experienced something like this before and knows a fix? Some more routing details: The drums and vocals send to strictly separate aux busses. That is, the drums only send to auxes to which the vocals don't send and the other way around. There is no aux bus to which both the drums and the vocals send. I double-checked that all the individual drum tracks output to bus 1, which is the input of the drum summing track. I double-checked that all the individual vocal tracks output to bus 2, which is the input of the vocal summing track. The vocal summing stack contains a few sub-summing stacks, so there are three hierarchy levels for the vocals. Only the top-level summing track export is corrupted, the second-level summing track exports are fine, as are the individual track exports. Any ideas? Thanks a lot!

Ah, that's interesting to know! I don't have an idea of what might cause this behavior, but please do report it to Apple as a bug via their feedback form. While it is super annoying that the project sample rate apparently changes under certain circumstances that aren't obvious to the user, this would be half as bad if it didn't mess up the take folder region positions. If the take folders were still intact, then it would still be annoying, but at least then you could just switch the sample rate back to what it's supposed to be and all would be good. But the fact that the take folders get messed up by the sample rate switch is definitely a bug, and a critical one because it destroys the project integrity in a way that is not possible to undo.

I'm looking for a way to store finished projects in a way that is least dependent on specific versions of third-party plugins being present on my system. Everybody probably has experienced the typical scenario where you're trying to open a 5-year old project and some of the plugins or the particular versions of them used are no longer available or functional on your system, maybe because you upgraded your system in the meantime and those plugins are no longer compatible with your system. I want to be able to still open and play back a project in such a case with everything sounding as it is supposed to. The best way I can think of doing this is by simply freezing all tracks. Is this a good idea or are there any downsides to this? Instead of freezing, I could bounce all tracks in place, deactivate all of their effects, and even export all the aux tracks. But freezing seems nice because I can always easily unfreeze a track if this particular track's plugins ARE all still functional. An open question would also be: If I unfreeze a track that has a plugin on it that no longer works/exists, can I refreeze it (by Logic just re-using the previous frozen audio file) or is that not possible? If freezing is not a good idea, what are best practices for conserving projects for the long term?

Amazing, thank you 🙏

When you open a Logic project that has multiple project alternatives, Logic always opens the alternative that was last open (or saved, I don't know which of the two it is). Is there a way to make Logic ask which alternative I want to load when I open a project? It takes long enough to load big projects as it is, so it's cumbersome if you need to wait for the wrong project alternative to fully load, only to then select the project alternative you actually want and wait for the whole loading process again.

No suggestions? 🙂

The reboot did it. ...LOL Alright, I'll keep that in mind for next time. Trashing the cache manually would probably also have done the trick (I guess that's the only thing the reboot did that made a difference in this case?).

Thanks for the help, guys! The two plugins in question are Wide Blue Sound Silencer and DMG Audio PitchFunk. I removed them from /Library/Audio/Plug-ins/Components and just to be sure, I also checked ~/Library/Audio/Plug-ins/Components (I had that case once). Once the .component package is gone from those places, shouldn't that be enough?

I removed a few plugins, but on the next launch Logic complained that the validation for one of those uninstalled plugins failed and the Plugin Manager shows the plugin as "couldn't be opened". I then ran a "Full Audio Unit Reset", but that didn't solve the problem either. It made it worse, actually 😂: On the next relaunch, Logic now complains that the validation failed for 2 of the uninstalled plugins and now the Plugin Manager shows both of them as "couldn't be opened". That "Remove" entry from the context menu in the Plugin Manager looks like it would be what I'm looking for, but it is somehow always greyed out. What can I do?

I'm having the same problem: Low-latency mode disables any channels that receive side-chain input, regardless of whether or not the plugins on the affected channels induce any latency. I'm experiencing this problem in a situation where none of the plugins involved induce any latency at all, and still Logic disables the respective channels in low-latency mode. If you're using MIDI-controlled effects (see screenshot), you're losing the entire channel output in low-latency mode, which is extremely annoying. As you can see in the screenshot, I'm using Bass XXL (like RBass, just better) on my bass line, where the focus frequency is controlled by the MIDI track and the actual audio from the bass track comes in via side-chain. And of course the output of the bass track is consequently turned off. Now when I turn on LLM, I'm suddenly left without any bass. So it's basically impossible to use MIDI-controlled effects and keep them playing in LLM, even if the plugins involved induce no latency at all. Is there anything I can do about this? Why is it this way?

Yeah probably better to have distinct visual indicators for routing-induced solo-safing and manually set solo-safing. I'm sure Apple's UX designers could come up with something reasonable if they tried 😄