Allow setting a parametermap value without triggering a change

Ideas / Feature requests
1

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.

2

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

1 Like
3

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.

4

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

1 Like
5

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.

1 Like