to_the_sun

The heart of the patch I'm creating right now is an itable which usually has around 10,000 elements and needs to be cleared periodically. Unfortunately this doesn't happen seamlessly; it causes a little pause and a glitch in the audio, but only when running within Live. Strangely, running externally in editing/preview mode it works just fine, so that's the way I've been running it, which for my purposes is fine, but if I were to ever offer this device for other people to use I would need to take care of this issue. I don't believe I can reduce the size of this table without compromising my program. Any ideas about what I could do to fix this? Instead of sending the itable a clear message, I now send it a couple of size 0 and range 0 messages, which made the blip smaller, but it's still there. Also itable vs ordinary table made no difference.

lag-that-causes-a-blip-in-audio-when-clearing-an-itable

try sending the clear message through the deferlow object into itable.

I was just reading up on deferlow actually. I've been getting intermittent "Changes cannot be triggered by notifications" warning ever since I implemented my first live.observer into the patch, which have not actually caused any problems that I've noticed as of yet, I just see pink every once and while in my Max window.

Thanks for the suggestion, that actually makes total sense now. I'll post back if it works...

Didn't work. Any notions on why it would lag inside of Live and not outside?

Well, the patcher (amanuensis.amxd) is pretty extensive...

In fact as I've added to it i've noticed that the pops and clicks occur more than just when the large itable clears, but I always run it externally to avoid this. However after adding a second patcher (NPC.amxd) to my whole set up which communicates with the first I would get an unacceptable amount of latency in the audio running Amanuensis externally. Here are the notes I was jotting down as I tried to diagnose the situation:

"There is an unacceptable delay on the audio coming from any track with a device in it when Amanuensis is running externally AND there is a track whose IN is set to Amanuensis's track (with the subcatergories of Post FX or Post Mixer chosen and notably NOT when Pre FX is chosen.) This track does not even have to contain a device of any kind. The delay does not occur on tracks with regular analog input if the track's output is set to Sends Only. If the output is set to Master, TWO notes will sound, one that is on time and one subject to the delay. Running internally, Ableton's CPU usage ranges from 9% - 15% (the lower end of this range while recording, but while no signals are coming in, the higher end while playing keyboard and sending signals). Externally, Ableton acts as if nothing in particular is going on and stays at the usual ~5%, but the computer's CPU usage as shown by the Windows Task Manager is 15-25% (roughly the same as when running internally). The switch from internal to external is accompanied by a jump in RAM usage from 4gb to 5gb, according to the task manager. The delay can be eliminated by running Amanuensis internally, although doing this causes clicks and pops when a lot of notes are coming through. This can be alleviated by raising the buffer, but this causes an undesirable amount of latency."

So really it looks like this is coming down to more of a general issue about CPU processor allocation in a DAW... Is there some trick of a way to compensate for latency and get it to just “line up”? Since I'm guessing there isn't, my real question is this: 

Why are these issues coming up when my computer's resources aren't even coming close to being fully tapped?

 When it runs externally it's smooth, there's just a delay. 

Is there any way to give Ableton more resources to work with?

After discovering that the delay only occurred when there was a track to which the Amanuensis track was sending midi, I reworked my two patchers so the NPC could record straight from the midi stream coming into Ableton and not have to feed off of the Amanuensis track. This got me back to a workable scenario. However a couple days later I was frustrated to find that the NPC patcher by itself (even if Amanuensis isn't present in the Live set at all) was causing the same kind of delay if run externally. I KNOW that after my rework of the two, I had them both running externally at the same time with no delay. I can't figure out what I've done differently now (I've added some to the NPC patcher, but not much). My situation right now is still workable enough, but it's annoying to deal with the lag externally, yet hard to work/diagnose patchers internally (no print capabilities, etc.). The NPC patcher is not nearly as extensive as the Amanuensis, so I took a pic of it in full, in case anyone wants to look at it and possibly suggest something. I really wonder if it even has to do with the code itself (I mean, I understand if Amanuensis causes delay; it has a lot going on, but there's not all that much to the NPC). 

Are there any known circumstances where running in preview mode causes this kind of latency?

Sorry to be so long-winded, but I've spent a lot of time on this and I figure I might as well be thorough. Also I might not be able to respond immediately as I don't have reliable access to the internet at the moment. Thanks in advance!

Well, the patcher (amanuensis.amxd) is pretty extensive... 

So really it looks like this is coming down to more of a general issue about CPU processor allocation in a DAW... Is there some trick of a way to compensate for latency and get it to just “line up”? Since I'm guessing there isn't, my real question is this: Why are these issues coming up when my computer's resources aren't even coming close to being fully tapped? When it runs externally it's smooth, there's just a delay. Is there any way to give Ableton more resources to work with? 

After discovering that the delay only occurred when there was a track to which the Amanuensis track was sending midi, I reworked my two patchers so the NPC could record straight from the midi stream coming into Ableton and not have to feed off of the Amanuensis track. This got me back to a workable scenario. However a couple days later I was frustrated to find that the NPC patcher by itself (even if Amanuensis isn't present in the Live set at all) was causing the same kind of delay if run externally. I KNOW that after my rework of the two, I had them both running externally at the same time with no delay. I can't figure out what I've done differently now (I've added some to the NPC patcher, but not much). My situation right now is still workable enough, but it's annoying to deal with the lag externally, yet hard to work/diagnose patchers internally (no print capabilities, etc.). The NPC patcher is not nearly as extensive as the Amanuensis, so I took a pic of it in full, in case anyone wants to look at it and possibly suggest something. I really wonder if it even has to do with the code itself (I mean, I understand if Amanuensis causes delay; it has a lot going on, but there's not all that much to the NPC). Are there any known circumstances where running in preview mode causes this kind of latency?

Sorry to be so long-winded, but I've spent a lot of time on this and I figure I might as well be thorough. Also I might not be able to respond immediately as I don't have reliable access to the internet at the moment. Thanks in advance!


It should be possible for you to create a very small chunk of code which models the thrashing you're handing to itable without us having to dive into your whole device.

If you can do that, and it reproduces the problem you're hearing, then we might be able to start helping you.

It is extremely rare in Max programming for a problem not to be reducible, and it will help your use of this forum if you are able to create really small example patchers which are easy for others to diagnose.

Lag that causes a blip in audio when clearing an itable