CHKComposer

Thanks! I searched here, but didn't use the right terms for that discussion to come up I guess. However, still the description in the notes for 10.7.8 update is incorrect. I have to hit "Shift-Option" to override the "new" behavior for scaling a range of automation points by dragging in the background of the automation display. While hitting only the option key while dragging does override the behavior when using the numerical display in the track header to adjust.

Welp. Of course now when I look, I see this note in the release notes for 10.7.8 (However, I find on my system I need to press "Shift-Option" to override this feature in the Automation/MIDI area of piano roll or in a track showing the automation curve, holding just the option key seems to prevent any scaling from happening. And to make things more confusing, holding only Option over the numerical number in the Track Header does override the the behavior):

Well...I thought I had. But I just went through everything. Shift-Option while dragging seems to do the trick! Thank you! Any idea why this changed? I'm using the same key command set on my new and old machine. I don't see anything documented where this was changed at some point. I'd prefer it to just always work this way (without any additional keys pressed), but thankful your post allowed me to discover the key command that allows it. Thank you!

Ok...I booted up my old iMac which still has 10.6.2 on it. Created a project and a track and created automation with -∞ and "0" values. It scales just as it should. Somehow this is something now happening on my current system with 10.7.8 🤷🏻‍♂️

To scale automation I've always just simply just selected the automation I want to scale and clicked some where in the background of the Automation/MIDI area of the piano roll (or in the track when showing automation curves) and moved my mouse up or down to scale. A few months ago I noticed I can not scale down if the automation selected contains a "-∞" or "0" value. The same seems to be true the opposite way (can not scale up) if there is a +6dB or 127 value. Am I crazy? or was this always the case? It can't have been. Is this a bug? Some preference I inadvertently selected? I've looked and can't find anything. I've finally gotten annoyed enough to ask here. Thanks!

This is an old post and I do think it was a bug that has been resolved. Or some weird quirk that was happening and for some reason is no longer happening for me. (Corrupted preference file or something.) The point isn't copying audio files from a template into a new project. The point is, for example, if you have a library of loops, hits, FX, whatever on a hard drive. And you import them into a project. You want it to copy that as a new file into the project. If you edit or process the audio it only effects that copy. Not the one in the library folder. There was definitely a time, when I wrote the original post, that it wasn't behaving this way. If you saved the template with "Copy Audio Files Into Project" checked. And created a project with that template. Saved as a new project. That preference would not be checked. I know because at one point I noticed editing the audio files I had imported, destructively edited the files from the original folder, because they weren't duplicates in the new project folder. This is when I wrote the original post. After troubleshooting and realizing that new projects created by a template that had that preference checked, did not actually copy files into the new audio folder. However, it is now a moot point, because it seems to be working fine now for me.

Did you notice this only after updating to macOS 12.4? I'm trying to determine if that is the cause.

Literally any time you chop or copy an audio region and move, and then undo. It seems to happen only in large templates when several Kontakt instances or loaded. And as Ozinga points out it gets worse and worse as you add tracks with Kontakt on them. So to try and reproduce I would say build a large template at least 20 tracks running with Kontakt instruments loaded. Create an audio track. And then copy and paste it and undo. See if it undos immediately, or if it drags, goes to rainbow wheel for a few seconds or more. It may be an issue only with M1, Monterey 12.4 and Logic 10.7.4. (And Kontakt)

I keep getting a rainbow wheel that lasts anywhere between 5-30 seconds when I do certain undos. Occasionally it causes a permanent freeze and after several minutes I force quit. Mainly if I copy or move an audio or Midi region to a new spot and undo. It will undo automation steps, erasing midi notes, adjust midi note time, velocities, etc with no problem. I think it might be related to Kontakt. And the larger the template the more prevalent the problem. I recently updated to Monterey 12.4 and wonder if this could have triggered the problem. I've tried everything to fix it. Including deleting preferences in Logic and Kontakt. Deleting the database in Kontakt. Older projects that I know opened up and worked fine, will now have this problem. I am on an M1 MacStudio Ultra with 128GB ram. So I wonder if it might be only a problem with M1, Logic 10.7.4 and macOS 12.4. Anyone else with an M1 running Logic 10.7.4 have this problem? I am running Logic in native (not Rosetta), and it happens in sessions with all native/universal plug ins. I have started up in rosetta mode and the same thing happens. Thx

