# Allow setting a parametermap value without triggering a change

**URL:** <https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967>\
**Category:** Ideas / Feature requests\
**Tags:** lua\
**Created:** [May 29, 2024, 7:25pm UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967 "2024-05-29T19:25:03Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![christianvogel](https://avatars.discourse-cdn.com/v4/letter/c/b19c9b/32.png) [@christianvogel](https://forum.electra.one/u/christianvogel)\
**Post date:** [May 29, 2024, 7:25pm UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967/1 "2024-05-29T19:25:03Z")

</div>

Currently, when `parameterMap.set()` is called, it also triggers the `parameterMap.onChange()` . This makes bidirectional Electra-device communication very tricky because you can get feedback loops.

So far I tried having `isReceiving` and `isSending` flags and checking these flags, but even with calling `midi.flush()` before setting and checking, this seems unreliable, likely because handling of messages is asynchronous. Another issue is that such flags are not per control, so to do it well I’d have to write a table of controls and changing state, and that would still not solve the issue fully. Also when many changes come in, or go out, the CPU load is significant.

Suggested: add an extra parameter `ignoreChange` that defaults to `false`: `parameterMap.set(deviceId, parameterType, parameterNumber, midiValue, ignoreChange = false)` , that if set to `true` does not propagate the change to the `parameterMap.onChange` handler.

---

<div class="post-metadata">

**Author:** ![oldgearguy](https://avatars.discourse-cdn.com/v4/letter/o/f4b2a3/32.png) [@oldgearguy](https://forum.electra.one/u/oldgearguy)\
**Post date:** [May 29, 2024, 10:07pm UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967/2 "2024-05-29T22:07:20Z")

</div>

Note that in the onChange() callback, there is an origin parameter. I often use this to discard messages coming from a Lua call or MIDI.

If you have time, put a print() statement in they’re to see the origin of the messages and maybe you can do a simple

If origin == MIDI then return

Kind of thing

---

<div class="post-metadata">

**Author:** ![christianvogel](https://avatars.discourse-cdn.com/v4/letter/c/b19c9b/32.png) [@christianvogel](https://forum.electra.one/u/christianvogel)\
**Post date:** [May 29, 2024, 10:53pm UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967/3 "2024-05-29T22:53:49Z")

</div>

Ah! Very nice, I missed that one. Thanks for the tip @oldgearguy ! Just tested and that allowed me to stop the feedback loops.

The feature request still stands, I think it is better to not have unnecessary calls, and is also easier for the user as an API.

---

<div class="post-metadata">

**Author:** ![oldgearguy](https://avatars.discourse-cdn.com/v4/letter/o/f4b2a3/32.png) [@oldgearguy](https://forum.electra.one/u/oldgearguy)\
**Post date:** [May 29, 2024, 11:32pm UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967/4 "2024-05-29T23:32:39Z")

</div>

Well, I like the flexibility because there are some cases when i am doing internal manipulation of values in the parameterMap and sometimes I want them sent to the device and sometimes not or sometimes I’ll intercept the triggered parameterNumber/value and send some other things.

So, inside the onChange(), I can code the exceptions as necessary.

yes, it’s ugly coding sometimes, but dealing with old gear and system exclusive messages is ugly by nature. lol

---

<div class="post-metadata">

**Author:** ![martin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/martin/32/145_2.png) [@martin](https://forum.electra.one/u/martin)\
**Post date:** [May 30, 2024, 11:15am UTC](https://forum.electra.one/t/allow-setting-a-parametermap-value-without-triggering-a-change/2967/5 "2024-05-30T11:15:24Z")

</div>

yeah, there was a good idea behind that: make sure that when parameterMap entry is updated, it always sends the data out and fires all functions. Later, I realized the idea has these drawbacks. Anyways, to keep things backward compatible I am going to add a few new methods to make more flexible.