Parameter map weirdness

Developers
1

The general question is – what changes the values in the parameterMap for a device?
I know programmatically you can use parameterMap.set(), resetDevice(), and resetAll(). Are there any other automated/behind the scenes things that can change it?

Why would the parameterMap get cleared out/reset in between these two steps?

      local pData = 0
      for i=47, 165, 2 do
         pData = makeData(deSyx[i], deSyx[i+1])
         if (i < 69) then
            print(string.format("in data: i = %d, pData = %d", i, pData))
         end
         parameterMap.set (1, PT_VIRTUAL, i, pData)
      end

gives:

19:01:06.469 lua: in data: i = 47, pData = 562
19:01:06.480 lua: in data: i = 49, pData = 552
19:01:06.485 lua: in data: i = 51, pData = 448
19:01:06.489 lua: in data: i = 53, pData = 531
19:01:06.492 lua: in data: i = 55, pData = 527
19:01:06.495 lua: in data: i = 57, pData = 479
19:01:06.498 lua: in data: i = 59, pData = 518
19:01:06.500 lua: in data: i = 61, pData = 512
19:01:06.502 lua: in data: i = 63, pData = 512
19:01:06.503 lua: in data: i = 65, pData = 512
19:01:06.504 lua: in data: i = 67, pData = 512

and just after:

      for i = 46,50 do
         storedVal = parameterMap.get (1, PT_VIRTUAL, i)
         print(string.format("pMap data: i = %d, storedVal = %d", i, storedVal))
      end

yields this:

19:01:06.505 lua: pMap data: i = 46, storedVal = 200
19:01:06.506 lua: pMap data: i = 47, storedVal = 0
19:01:06.507 lua: pMap data: i = 48, storedVal = 200
19:01:06.510 lua: pMap data: i = 49, storedVal = 0
19:01:06.513 lua: pMap data: i = 50, storedVal = 200

It’s probably something stupid I’m doing or maybe controls on some other page or ???

2

@oldgearguy I guess this is part of the PCM70 preset. I should be able to see that behaviour when I use the preset and will send the sysex files (you provided to me earlier) to E1. Is that correct?

E1 clears the parameterMap entries that are affected with the incoming patch request response data. As you use virtual parameters, they should not be affected. But I will check…

3

I think I know the issue.

If I have controls defined that had parameter numbers assigned to them in this range, that would cause a reset to their minimum even if they were on a different page, correct? The 0’s are understood because I was only using the odd numbers in the parameterMap. So a control on page 7, even if I’m not using it, will be set to the minimum value of the range and this will cause a change to the parameterMap at that offset. It doesn’t matter if the control is virtual or not I think.

If I understand the parameterMap correctly, it is the data structure that is referenced by any/all controls with a parameter number assigned to it. The idea is that if a control (mapped to a parameter number) is changed, the parameterMap data structure is also changed at the same time. This gives developers an easy way to populate controls from a sysex receive and also a convenient way to collect up any changes and send it back to a device.

In my case, the same byte offset in a sysex dump from the PCM-70 is mapped to different parameters based on which algorithm is being used as a basis for the delay or reverb effect.

Since each parameter may have a different range and data type, this makes some aspects of the preset more difficult. In addition, the data to be sent back to the PCM 70 for each control is actually based on the position in the displayed matrix, not on the byte offset in the system exclusive dump.

So - I think I know what’s causing it and my struggle up to now has been trying to use the parameterMap data structure for multiple things and trying to interleave them in such a way that would make populating initial values and then changing them easier. In fact though, I really need to rethink the approach since it’s now clear I chose poorly.

1 Like