Detect when device is deleted in Live
Paul
4月 23 2011 | 9:17 午後
Very simply, how do you detect when - a device that has been mapped to with the live API - is deleted?
What information changes from the devices???
Any example patches would be most helpful//////
Michael Gary Dean
4月 24 2011 | 6:19 午前
There's not really just a 'very simply' answer, in my opinion. I think it depends on your patch. Basically you want to you retrieve the device path after changes in the path data occur.
Abstractions you may find useful are 'M4L.api.GetAllTrackIds', 'M4L.api.GetAllDeviceIds' & 'M$L.api.GetDeviceNames'. You can essential poll the results these return and determine when changes occur.
Post a patch for more help.
pid
4月 24 2011 | 10:05 午前
indeed, mikedean is right, there are so many different ways to do this, depending on context. for info regarding stuff on the track, i use something like that:
pid
4月 24 2011 | 10:06 午前
having said that, if you live.observe the mapped device / parameter, it will simply throw a "id 0" when deleted anyway, again depending on context.
Paul
4月 24 2011 | 12:53 午後
Hey guys.... many thanks for the suggestions and the posted patch.
I will try these in my patch a little later and let you know how things go.... Looks promising!
Paul
4月 24 2011 | 4:09 午後
Hey guys. Still can't get anything useful out of the suggestions....
pid - I pick up some changes with your patch, but I only need to detect when deletions happen. The posted patch seems to bang whenever something changes.
Also it only changes IDs when a device is deleted, but not when a track (that might be mapped to) is deleted!
Mikedean - what do I hook those abstractions up to (inlets) - I know the help files might say it takes a list, but from what?
The dial in the patch posted (attached) below can be mapped to pretty much anything - so I would need to detect tracks, send tracks, master tracks and all device removals of anything that's mapped to!
The patch itself is basically the 'Max Api Map1' patch that comes with Max for Live.
I'm afraid I just don't really get the API stuff and organising the amount of different types of data that come through it. It seems all the objects do the same thing but in a different way...
Michael Gary Dean
4月 24 2011 | 9:46 午後
Here is some of the code I used in a recent Max patch that retrieves path information. I've commented it so you can follow the flow. It will show you the context in which to use such abstractions. Hopefully, it'll provide you with some insight on your patch, as it appears you need to be able to do what my code does. That is, seek out the path to the user selected parameter.
There's two subpatches I'm posting. The first one outputs directly to the second one's input.
here's the second:
Paul
4月 24 2011 | 10:31 午後
Hey Mike!
Wow, thanks very much for all that. Appreciate your time.
Yeah, I think after some perusal I should start picking up the API thing better. I'll have to implement your patch in a project to and see what all the output data is for a clearer understanding.
I have drawn my current project to a close for now, as time is running out. But this will definitely be helpful when I'm able to return and update it - not to mention other projects.
The whole API thing still seems a little delicate to me. It might be my crappy patching, but it's quiet easy to crash Live and Max you want to....
Thanks again. Much appreciated!