Track selection freezes reaper for up to 2mins

[srdmusic]

I have been experiencing a significant lag with the GUI, specifically track selection.

I'm not a programer but this feels very similar to problems I've had in other programs with memory leaks.

The symptoms are that when I have a session open for more than 15 mins track selection becomes very laggy. The lag is not quite a bad when I first open Reaper. Sometimes it takes 1-2 seconds before I can select a track. If I select multiple tracks sometimes Reaper with become unresponsive for up to 2 mins before it selects that track. This is not a problem I had in Reaper 5.5 and below. During my test I was only selecting tracks and moving tracks around. I did not have any instruments online and no audio in the session. Waiting for reaper to selected a track for 2 mins while it basically crashes is making it very difficult to work.

I have tested this with my 900 track session and then tested with a session that was only 500 tracks. I realize Reaper was not optimized for super high track counts but my monster machine was able to handle track counts of 1500 with lots of instruments and audio in 5.5.

I've confirmed that I can still reproduce the lag with No FX windows, mixer or the FX Browser. Just the main window is open. I have also tested with all my custom scripts turned off. It's just the main TCP window.

I previously posted about this problem a few versions back:
https://forum.cockos.com/showthread.php?t=207963

And a fellow composer friend of mine posted a similar issue:
https://forum.cockos.com/showthread....ght=4000+track

The forum peeps suggested that it was because of my high track count and that may be true but it doesn't explain the difference in functionally in version 5.5.

The other suggestion was that I only keep the tracks I need visible, but even with just 10 tracks visible in the TCP the GUI for tracks selection lags.

The last suggestion we got was that it might be related to the tracks having auto arm turned on and anticipatory fx for selected tracks turned on. I've since converted all my tracks to no record arm on and tried to turn off anticipatory fx. The problem still persists.

I know that Justin did a few modifications to way the audio engine works and I believe he also updated the type of compiler the program runs on. Is there a version I can test without those two modifications so see if it solves the problem.

I have a fairly expensive Nvidia Quadro M4000 video card but is it possible that mine is just not playing well with Reaper? Is there an API alternative that might be better?

Here are my machine specs:


Reaper 5.95 pre 6
Windows 10 version 1803

Intel Dual 24 core (48 core hyperthreaded) 3.2GHz
128 GB of Ram
14x500GB SSD drives raid 0 split for samples projects and system
Nvidia Quadro M4000 4x4k

[Klangfarben]

Is it also happening in a portable Reaper install? Also as a test, could you load minimal scripts to make sure there aren't multiple scripts not playing nice?

Although the issue is not happening for you in version 5.5, that doesn't necessarily mean something broke on the Reaper side.

[srdmusic]

Originally Posted by Klangfarben

Is it also happening in a portable Reaper install? Also as a test, could you load minimal scripts to make sure there aren't multiple scripts not playing nice?

Although the issue is not happening for you in version 5.5, that doesn't necessarily mean something broke on the Reaper side.

Hi Klangfarben! Nice to see you on the forums. You're totally right that it could be some preference I've changed since 5.5. Yeah, I'm testing it with portable and normal install. Doesn't seem to make a difference. I've also tested on two seperate rigs. Seems to not be just a problem on my main machine. I've only tested on the Windows side so I don't know if it affects macs as well. There is an action I've used that kills all running scripts to double make sure there isn't anything other than the TCP running. Doesn't seem to matter will all the scripts turned off.

[karbomusic]

From the other thread:

I know that Reaper prioritized the audio threads above the GUI threads by design. I wonder if its possible to give the users some control over this priority for systems that have really powerful CPU's and GPU's

Though I think it could be more related to the sheer number of tracks and/or number of items or other things that may need to be enumerated.

[srdmusic]

Originally Posted by karbomusic

From the other thread:





Though I think it could be more related to the sheer number of tracks and/or number of items or other things that may need to be enumerated.

Karbomusic Yes there used to be an Appearance setting that could be adjusted for the GPU. I believe that setting has been removed. Perhaps that's the issue between v5.5 and the current versions.

