Jump to content

DCMG

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is a really good point. I've been looking at some of those plugins to see if there's common culprits. Every project I have probably has Fabfilter EQ, Maag EQ, RenComp, Concrete Limiter ( this is often in place before real limiting on mixdown, and I try never to have this on during tracking but worth chasing down to be sure). There are others, but those are literally on every project in some measure. I've had it happen on a project where no software instruments are in place, so I think I can rule those out.
  2. OP here. I get what you are saying...but the setup I'm using is not unusual. Apollo USB is the only interface my system is seeing. The Presonus 192 is being used simply as a set of converters for 4 (nice) outboard mic pres. That way my Daw sees the analog ins of the Apollo along with the optical ins supplied by the 192. Not sure why externally clocking the Apollo would be the culprit, but I might try the test just to be sure.
  3. Yeah, I'm not seeing round trip latency issues offset by 128 samples or something. These are wholesale "off by 10 seconds" issues. Then the next immediate round of recording (literally seconds later) ...everything fine. Odd issue. Yesterday happened mid session, which I haven't encountered. It's a tough one to explain to clients ( when we already labor under the "why not ProTools?" dogma 😆
  4. Interesting note that the waveform preview is always in correct position, suggesting alignment is correct at moment of capture, then offset upon transport reset. Same always true here as well. I'm going to update all my system info along with typical plugins used so we can identify any commonalities. Regarding the suggestion about generic drivers, I only have the UA Apollo Twin USB drivers present and still have this issue. No conflicting ASIO drivers present.
  5. It happens so infrequently you might be waiting days or a week before the changed settings would show if they worked. I'll keep at it too. Strange elusive issue....
  6. Did some testing last night, couldn't get it to happen (or course) My only clue is I've never had it happen LATE in a session; always right off the bat, then subsequent takes are good once I observe the issue, stop transport and begin a new set of takes ( buffering, length of time program/OS/computer has been on? ) I've started doing a test run of 2-3 looped takes when I've got a client present. I don't tell them why I'm doing it, but I'm checking to make sure it's behaving. Shouldn't have to do that type of stuff to trust your system ( which BTW is a fast CPU, good RAM and all SSDs so no issue there) Will keep digging.
  7. Thanks for the input. Don't recall this issue in SONAR; seems like a recent ( last 2 updates?) Will do more testing this week, but it's pretty random so far....
  8. Random issue but happens enough, thought I would ask if this happens to anyone else. Typical circumstance: Loop Record Mode> run 4-5 passes> stop transport to find all passes are not in correct position (always early to where they should be). Luckily I usually am looping to a grid so it's easy to see the new misaligned passes are easily moved by 1/4, measure or whatever and all is well. Subsequent passes all land in correct position; not unusual for the problem to NOT present itself again for days or a week. Note: I did have this happen with a manual start (non looping mode) the other day, so it's not just a loop record issue. No pattern detected yet, and no other timing anomalies with my setup observed ( UA Apollo w/ Presonus 192 providing Optical ins and clock) TIA.
  9. thank you thank you!!!
  10. So glad to hear others questioning this. I usually use cntr+arrows for quick zooming and the (zoom+center) behavior I simply took for granted as normal. Now I have to zoom and hit G (center) to center where I was working *constantly*. It's a workflow mess and slows me down. Can we have this be a user option to have the old behavior ?
  11. I would like to know this as well. Is this new behavior discussed somewhere in another thread? Definitely prefer the previous <zoom+center> behavior .
  12. When it happens it's with every midi folder in the project ( ie if I have battery, Omni, AD, etc all will be closed w/tracks within folder hidden). It's also free of any pattern thus far, so I think it must be a keystroke ( perhaps custom one?) that is doing it when I'm not aware. Thanks for the input. I will continue to track it down. Creating a test file today with the usual midi tracks on board and run through some typical keystrokes to see if I can recreate with more regularity.
  13. I mentioned in my post that the pic I took was of a folder with nothing hidden yet. "Pic here is with tracks "not hidden". I posted this as there was some confusion in an earlier reply as to what "hidden" meant (?!) In this context...that is the hidden I am speaking of. So I just opened another project where I definitely did not intentionally go to this track and "hide" the midi tracks. Yet when I open it. If I'm not purposefully doing that upon close, I have to guess there's an errant keystroke or preference I've set ( or not?) that is doing this when I close a file. That is what I'm trying to investigate.
  14. pretty sure I don't but I will double check that. Thanks for suggestion.
  15. It does seem to be in midi folders. Hiding midi tracks within an instrument folder is (was?) a very specific process, but now something I'm doing is making that happen when I'm not aware. The term hidden applies to THIS scenario. ( Yes, I understand collapsing audio tracks in a folder...this is with midi tracks only upon further investigation). Pic here is with tracks "not hidden". When I re-open the file, the midi tracks will be "hidden" and I will specifically need to click the box to unhide. This seems to be happening without my input, but I know that's impossible. Wondering if a new shortcut or key binding that I use regularly is doing this. Will keep investigating, but any other observations of this would be appreciated.
×
×
  • Create New...