MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Questions and discussion about building and using Max for Live devices
Post Reply
lx71
Posts: 44
Joined: Sat Jan 02, 2010 5:57 pm

MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Post by lx71 » Sat Sep 17, 2011 2:44 pm

When working on Python scripts for ControlSurfaces, I frequently run into the following errors:
-----------------
RemoteScriptError: MixerComponent.on_selected_track_changed(self)
RemoteScriptError: AttributeError
RemoteScriptError: :
RemoteScriptError: 'NoneType' object has no attribute 'on_selected_track_changed'
-----------------

It's a strange error since MixerComponent is an imported parent class (type of thing...).
This pops up at some point and then there is no way to get rid of it, except by reloading your scripts, starting a new live set or restarting Live.
Once this error happens, it also sometimes gives more errors about code that is not even there anymore.
I am not sure why this keeps happening or what I can do to prevent this.
I've seen this error popup up in (the supplied) Mackie ControlSurface scripts as well, so I'm thinking it is not entirely my fault, but I'm sure I'm missing something.
I realize I have not supplied a lot of information here, but I figured that anybody working with the Python Midi Remote Scripts and the _Framework clases recognises these.
I hope someone can help with this.

Thanks,
Alex
Check out the UltraDevice http://vimeo.com/21841158. A DeviceComponent with more than 8 controls!
Here is my music: http://soundcloud.com/goalex

amounra93
Posts: 431
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Post by amounra93 » Tue Sep 20, 2011 6:36 pm

Sometimes things get screwy if you are editing py scripts without closing and reopening live. Mainly, though, I would recommend checking your 'disconnect' functions and making sure everything is getting resolved correctly between sessions (this happens a lot, and is the usual cause for this type of thing when I see it in my environment).

Hope this helps, cheers :)

a
http://www.aumhaa.com for Monomod and other m4l goodies.

ST8
Posts: 259
Joined: Mon Jan 26, 2009 12:55 pm

Re: MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Post by ST8 » Wed Sep 21, 2011 6:47 am

You've raised an error somewhere before the script disconnects, leaving listeners connected to objects that no longer exist. Check the log file for the last place you raised an error.

Only way to get rid of it is to close / restart live

lx71
Posts: 44
Joined: Sat Jan 02, 2010 5:57 pm

Re: MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Post by lx71 » Wed Sep 21, 2011 9:49 am

Right. I thought it must have been something like this.
I looked exhaustively at my disconnect()s and there didn't seem to be a problem.

This error makes my scripts feel buggy, even after the culprit was fixed, but thanks to your replies, I am more comfortable with it.

Isn't it a bit strange that Live hangs on to these listeners even after everything has been disconnected and then reconnected?
Also, how come it only happens for this one event? I'm sure there are other similar listeners that could cause this issue, but they don't seem to.
I suppose there is no way to tell live at the beginning of a script, to drop all these hanging ones, is there?

Thanks again,
Alex
Check out the UltraDevice http://vimeo.com/21841158. A DeviceComponent with more than 8 controls!
Here is my music: http://soundcloud.com/goalex

amounra93
Posts: 431
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: MixerComponent.on_selected_track_changed (MidiRemoteScripts)

Post by amounra93 » Thu Sep 22, 2011 8:39 am

To be honest, this only ever happens to me when I have a script loaded, edit the .py and save it, then reload the same script without restarting Live. Doesn't seem to matter how 'correct' the script is, I often encounter all sorts of weirdness with the _Framework when doing this. It can, though, be simply incorrect disconnects when you're encountering it outside the circumstances I mentioned.

There's no way that I know of to disconnect all listeners (it's not 'cached'), and I doubt there ever will be. You just have to keep an eye on what you've done, and undo it on disconnect. Keep in mind that even though you may not directly set up a listener, some routine of a sub-class may do it without your knowledge.

a
http://www.aumhaa.com for Monomod and other m4l goodies.

Post Reply