Yes there is a large number of tracks but I was able to run session with triple what I'm working with now. The test session, has no instruments loaded, no plugins turned on, no items in the tracks. Just tracks within folders.

I also used to be able to work around this problem by using actions like: hide all unused tracks from TCP. This reduces the visible track count to maybe 15 tracks. Lowering the visible track count used to speed the GUI back up. Now I can't even use that workaround. It's simply freezing no matter what tracks I have visible.

I've never really seen anything like this in Reaper. This DAW has always been super snappy. So there has to be something either in my prefs that's changed things or it's a bug because I don't think the developers are intending to code in a 2 min freeze when trying to select multiple tracks.

I'll upload my prefs and Reaper install folder and template for anyone that wants to test.

[karbomusic]

Originally Posted by srdmusic

Karbomusic Yes there used to be an Appearance setting that could be adjusted for the GPU. I believe that setting has been removed. Perhaps that's the issue between v5.5 and the current versions.

Yes there is a large number of tracks but I was able to run session with triple what I'm working with now. The test session, has no instruments loaded, no plugins turned on, no items in the tracks. Just tracks within folders.

Ah... I just noticed that option is missing in the latest but I wasn't completely convinced it is related anyway. I downloaded the latest version (5.941) and installed as portable, seems fast enough selection wise testing with 1001 tracks - I went back and did some with folders as well but didn't spend a lot of time on it:



Just a sanity check, are you using HiDPI, scaling or any other monitor type settings that would be outside the defaults?

[srdmusic]

Originally Posted by karbomusic

Ah... I just noticed that option is missing in the latest but I wasn't completely convinced it is related anyway. I downloaded the latest version (5.941) and installed as portable, seems fast enough selection wise testing with 1001 tracks - I went back and did some with folders as well but didn't spend a lot of time on it:
Just a sanity check, are you using HiDPI, scaling or any other monitor type settings that would be outside the defaults?

I'm glad it's not happening on your rig. I'm hoping there is something dumb I'm doing to cause it but my fear is that we are looking at an actual bug. As I said in the first part of the post the session seems to get progressively slower with track selection as you keep the session open for more than 15 mins. This is again with nothing loaded, just selecting and moving tracks for 15 mins. Which leads me to believe there is some sort of memory leak or undo leak happening that's causing the slow down.

On thing I've noticed as well. The tracks at the top of the session select faster than tracks at the bottom of the session.

There isn't any HiDPI or scaling setting turned on. But that's a smart idea to check. I have the setting: HiDPI mode: Unaware (recommended)

[srdmusic]

MY CURRENT TEMPLATE AND PREFS:

https://www.dropbox.com/sh/jeq5ddkkp...cESkydiFa?dl=0

Within this folder you'll find my template in two versions. A large 900 track template and a smaller 550 track template. Both seem to have the same problem.

If anyone has any questions about how to use my Reaper Install/preference folder without messing with your current prefs please let me know and I can walk you through the process. It's very easy.

I would greatly appreciate anyone testing with my setup to narrow down if it's a bug or something in my prefs.

[karbomusic]

Originally Posted by srdmusic

I'm glad it's not happening on your rig. I'm hoping there is something dumb I'm doing to cause it but my fear is that we are looking at an actual bug. As I said in the first part of the post the session seems to get progressively slower with track selection as you keep the session open for more than 15 mins.

I'll create one and let it sit and report back. This is my machine at work which is just a vanilla portable I use for helping out in threads/posts.

[karbomusic]

So far so good at about the 30 min mark with 1000 tracks.

Then I opened your large template. First off 356 MB for an RPP is pretty gigantic with 2,747,390 lines (holy shit batman). I noticed one of the Kontakt plugin instances was 7666 lines long. I think there is more than one that is that size or larger for what it is worth.

