I like to think i am pretty savvy when it comes to PD, but alas, I still have much to learn it would seem, as I cannot for the life of me solve an issue with a patch of mine that has been driving me mad for quitge some time now. When I open the patch, all midi runs fine. Everything is low latency and very usable... but the more I play around in the patch and play keys and alter settings, things get slower and slower... until finally after a while there is too much latency in the midi system to even use my patch properly. The problem is solved when I shut down PD and restart the patch, but then rears it's ugly head once againm after some time. The patch is prety complex andf has a lot fo stuff going on, but it is a midi only program. The audio engine is off, so that is not likely the cause. Im thinking it has something to do with the console stacking up, or various objects which store data stacking up and bogging down. I would like to build in some way to clear things up soo the latency never piles on too much, but I cannot figure out which object is causing it or why! Does anyone know of any onjects that are known to cause this problem so as to point me in the right direction? I can post the patch if anyone cares to see it, but I warn you that it is pretty huge and would have layers and layers of patching to dig through. Maybe there is some way to globally clear all the midi data buffers or something? any help would be immensly appreciated, as the patch otherwise works well and It's something I use in almost every session!

Many thanks.
Cheers!

@th8a Yes..... post it up.
Is it creating objects dynamically? I have had a similar problem where I copied a part of a patch that created objects, in order to create other objects, and forgot about a bang with a (non $0) receive name. The patch would recreate those objects on top of each other in certain circumstances. It came to a head when I changed a value sent to [moses] and the creation patch ran away creating objects continuously....
No messages to terminal as it had no problem creating.... it just had very little time to do anything else...!
Storing and retrieving data should not bog down a modern computer.
David.

Did you try monitoring the midi messages using some small program like kmidimon or midi monitor or midiox?

Nau

@th8a I had this happen twice in the past... in my case the culprits were:

1. a message box in a forgotten subpatch which was collecting midi note numbers for later use, using |add2 $1( with no |set( message to clear it. It would eventually grow so large that I would get audio dropouts.

2. list-lifo & list-fifo, again collecting midi note information but neglecting to clear it every once in a while.

I suppose some of the specific midi objects could be the problem in your case, for example if an object is expecting note offs but not getting them? (I sometimes get these warnings using maxlib/chord) If that turns out to be the problem, maybe cyclone/flush could help by providing the missing note off messages?

Hey all. Sorry for the delayed response here. Thank you all for the replies.
@beepbeep - You know what - your idea of what is happening is damn likely. There is a lot of list fifo and lifo going on in the the later stages of the patch, and a ton of things like notes being stored as lists for later use etc. It also has a lot of chords being triggered from single note input, so note-off messages ending up where they are supposed to is something that has been one of the major challenges of the building the patch from the beginning. I finally managed to get noteoff messages to happen in a reasonably reliable manner, but now and then there will be some stuck notes, which I dealt with in a way that is a bit quick and dirty, and not exactly elegant... I have been so so busy with boring life crap that I have not been working on my patch for a while... but reading your response gave me some inspiration in the form of a likely lead on how to fix the problem. I am going to look into it a bit later today and see what I can find. For the rest of you, here is the patch in question... I was hesitant to let it out because I always sort of considered it one of my secret weapons in the studio... but hell, I may as well share it with my most favoritest music community with hopes that you all enjoy using it as well as maybe pinpoint the bug in question. You will need classic pd-l2ork to get it working. I made a version in purr-data, but for whatever reason it was always unstable and the latest versions of purr-data crash on loading every time... so I will probly have to start it from the ground up when I am finally ready to update it... that said it works quite well in classic l2ork, save the problem stated in the OP. Please, Id love to know what anyone who checks it out thinks or if they find the problem before i do... Move the folder from the attached zip fileCM.zip into your path and open the top level patch, CM7.pd located in the CM folder Also note that there are two midi channels which can receive midi. the first channel triggers the chord memorizer, the second recieves notes , remaps them based on the chord which was triggered and the options selected respectively, and outputs them from the second output. Any questions about it are welcome. Cheers!

PS: I should also mention that you will not get any output at all until there are settings set in coll object which holds the global settings. Each note that can be played on the keyboard into the first midi input will recall a list of settings which are stored for that key. For example, C1 on the keyboard will trigger an A diminished chord in third inversion, open position and a lydian scale for the mapped input etc. If the coll object which stores those settings is empty for that key, nothing will happen, so you'll initially need to enter a key and then set some settings on the patch's UI. Best thing to do is set every setting on one key and then use the copy paste function that I built in to set those settings for every key just to get the thing initialized. Then you can set each key to your liking. Soon I will implement a default setting that will fix this issue, but as I said, Lifes been all naggy lately... so if you go to use it and it doesn't seem to work, just keep this in mind. Also, I admit that not everything is well labeled yet... For now Im the only one whos used it and i know where stuff is... for instance the little ulabeled button next to the button labeled "seq" will toggle the sequencer window on and off, and the number objects with the green buttons on the right hand side with no labeling are to control the osc inputs and outputs - ie setting the ip address etc. With the toggle button marked flam turned on, you can click drag an array where the display screen looking tghing is to set different flam timings of how the chord plays.. I tried to make it feel and function like your usual VST plugin.... just toy with stuff and you'll figure it out... And finally, the guts of the patch can be found by dragging the top level window size bigger to the right until you see the subpatch boxes... ok, Cheers

BOOM! Finally found the culprit. It was a [list cat] object that wasn't getting properly cleared. @beepbeep - you da man! Now my patch is finally performance ready. Im stoked.

@th8a Cool! Glad that my past ineptitude led to a teachable moment for the both of us, at least.

@th8a, what is [list cat]?

@LiamG it is an object from listabs that stacks lists from values it recieves.

Funny, I don't have it in my version of list-abs.