Let's fix the MapButton bug !

Questions and discussion about building and using Max for Live devices
Post Reply
chapelier fou
Posts: 4968
Joined: Mon May 15, 2006 12:15 pm

Let's fix the MapButton bug !

Post by chapelier fou » Tue Feb 21, 2017 9:01 am

this topic brought it back to me : viewtopic.php?f=35&t=225215

Any m4l device using MapButton (and its variations) has a saving bug : when you unmap a parameter and save the set, when you reload the set, it's mapped again. I am really surprised to not see more complaints about it.
I remember having tried hard to fix this, but i couldn't find the bug.

Who would investigate ?
MacBook Pro 13" Retina i7 2.8 GHz OS 10.13, L10.0.1, M4L.
iMac 27" Retina i5 3,2 GHz OS 10.11.3 L10.0.1 M4L.

hoffman2k
Posts: 14693
Joined: Tue Jun 15, 2004 6:40 pm
Location: Belgium
Contact:

Re: Let's fix the MapButton bug !

Post by hoffman2k » Tue Feb 21, 2017 9:35 am

chapelier fou wrote:this topic brought it back to me : viewtopic.php?f=35&t=225215

Any m4l device using MapButton (and its variations) has a saving bug : when you unmap a parameter and save the set, when you reload the set, it's mapped again. I am really surprised to not see more complaints about it.
I remember having tried hard to fix this, but i couldn't find the bug.

Who would investigate ?
Its likely because of how the ID is stored and recalled.

Persistent Mapping needs to be in only one (live.)object and it should check the device state before passing it on to the rest of the patch.
Deleting a mapping requires an "ID 0" message to ALL objects that may store the current ID.
Bypassing a mapping works as it should if you followed the first rule.
Using 2 different mapping devices on the same parameter would only work if the devices send their values with live.object. You can have only 1 remote~ mapped to an ID. But you can have unlimited live.objects mapped to the same ID.

Post Reply