Detect when device is deleted in Live

Apr 23, 2011 at 9:17pm

Detect when device is deleted in Live

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//////

#56544
Apr 24, 2011 at 6:19am

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.

#202759
Apr 24, 2011 at 10:05am

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:

– Pasted Max Patch, click to expand. –
#202760
Apr 24, 2011 at 10:06am

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.

#202761
Apr 24, 2011 at 12:53pm

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!

#202762
Apr 24, 2011 at 4:09pm

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…

#202763
Apr 24, 2011 at 9:46pm

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.

– Pasted Max Patch, click to expand. –

here’s the second:

– Pasted Max Patch, click to expand. –
#202764
Apr 24, 2011 at 10:31pm

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!

#202765

You must be logged in to reply to this topic.