I just noticed that if I create a session and save as a template it will not save the preference to "Copy Audio Files Into Project" in Project settings. The workaround is to use "save as" and save the project in the user Project Template folder. That works. But this setting should be saved when using "save as template" as well. I don't think this used to happen. Been awhile since I've created a new template. So curious to know if others notice this same thing on their rig.

Here is what I have found out. After spending a little time experimenting. I don't know if it's Logic 10.7.4 or if it is the M1, or Apple Silicon native plug-ins --But if I create a session with several (lets say 30) Kontakt and/or Spitfire Audio plug-ins. And load large libraries. The larger the libraries and the more instances the longer it takes for the main session screen to appear and open after the progress bar disappears. Obviously the more plug-ins you have in a session and the more samples that need to load will require longer load time. Even with SSD or NNMe. I'm used to large orchestral templates taking a long time to load. The problem seems to be that, at least in my experience prior to 10.7.4 on my intel machine, the session usually popped up on screen pretty soon after the progress bar and "loading" completed. My test with 30 plug ins loading several Spitfire, HZ Strings, 8Dio Anthology Strings and various other libraries took 46 seconds to load after the progress bar disappeared. It feels like logic has frozen or crashed. Because the only thing that shows is your desktop albeit with the Logic Pro menu bar. Perhaps in previous versions the samples loaded in the background after the main session window appeared? Or the progress bar continued to run while they were loading. Not sure but this did not happen when I was using 10.6.3. I don't think its taking longer to load than usual. I think its just a matter of what we're seeing on the screen while loading. It would be helpful if the progress bar continued to run while samples loaded.

Thanks for the reply. Only using Apple Silicon native plug-ins. I will try to narrow down what third party plug ins could be causing this. I created project using a similar number of only Apple-Logic Plug ins and it opened very quickly with no pause after progress bar goes away. So it does seem to be a third party plug in problem. However, this was not this way in 10.6.3 for me. So maybe some combo of third-party/Apple Silicon causing this. Even when not running rosetta plug ins.

I recently upgraded to 10.7.4 on a new M1 rig. So I don't know if this is an Apple Silicon thing or a 10.7.4 thing. But since upgrading I have noticed the session loading progress bar is less "accurate" than it was in 10.6.3. It is inconsistent in its reporting of what is loading and it jumps around. And more annoyingly, after it goes away it can take anywhere between 5 and 20 seconds for session screen to pop up and become active. It feels like system has crashed. But it just needs a few more seconds to load. Is this what everyone is experiencing with 10.7.4? If so, they really need to fix it. With previous versions, the progress bar moved fairly consistently towards the end with plug-ins listed below as they loaded and when finished session would pop up within a few seconds.

FYI This bug remains in 10.7.4. I re-sent bug report to Apple.

Thanks for the reply. After experimenting a bit I've narrowed the problem down to iZotope Ozone 9. I put just a touch of mastering on each stem (10 tracks). If I take Ozone off the channel strip it takes about one min 15 sec to export 11 tracks (Stems plus Mix) that are about 2 minutes long. With Ozone on channel strip it takes about 3 min 15 sec for the same export. (Nearly 3 times longer export time!) Ozone is Apple Silicon native, and it has always been a CPU hog. I was hoping that would change a bit with AS version. I experimented with replacing Ozone with the stock Logic plug-ins and other third party mastering plug-ins (a channel strip consisting of EQ, Comp, Exciter, Imager, and Limiter on each stem) and there wasn't sizable difference between no plug-ins on stems, and the non-ozone plug ins. There was also a negligible difference when I swapped out softsynths that require little disk activity and Kontakt. So it seems that Ozone is the main offender here. I do prefer the sound of Ozone over other options, so maybe that's just the trade off I have to deal with for now.