# Lua: Manipulate MIDI message object associated with value object

**URL:** <https://forum.electra.one/t/lua-manipulate-midi-message-object-associated-with-value-object/772>\
**Category:** Developers\
**Created:** [June 7, 2021, 4:14am UTC](https://forum.electra.one/t/lua-manipulate-midi-message-object-associated-with-value-object/772 "2021-06-07T04:14:53Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![shankar](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/shankar/32/463_2.png) [@shankar](https://forum.electra.one/u/shankar)\
**Post date:** [June 7, 2021, 4:14am UTC](https://forum.electra.one/t/lua-manipulate-midi-message-object-associated-with-value-object/772/1 "2021-06-07T04:14:53Z")

</div>

@martin, I would love to be able to manipulate the MIDI message object associated with the value object of a control in Lua. I think I need this to be able to make [my controls dynamic](https://forum.electra.one/t/dynamic-controls-aka-array-of-parameter-groups-sharing-one-set-of-controls/676/5) for Triton, since the sysex data sent on parameter changes need to refer to different ‘parameter ids’ and ‘sub ids’ (Triton MIDI implementation is pretty nasty 😃).

My use case: I am going to have an oscillator selector on screen which allows to pick osc 1 or osc 2. All the other controls on the screen will be now associated with the selected oscillator. For example, after choosing an oscillator, if I change the waveform, the correct parameter change message needs to be passed to either osc 1 waveform or osc 2 waveform.

Normally, this should be easy. But, for Triton, if I pick osc 1, I need to send param id 2A and sub id 01 as part of the param change sysex. If I pick osc 2, I need to send param id 2B and sub id 01 (just one example. these ids differ by control). I can maintain these param ids and sub ids in Lua arrays, but to send the right ones, I still need to be able to update the MIDI message object with these values.

There are a couple of ways to build this:

1. I can have a lua function on osc change, which updates all the ‘child’ control midi message data. This is a bit verbose and may lead to a heavy lua script.
2. If there is an onChange function associated with every control, then I can just update the midi message on the function itself referring to some Lua arrays holding the param ids. Maybe this will be less verbose code-wise?

I see a reference to TransformIn and TransformOut functions in the doc as ‘to be built’, but they sound more focused on changing the midi value as opposed to the midi message object.

---

<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:** [June 10, 2021, 2:14pm UTC](https://forum.electra.one/t/lua-manipulate-midi-message-object-associated-with-value-object/772/2 "2021-06-10T14:14:40Z")

</div>

@shankar point understood. I thought originally that I would stay away from the message object in Lua scripts but the idea is false. I am currently adding some more functionality on handling Message objects, modifications are part of that. I will think about your question from the perspective of the ParameterMap too. I would prefer if we were able to maintain the lists of parameters within the ParameterMap object. It is fast and takes care of repainting of controls whenever it is needed.

> [@shankar](#):
>
> TransformIn and TransformOut

yup, these are meant to be simple value modifiers.

---

<div class="post-metadata">

**Author:** ![shankar](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/shankar/32/463_2.png) [@shankar](https://forum.electra.one/u/shankar)\
**Post date:** [June 10, 2021, 3:56pm UTC](https://forum.electra.one/t/lua-manipulate-midi-message-object-associated-with-value-object/772/3 "2021-06-10T15:56:33Z")

</div>

I fully agree on the parameterMap object. I would prefer to use that, compared to directly manipulating message object. I think your original idea is still valid. Thinking about it, it is a cleaner design to abstract away the message object. In triton, the first problem that I ran into was the fact that it uses two ids to represent a parameter, instead of the typical one id. So, in this case, we will need to have two constructs:

1. A way to represent parameter id as an array instead of just 1 element (with a way to default it to just one element for most use cases)
2. A way to represent a list of such parameters and a reference to the current ‘selected’ parameter id.

Let me know if I totally went on a tangent 😃.