Oh, it's not a bug, it's a quirk then - if with clever filtering and double checking every relevant event can be collected somehow, then things are finde with me. Ofc I can understand its problematic if you don't know the whereabouts, and also think that a proper api that don't need quirkyness workarounds is the best, but well, in my experience almost any complex software api has such strange behaviour somewhere in its guts.
Hm, so I thought I'd first do the processing code until it works fine. It would also set me going as I could compose a tune straight or with some native groove, and then experiment with grooves, single-run applying them on command. This would also be useful for old (quasi finished) tunes, that are to get some a posteriori ants into their pants...
Then I thought about an event catcher func that is as slim as ever possible, just filtering/collecting relevant events to some stack or so. Then a processing routine that goes in the background that will apply the action - is the idle notifier background threaded, or would I have to split the workload in packets for the whole thing not to block the engine at any point more than absolutely nessecary? Is it generally advisable to put processing out of the notifier handlers and schedule into idle routines instead?
I mean also, the nature of the task I have in mind is very simple, and with the right concept it could work out well. I don't know how robust I would want to make this. For example the effected copy of a track is never to be touched by the user, I'd for example go for assuming the user not to touch it and periodically and by demand overwrite whatever crap happened to the track just to make sure. Maybe the processing also can be kept rather simple, by for example always processing the whole patterntrack on a change instead of trying to weed out just single notes that were changed. I will also try looking for nudge/shift tools, or similar, to lend some note overlap handling for shifting notes to (new) columns. My main concern on the live grooving approach is to keep it, for the user, as close to a normal workflow as possible, I have some Ideas going on about this. But some concepts will imply my own preffered workflow I think, or also have to add quite some visible baggage to the project in order for it to work nicely.
Maybe you want to split the discuss to another thread as its not related to your tool any more. I also have to say there will be some time passing until I can try working on this. Might have to wait for nothern hemisphere winter... I am no seasoned programmer, just an enthusiast, and I have other things to waste my time with, and want to get warm with another tool that aims accelerating sample creation/editing/processing workflow with the convolver first.