Edit 3: Got it working with a CC message being sent from Python every 1ms to an encoder. This seems to clear my network queue pretty quickly but I'm thrashing the CPU somewhat in python and Live. Not sure how else this problem can be fixed right now, but this works for the moment.

Edit 2: Just tried something crazy. I mapped the mod wheel on my keyboard to a EncoderElement so that my ControlSurface script fired its receive_midi method every time I rotated the wheel. The receive_midi method then threw away the midi message and triggered my event loop that looks for messages incoming from Pyro. The incoming midi messages are processed incredibly fast and also got rid of the notifications error. I'm hazarding a guess that I can't modify parameter values easily if my code has been triggered by a listener, probably something to do with how the listeners are threaded. The next step now is to send a constant clock CC message from my Pyro server, and then everything should be great!

Edit 1: Just had a possible thought of a way around the problem. Is there any way I can fake a CC value coming in? I have EncoderElements set up on all of my parameters at the moment, and if I could find a way of fooling an encoder into accepting a CC value coming from my network code then maybe that will perform all the necessary checks and send the value to the right place at the right timequestion:

Original Question: I recently have been working on a networked midi remote script so that I can control clips and parameters in Live using Pyro (Python Remote Objects). The one snag I've run into involves setting the value of DeviceParameter objects directly which results in a "Changes cannot be triggered by notifications. You will need to defer your response" error.

I arrived at this point as follows. I have an update method that gets called by both the update_display function and a listener I have on the song timer. This method will grab messages off the network and process them into values for applying to device parameters. The reason that the update gets called from both update_display and the listener is because it seems to be the fastest type of loop that I can access, since I haven't had much luck with threading (seems to be locked to 100ms from what I've read).

When the song timer listener is activated during song playback, a significantly lower number of values will make their way through to the parameter, anywhere between 1 in 2, to 1 in 7. The rest all get marked with the "Changes cannot be triggered by notifications." error. When the song is stopped, values will start to make their way through normally, unimpeded by the error.

Anyone have any clue how I can avoid this? I've read a few notes from Max for Live where the error also appears, and apparently it's fixed with a "deferlow" object. Since I don't have access to similar tools (as far as I know) I'm not sure how to move forwards.