MIDI DESIGNER
The only MIDI controller for iPad, iPhone, and Mac


Talk to other MIDI Designer users about MIDI Designer, iOS MIDI and related topics. Or share layouts, pages, and ideas.

Check out our Facebook Group.

Of course, if you want to send us an email, feel free.

Open problem reports

Summary of user requests
Can I share controls with other preset controls? - MIDI Designer Q&A
0 votes
in Defect (Is this broken?) by bba120 (440 points)
edited by bba120
Addtional information about one problem I am seeing:

The three preset knobs each have their own store and recall buttons. Before I added preset3 to the layout everything worked properly in terms of saving and restoring presets.

When I added preset3 I discovered that the store function started interacting between the presets.

For example if I set knobs1-3 to some values and save to Preset1-location20 it also saves in Preset3-location20. I'm sure Preset2 is also being affected but I haven't carefully tested yet to verify the behavior.

This looks to me like a problem with how events propagate through the layout, i.e. the store action is for some reason being propagated past the Preset where it belongs.

I've checked for mistakes like linking the same button to more than one place and find nothing out of place.

I also notice using the example above if I store to preset3.location20 as I describe that it stores to Preset1.location20 even if Preset1 is currently set to another value.
We'll have to research this and circle back, but if memory serves a control cannot participate in more than one preset at once UNLESS the presets' ticks don't overlap. The best way to test this stuff out -- if you have time and inclination -- is with VERY small layouts (two knobs, two preset supercontrols).
Okay, so you can do this if the MIDI VALUES of the named ticks of the preset knobs don't overlap. And since named ticks can have ANY display value... it can basically work however you want. Let me know if that needs more explanation. Thanks!
Here's an example of 6 named ticks in second knob, but you could do 0-11 for the first, 12-23 for the second, etc.

http://mididesigner.com/automatic-images/Second_Preset_Knob.png
Thanks for the answer, I understand what you are saying and it is a possible work around for the behavior.

 To be honest with you I actually wanted to be able to use the entire 0->127 midi/preset range for all three preset knobs and I was planning to have more parameters associated with the knobs.

I'd be interested in gaining more insight into what is actually going on in the software with this.

When there are two preset knobs with no common controls it's all pretty much ok with the exception of a few smaller issues but when there are controls in common then wierdness begins to happen.  As I said above this is one of the things I see go awry but not the only one.

Anyway, since two independent presets work it seems like each preset must be successfully keeping it's own list of values. This and some other things I'm seeing make me think there is something going on with how events are propagated around between the control objects. I'm think the store is propagating to other controls when it shouldn't.

So I'm wondering if you mind giving some insight into how it works.
I'm pretty sure that you can use a 14-bit control to get up 16383 presets... so you could easily get 0-127 for a knob.

To test this hypothesis, you could TWO ticks per preset knob:
Knob 1: 55, 127 (for example)
Knob 2: 128, 666

or whatever. The point is to keep your tests VERY limited.

What's going on under the hood is that the value for PRESET 1 is stored in the control that is affected (the subcontrol) and saved there. So any supercontrol preset knob that hits preset 1 will restore THAT value

make sense?
use NRPN 14-bit in the supercontrol or just use a CC that is lower than 32 and hit "14-bit CC"
Ah ha. I wondered about that but as you can see I didn't think you had actually done it that way.

Are you saying there is a value array for each subcontrol and when the super control does a store it's calling a method or whatever which actually stores the value in dataspace associated with the subcontrol? If so then how big is the dataspace, for example is it 128 locations?
It's not about size. The preset gets stored by a KEY that is a MIDI value, so you could even do 3 bytes in your value and get a LOT of group presets (which is only possible with sysex). Make sense?
Yup. Sounds like you are using a small database manager. I haven't looked at the SDK documentation very much, only a small peek at how the MIDI facilities work, so I'm not familiar with what is all there to help you build the app.  That's a better approach, I guess I might have thought about storing the values with the super control but this is good in a lot of ways. You have a namespace and just map different ranges into different things and it works. It also has the interesting property that you can delete the super control and create a new one and as long as you map the same range all the preset values are not lost except of course the preset names which presumably disappeared along with the super control. Which does bring up a question.... what happens to the db entries if their associated control is deleted? I would assume they are purged?
PS it's also nice because you can have a really large number of entries but only consume space for the ones actually in use.
I forgot to tell you... I changed preset1 and preset2 to by 14 bit NRPN controls and then mapped them at 128-255. I left preset3 as a program change and of course made it use 0-127. Seems to work fine.

One thing I think is a little wierd is that I have a bunch of buttons setup as supercontrols for preset1 which I using to get random access to the presets. What I think would be intuitive is if I could just use 128-255 as the values rather than have to scale the value to fit the control range. I think that probably makes sense for most parameters but maybe not here. Patch change might be another place where it's worth considering.
Yes, how supercontrols scale subcontrols is sort of voodoo right now in MD: you have to do the math yourself, and if the subcontrol is 14-bit and the supercontrol is not, they don't line up at all (except mathematically)... In the future we'll provide more sense to this functionality
glad to hear you're sorted on this issue.
I have some other issues concerning the operation of the presets and their super and sub controls I would like to discuss. Should I continue here or start a new thread?
Unless it's a clear bug, please drop us an email starting the discussion. Also remind us of who you are from here. Use Config -> Actions -> Email Us. Thanks!
...