I'd be willing to bet you cannot repro this without a template and all these track views, VST instances etc., just raw track counts. But maybe you can because, even with all that can't repro the slowness when selecting tracks (well I need to let that sit for 15 minutes so I'll be back in a bit):



So, maybe since this machine doesn't have Kontakt installed (the one at home does) maybe that's related and there is some behind the scenes enumeration going on but that's all I got right now.

[srdmusic]

Originally Posted by karbomusic

I'd be willing to bet you cannot repro this without a template and all these track views, VST instances etc.

Thank you very much for testing. I totally realize this is a larger template than most user work with but take a gander at the PC specs in my first part of the post. This 48 core Dual 3.2Ghz machine has been able to handle a 1500 track template for about a year before I started seeing this gui slow down problem this past 6 months. Now I'm working with a 550 track template and the problem is just as bad.

If you check out the template at home all of the instruments and plugins are disabled. As far as I can tell there should be No CPU, No GPU, or at least very little used if they are off-line.

Out of curiosity which track number had the large number of lines?

I can reproduce the fast track selection at the top of the session like in your video. However, at the bottom where the Audio Folder is, seems to be a lot slower in track selection. The Stems folder in that Audio folder are blank tracks. No instruments or kontakt plugins are on the track but they are the slowest to select.

Lastly, What software are you using to screen capture your findings? I will do the same so you guys can see the problem.

[karbomusic]

Originally Posted by srdmusic

Thank you very much for testing. I totally realize this is a larger template than most user work with but take a gander at the PC specs in my first post. This 48 core Dual 3.2Ghz machine has been able to handle a 1500 track template for about a year before I started seeing this gui slow down problem the past 6 months. Now I'm working with a 550 track template and the problem is just as bad.

My pleasure, also not cracking on the size, just noticing it's darn hefty - I respect you guys, I get annoyed dealing with my normal 60-100 tracks LOL. It's been almost an hour with your template open and selection still seems OK. To be fair the scrolling etc. is laggy as heck but not 2 minutes laggy.

If you check out the template at home all of the instruments and plugins are disabled. No CPU, No GPU, or at least very little should be used if they are off-line.

I'm heading that way in a bit but have some rehearsing to do so I may or may not be able to test there tonight, maybe.

Out of curiosity which track number had the large number of lines?
I can reproduce the fast track selection at the top of the session like in your video. However, at the bottom where the Audio Folder is, seems to be a lot slower in track selection. The Stems folder in that Audio folder are blank tracks. No instruments or kontakt plugins are on the track but they are the slowest to select.

Seems OK on the Audio > Stems folder - I was testing the tracks under the folder that is track 924.

Lastly, What software are you using to screen capture your findings. I will do the same so you guys can see the problem.

Cocko's on licecap - Grab it here: https://www.cockos.com/licecap/

[srdmusic]

Attached is a couple of quick videos demonstrating the problem.

The first video has a few tracks select. When I select just a single track and unselect the group Reaper freezes.

In the second video I select tracks which takes about 1 second before each track selects. Then I select a group of tracks and reaper freezes.

BTW how do you guys compress your videos so that they fit with the 600x800 64kb format. Is there a better way to post these videos then to attach them.

[srdmusic]

https://imgur.com/7tYo0a1

[srdmusic]

[juliansader]

Originally Posted by srdmusic

The forum peeps suggested that it was because of my high track count and that may be true but it doesn't explain the difference in functionally in version 5.5.

You mentioned in another thread some months ago that your home rig does not have problems with lagging -- is this still the case?

Originally Posted by karbomusic

So, maybe since this machine doesn't have Kontakt installed (the one at home does) maybe that's related and there is some behind the scenes enumeration going on but that's all I got right now.

When I previously tested srdmusic's template and other trial projects with large numbers of tracks and FX, I noticed that Kontakt has a strange effect:

Originally Posted by juliansader

After some experimentation, I am now also seeing this slow enabling/disabling of auto-arm.

It appears to be caused only by certain plugins, particularly two samplers: Kontakt and an old VSTSynthFont. (These are the only samplers I have available to test [on this computer], besides REAPER's own SamplOmatic5000.)

None of the other VSTs or VSTi synths seem to affect the speed of enabling/disabling auto-arm.

The more instances of (online) Kontakt, the slower auto-arm. When Kontakt is bypassed or offline, auto-arm is fast again.

Curiously, Kontakt has this effect even if it is bypassed on the tracks that are being auto-armed. For example, if Kontakt is online in tracks 1-200 and offline in tracks 201-400, the latter tracks are still very slow to enable/disable auto-arm.

Similar to Heda, I notice no difference if the mixer is open or closed.

[srdmusic]

Hi Julian!

Thanks for chiming in. Yes the home rig was not having these problems for a while and when we upgraded to later versions it also started to have these problem. I have to admit that I don't notice the slow selection on the home rig as much as I do on the studio rig. However, I don't work on it as much as I do the studio rig.

Yes, there seems to be an exponential slow down with the more kontakt instruments that are in the session even if they are all offline. This is why I've reduced the track count to about 550 tracks with only something like 300 offline kontakts. It is possible that something has changed in the way Kontakt was updated. I just don't understand how an offline plugin could affect the GUI so much.

I do not see the same problem in Cubase with 1000 kontakts loaded. Cubase switches tracks and selects tracks quickly. So there might be some new thing Kontakt has done that only affects the way Reaper responds. This might explain why the home rig was working fine and then after updating kontakt both rigs slowed down. I'll start gathering intel on the NI forum.

Do you have any ideas as to what we could set in Kontakt to make things a little faster in the Reaper GUI? What do you think about loading all of these kontakts into their Komplete Kontrol frames? I avoided doing that because I figured it's double the plugin power each one needs. However, Komplete Kontrol seems to reduce the GUI interface down to a simple set of Knobs. Maybe this could reduce graphics overhead.

BTW the video files I posted were blank tracks with no instruments/ offline Kontakts on them. Simply tracks within a folder.

[srdmusic]

The option to make the GUI update 'always fast' has been removed from Reaper. Not sure if it is now defaulted to 'always lazy' instead. Justin or Dev's can you confirm what the setting is now that it's been removed as an option?

I know it's a long shot but anything to avoid Reaper from freezing for 2mins+ would help.

[srdmusic]

Can anyone reproduce the freezing problem? There isn't much on the Kontakt forums but that doesn't mean much since there isn't many people trying to load 800 offline kontakts in a session

[Klangfarben]

I will grab your current template and test. I'm not getting a huge amount of lag with track selection in mine but things are def laggy-er with so many Kontakts. My biggest issue is long save times with the large number of tracks with Kontakt on them.

[juliansader]

What compatibility settings are you using for KONTAKT?

I have tested REAPER vs KONTAKT again and, many crashes later, I realized that Run as -> Native is vastly faster than Run as -> Dedicated process, and since Native doesn't hang REAPER as easily, it is actually safer too.

When using Dedicated process, I can barely load 100 instances of KONTAKT or PLAY without REAPER hanging, crashing other otherwise freaking out with flashing windows.

With Native, I can load my entire RAM full of hundreds of KONTAKT instances (online, with instruments loaded in each), without any noticeable lag.

Interestingly, "Buggy plugin compatibility mode" also seems to have an effect. When using Dedicated process, "Buggy plugin compatibility mode" also allows me to load many more instances, although loading is not as fast as when using Native.


** EDIT: I checked in the Preferences that you posted above, and it seems that you are already using Run as -> Native by default.

[EvilDragon]

One thing everyone should be aware of regarding Kontakt is that its scripting engine is tied to the RT audio thread. So basically each arm/disarm of the track would reinitialize the audio engine and reapply the scripts (IIRC) - which can take some time with heavier instruments.

Additionally I have noticed tons of ultra-weird behavior with scripted Kontakt interfaces if Preferences->Audio->Playback->[x] Run FX when stopped was DISABLED. Which is natural, because if FX is not running, that means Kontakt's audio engine is not running, and that in turn means that scripts also don't do any of the work they're supposed to. So make sure you always have that enabled. Perhaps the above setting might also improve the auto-arming of Kontakt, since it wouldn't kill then respawn Kontakt's audio engine every time you disarm then arm...

[srdmusic]

Originally Posted by EvilDragon

One thing everyone should be aware of regarding Kontakt is that its scripting engine is tied to the RT audio thread. So basically each arm/disarm of the track would reinitialize the audio engine and reapply the scripts (IIRC) - which can take some time with heavier instruments.

Additionally I have noticed tons of ultra-weird behavior with scripted Kontakt interfaces if Preferences->Audio->Playback->[x] Run FX when stopped was DISABLED. Which is natural, because if FX is not running, that means Kontakt's audio engine is not running, and that in turn means that scripts also don't do any of the work they're supposed to. So make sure you always have that enabled. Perhaps the above setting might also improve the auto-arming of Kontakt, since it wouldn't kill then respawn Kontakt's audio engine every time you disarm then arm...

Thanks for the insight ED!!!! That's a good suggestion. I'm going to turn the setting off while working to see if it reduces CPU.

As far as the track selection/ arm problem, The setting doesn't seem to affect that particular issue. So when I start the template that I posted, all the the kontakt instruments are offline. I know there is a lot of ram and resources still being used even though they are offline but I'm curious as to why that would affect GUI refresh as my GPU isn't pinned and neither is my CPU by a long shot. Both are well below stable working numbers and this only seems to affect later versions of Reaper.

I'm going to try and find the version at which this changed. The only wrench in this whole thing is that I fear it's actually a problem with the update to Kontakt 5.8.1. NI has no interest in dealing with problems of this scale when there product is being used over a 1000 times in one session. Where as the Reaper team has always been about efficiency. I hope there is a way to code a work around within Reaper like many of NI and Microsoft's flubs along the way.

Thanks again for all you're guys help. ED, I see you post on almost every forum with great advice for noobs and pros. You're a real hero, so thank you as well.

[srdmusic]

Originally Posted by Klangfarben

I will grab your current template and test. I'm not getting a huge amount of lag with track selection in mine but things are def laggy-er with so many Kontakts. My biggest issue is long save times with the large number of tracks with Kontakt on them.

Yo Klangarben, Thanks for the testing. It's really been helpful all the extra tech work you've put into Reaper and the hardware we both use. I know you and I are on similar Nvidia GPU's. I've been avoiding jumping to the P4000 since my M4000 has been great so far. It feels more like a Reaper/Plugin or Reaper/ preference setting issue than GPU. Maybe wishful thinking huh....


You're right about the save times. ED and JS had good suggestions about making sure most of your plugins run under Native and not buggy compatibility. The save minimal undo and so forth suggestions did save on the Reaper file size a bit.

On the home rig I don't seem to have the freezing issue but it does take about 1 second to select a track. The home rig is on the API W7100 you so kindly gifted to us for our wedding. This leads me to believe we're looking at more of a software issue than a hardware specific one.

In the currently template with less than 400 kontakts I would think we should see some better performance, but I'm seeing the same issues on both rigs. Can you confirm?

[srdmusic]

Originally Posted by juliansader

What compatibility settings are you using for KONTAKT?

I have tested REAPER vs KONTAKT again and, many crashes later, I realized that Run as -> Native is vastly faster than Run as -> Dedicated process, and since Native doesn't hang REAPER as easily, it is actually safer too.

When using Dedicated process, I can barely load 100 instances of KONTAKT or PLAY without REAPER hanging, crashing other otherwise freaking out with flashing windows.

With Native, I can load my entire RAM full of hundreds of KONTAKT instances (online, with instruments loaded in each), without any noticeable lag.

Interestingly, "Buggy plugin compatibility mode" also seems to have an effect. When using Dedicated process, "Buggy plugin compatibility mode" also allows me to load many more instances, although loading is not as fast as when using Native.


** EDIT: I checked in the Preferences that you posted above, and it seems that you are already using Run as -> Native by default.

I'm forever in your debt JS! I made sure all my plugs work with no compatibility mode accept Autotune which crashes on the regular. I'm currently on Kontakt 5.8.1 and the real problem is that they don't really let you go backwards once you update. The track selection problem has been happening since at least 5.8 and possibly 5.7.3. I could try a separate install to confirm.

Thanks again for all the tests. Where you able to reproduce the GUI errors?

[mschnell]

Regarding Kontakt and GUI freezing, there is (at least) one other thread about this: it can happen that certain Kontakt versions freeze the complete GUI with certain actions (for me: deleting an instrument collection in a Kontakt instance) by preventing any mouse activity. I could get the GUI running again by pressing ESC, but the action in the Kontakt GUI could not be performed at all. Others reported somewhat different behavior, For me it does not seem to happen with the latest Kontakt version.

-Michael

[juliansader]

Originally Posted by srdmusic

The symptoms are that when I have a session open for more than 15 mins track selection becomes very laggy. The lag is not quite a bad when I first open Reaper. Sometimes it takes 1-2 seconds before I can select a track. If I select multiple tracks sometimes Reaper with become unresponsive for up to 2 mins before it selects that track. This is not a problem I had in Reaper 5.5 and below. During my test I was only selecting tracks and moving tracks around. I did not have any instruments online and no audio in the session. Waiting for reaper to selected a track for 2 mins while it basically crashes is making it very difficult to work.

I could not unfortunately not replicate this. I created a portable install of REAPER, copied your configuration zip, and opened the large template. The project was open for several hours, during which I would intermittently select or duplicate some tracks. Track selection remained fast.

Since KONTAKT and all other instruments are offline, I doubt that KONTAKT is the culprit in this case. (It is still possible that, in other cases, KONTAKT is causing another, separate problem that also slows REAPER down.)

Possible differences:
* The configuration seems to have copied OK, except for two AutoHotKey .ahk scripts that weren't included in the zip.
* Two items in the project were saved by unnamed extensions that I don't have.
* There are several plugins, particularly Slate and Relab LX480 plugins, that I don't have, but that are supposed to be online in the template.

BTW the video files I posted were blank tracks with no instruments/ offline Kontakts on them. Simply tracks within a folder.

Was KONTAKT online at or before that moment in any other track or project? In my own GUI bug report, I found that certain plugins that are incompatible with my graphics driver will continue to slow REAPER down, even after I take them all offline.

Yeah, I'm testing it with portable and normal install. Doesn't seem to make a difference. I've also tested on two seperate rigs. Seems to not be just a problem on my main machine.

I wonder what would happen if you start afresh with a clean portable install, and then build a new project with 1000 tracks containing only KONTAKT, nothing else. No extensions, LBX, Slate plugins or anything else.


Your situation reminds me a lot of Attention developers : Annoying video bug.. pls help. Weird problem that happens on all computers of one user, but that no-one else can fully replicate, and that makes REAPER practically unusable. If all else fails, your best bet might be to contact Justin directly, to try to get him to take a look at the problem.

[EvilDragon]

Originally Posted by srdmusic

Thanks for the insight ED!!!! That's a good suggestion. I'm going to turn the setting off while working to see if it reduces CPU.

No! You have to keep it ON! Turning it off results in all sorts of bizarre things happening in Kontakt with unarmed tracks.

[srdmusic]

Originally Posted by EvilDragon

No! You have to keep it ON! Turning it off results in all sorts of bizarre things happening in Kontakt with unarmed tracks.

Hmmm. It's already on. I'll test further. I think we should put the Kontakt problem aside for now because I have just confirmed that starting from a blank session and adding 1000 empty tracks causes Reaper to freeze for about 3 mins while creating the tracks. That's never really been a problem before. Reaper has always been able to add tracks very quickly. And I can confirm that other users have added upwards of 4000 tracks in a just a few seconds.

On thing I haven't really dived into is the number of Midi devices connected to my rig. I have lots of outboard midi. I also have a SSL Nucleus that connects to Reaper on 4 ports. 2 for 16 faders and 16 Knobs of CC data and 2 for Mackie Control. I'll try disabling midi devices and see if there is a difference. It could very well be the Mackie Control which is slowing things down alot.

[srdmusic]

Originally Posted by mschnell

Regarding Kontakt and GUI freezing, there is (at least) one other thread about this: it can happen that certain Kontakt versions freeze the complete GUI with certain actions (for me: deleting an instrument collection in a Kontakt instance) by preventing any mouse activity. I could get the GUI running again by pressing ESC, but the action in the Kontakt GUI could not be performed at all. Others reported somewhat different behavior, For me it does not seem to happen with the latest Kontakt version.

-Michael

Good point. I'm not using any actions while in Kontakt in producing the error. Nor do I have any of the Kontakts turned on. I can reproduce the error with blank unarmed tracks. Might be a MIDI device or Mackie Control problem.

[srdmusic]

I may have found the culprit. As soon as I removed the SSL Nucleus from Remote controlling Reaper through Mackie Control, the gui responds much more quickly.

I'm using the standard Mackie Control built into Reaper. Is there a better HUI or Mackie Control that allows for the adjustment of how tracks are selected/ GUI responsiveness? I see that the default Reaper HUI/ Mackie allows the Display update frequency to be increased. I'll try messing with that first.

Anyone who has set up a different way of using HUI, I would greatly appreciate the help in getting mine to respond as expected.

[EvilDragon]

IIRC MCU/HUI spit out an awful lot of MIDI data, and the more tracks you have in the project, the worse it gets...

[srdmusic]

Originally Posted by EvilDragon

IIRC MCU/HUI spit out an awful lot of MIDI data, and the more tracks you have in the project, the worse it gets...

You're probably right. I just tried the Klinke alternative and it's even worse. Freezes Reaper for even longer then than the built in one. Damn. There has to be a work around...

I really don't use the MCU/HUI much accept for the transport. I suppose I could try switching everything over to just the one port I have CC's on and set the actions of the transport to buttons. Just really sucks that I can't use HUI at all and can't get the buttons to light up when I press play etc etc.

[EvilDragon]

Originally Posted by srdmusic

There has to be a work around...

OSC, if your control surface supports it? Or have your mobile phone be your transport using web control?

[srdmusic]

Originally Posted by EvilDragon

OSC, if your control surface supports it? Or have your mobile phone be your transport using web control?

Only Midi and MCU but I might be able to convert with Bome Midi translator.

[srdmusic]

Everything has been running much smoother today. Thanks for all the help everyone. I'll make a new post to try and find a better way to work with Mackie Control.

[juliansader]

Originally Posted by srdmusic

Everything has been running much smoother today. Thanks for all the help everyone.

This is good news!

But... I'm not quite sure that we have actually gotten to the bottom of this problem: In your original thread about slow GUI, one of the suggestions was that a MCU could be the cause (since the MCU is known to cause this exact problem), but at that time you did not yet use any control surface. Could there be another problem that also causes sluggishness and that pre-dates the MCU?

[ivansc]

Just a quick thought - I have several smal MIDI controllers, but recently switched over to OSC and a tablet computer. MUCH better in almost all respects, but of course that is for MY purposes. Worth investigating though... Been using both OSC-Commander and Touch OSC.

[srdmusic]

Originally Posted by juliansader

This is good news!

But... I'm not quite sure that we have actually gotten to the bottom of this problem: In your original thread about slow GUI, one of the suggestions was that a MCU could be the cause (since the MCU is known to cause this exact problem), but at that time you did not yet use any control surface. Could there be another problem that also causes sluggishness and that pre-dates the MCU?

Currently scrolling and track selection has been sluggish for some time now but never as horrendous as with this MCU problem. With a 1000 tracks up arming and selection takes progressively longer towards the bottom of the session. I've reduced the sessions down to 550 tracks and have track layouts that narrow the scrolling and selection problem now. It's usable but I wish it was as snappy as Cubase. The MCU problem started a few months back when I purchased an SSL nucleus. It has the ability to work strictly with midi so when I switch it over to that we are back normal sluggishness as opposed to the almost unusable MCU sludge.

[Dannii]

I seem to recall a recent update of REAPER included some tweaks to the HUI protocol. Something about keep alive messages from memory. I wonder if that could be a contributing factor?