Jump to content

bayswater

Member
  • Posts

    41
  • Joined

  • Last visited

bayswater's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. My experience is that it runs very well. I tried it out in the Apple Store where they had a i5 version with 8G RAM. It was pretty goof. I got the i7 with 32G RAM, and it's great. I have a test project with 384 audio tracks, each with different audio, and a EQ in the first insert, and 128 VI tracks using 32 instances of Kontak, all playing scales on one of 4 patches. This takes up 60% of the CPU when everything is going. I guess if you have huge orchestral template with a zillion plugins, things might choke up, but then you ought to be using multiple CPUs. I've been using it for mixing in Mixbus 32C, 20 to 40 tracks and 8 busses, which is very CPU intensive and activity monitor barely moves. The one potential weakness of the 2018 Mini noted by some reviewers is the GPU which is not that great at stuff like 5K 60 Hz video editing. And you have to be careful with is the display profile in system preferences if you are using a non Apple display. Choosing the wrong profile give you slow screen updates. But for Logic, or any DAW, this is all irrelevant. If you do have to do the more demanding video editing you can always get a outboard GPU and run it off one of the TB3 ports.
  2. Interesting idea. DAWs generally let you choose an alternative audio editor. Being able to specific the EQ and Comp you want as defaults in the channel strip would be a good feature for any of them to add. Are there any that do this? DP lets you use any of several of their own EQs and provides the controls and graph in the channel strip, so making it somewhat generic is possible. You'd need some sort of mapping template to link the controls in the plugin to the standard display in the channel strip.
  3. Another thing to do it have Activity Monitor running along side Logic, and look at what it says is going on when you get overloads, dropouts, and so on. You might find some process not related to Logic causing temporary system overloads.
  4. The conflict usually noted for this Mini is between Wifi and USB3. This showed up for me with dropped Wifi, and external drives not mounting on startup, or unmounting without warning and issuing the usual warning about unplugging drives. Supposedly that is solved by using a 5G wifi signal. Along with moving USB3 devices away from the Mini itself, that solved it for me. Bluetooth problems were also solved by trying various placings of the devices involved. But I found that the older Bluetooth devices that came with a 2009 iMac are less likely to establish stable connections with the 2018 Mini than they did with the iMac. I borrowed newer versions and these seemed more stable. For a while I used only USB wired keyboards and mouse, and found the drop in latency when doing edits worth staying away from bluetooth altogether when using DAWs. It's difficult to say exactly how various devices should be positioned to get around these problems, but after some trial an error, my setup is very stable and reliable.
  5. So the increase in idle processor percentage and decrease in user percentage is irrelevant?
  6. I don't think it's worth the effort. This looped a passage that's about 15 seconds long and it ran for about 10 minutes. The load was even across that time. Sure, a more accurate test will narrow down the actual numbers, but it won't change the conclusion.
  7. Look at the charts I posted earlier. Those are shots taken while these projects were in playback. The exact ratio doesn't really matter. The first set showing 16 channels is clearly showing significantly less CPU consumption than the second set showing 1 channel.
  8. This must be what is happening assuming both LPX and AM monitors are accurate. The OS is clearly using 6 processors, and the load on them is more than the system or any other background processes would invoke. As for comparisons between two approaches, the projects used in my example are the same except in one case 16 instances of Q10 are all in one channel strip, and in the other they are in 16 sequentially chained channel strips. Otherwise they play the same sets of scales on a single instance of EXS24. I could take more precise measures as you suggest, but just from looking at the three summary AM measures (system, user, idle) you can see that the user load is about half or less using 16 channels compared to using one channel.
  9. I see what you mean. The LPX performance meter shows only one thread active. But I'm still not sure what I'm seeing because: 1. The Activity Monitor CPU meter shows activity on six processors while LPX shows one thread. 2. The level of activity on the LPX meter and the six AM meters are in concert: they all rise and fall at the same time 3. If I increase the note density on a range within the MIDI region, on the next pass, the LPX meter and all 6 AM meters show increasing activity at the same time 2 and 3 above imply to me that what the LPX meter is showing on one thread is the same activity being shown on 6 processors in AM. I tried another sequence that has 200 audio tracks, followed by 128 MIDI tracks playing 32 instances of Kontakt. In this case, LPX shows an even load across 12 threads, implying that hyperthreading is happening. But AM shows activity only on 6 processors wile the audio tracks are playing: no hyperthreading, but then shows hyperthreading when the MIDI tracks are playing. While the activity is shown as even distributed across 12 threads in LPX, it is not even across the 12 AM meters. Numbering the processors from top to bottom or left to right, it shows lower activity on even numbered processors, and higher activity on lower numbers processors. So what's going on here? It looks to me as if there is no one to one correspondence between the threads reported by LPX and the processors reported by AM, and that regardless of how LPX reports the way activity is spread across threads, the Mac, as reported by AM does not necessarily link one processor to one thread. Regardless of that, there is still the question of why the 16 channel version consumes less CPU overall than the 1 channel version. How can that be if both use only one processor? And regardless of the answer to that question, does it not imply that spreading a heavily populated channel strip across several Auxes is a possible way to improve processor efficiency?
  10. Dewdman, if you were addressing those last two posts to me, I have two comments: 1) it's pretty clear from watching the Activity Monitor that as the load increases in Logic, even on a one VI one track project, the pattern of that load shows on more than one processor. 2) One of the early posts was saying that a chain of plugins on a VI channel was using up a lot of CPU. I suggested that splitting the load over several channels might help. While the load is not necessarily being split over processors, the version of this project with 16 channels clearly uses less CPU than the version with one channel. It seems to me that regardless of the reason for this, it suggests an approch to deal with CPU overload. load.
  11. Not really. You can’t start the second plugin in the chain until the first plugin has finished its processing on the process block. Audio doesn’t stream through plugins like it does through guitar pedals. There is a process block of data and each plugin gets its turn to operate on the block of data. The second plugin in the chain needs to see the final results of the first plugin for that process block before it can do anything. in theory a daw could possibly break up process blocks into smaller chunks of time so that while plugin 2 is working on the results from plugin 1, another thread could start working on the next process block for plugin 1. But what if the plugin is time based in some way such that the results from plugin 2 need to be taken into account by plugin 1 in the next process block, etc. Fundamentally a plugin chain needs to happen serially because the actual computed results of each step along the way effect what the next plugin gets as input. There may be some advanced situations where a daw could do some smart stuff to parallelize more, but remember that all the plugins have a fairly simple callback interface with the daw. Generally it’s probably better for the daw to keep things simple. When you have more then a few channels playing back it’s all moot anyway as all cores will be working away. I thought about this and decided to try it out. I created a project wth one EXS24 track with KH Concert Strings 2 loaded, and then put 16 instance of Wavs Q10 in the insert slots. The track has a load of scales all superimposed on each other so there are a lot being played at any point. Let that play for a few minutes and got a screen shot of the CPU chart, shown here at One Channel. Then I changed the output from Stereo out to Bus 3 > Aux 1, changed the output of Aux 1 to Bus 4 > Aux 2, and so on until there were 15 Aux channels. I left one instance of Q10 in the Instrument tracks and move the other 15 instances to the 15 Aux tracks. So the plugins are in series. Played it and got another CPU chart shown as Sixteen Channels. You can see that going to more channels doesn't increase the number of threads, but even the one channel version was using 6 threads on a 6 processor i7. And the overall load is different across the processors, the variation in the load is the same, implying that the load from the EXS24 is spread across more than one processor. (When Logic is idle, nothing registers on these charts other than the occasional blip). The more interesting thing though, is that the 16 channel version clearly uses less CPU. One Channel Sixteen Channels
  12. I wasn't suggesting parallel processing. Just using auxes chained serially with one plugin on each channel.
  13. That is unlikely to ever change. You can't really parallelize a serial plugin chain. Perhaps you can spread the load over a chain of Aux channels. Maybe you could also spread the load over several instances of the VI? Each instance with a different note range.
×
×
  • Create New...