Yes. The interval [-x,x] is double the size of [0,x], so a step of 10% will be the double size on [-x,x] as on [0,x]. I am missing something?
Edit: I will change the unit in parameter tooltip of the “STEP” knob from “V” to “%”. Although “Volt” has the same meaning on the input range 0…10V adding percent symbol makes it clearer what stepping means.
getMinValue() < 0 ? interval /= 2; : interval; or something?
There should be a multiplier that works for [-54, 54] but just can’t find it atm some VCO’s frequency knobs are [-3, 6] not sure what this will do to the multiplier.
configParam([...] 0, 2, 0.2, "Multiplier") might work better than “V” or “%” imo.
Actually this would be a bad idea. I’m doing none of these calculation myself, I’m using ParamQuantity::moveScaledValue() and ParamQuantity::setScaledValue(). The implementation of ParamQuantity defines how the range [0,1] or 0…10V is mapped onto the parameter. Any developer can overwrite these functions and make something more complicated than default linear knobs. I have no intend in breaking these things.
We’re moving this discussion to somewhere else, so everyone else: your feedback is welcome!
I think I will release 1.5.0 of PackOne with several new modules and improvement in a week or two. Mostly the manuals need some love until then…
I fear that I am missing something in the way Midi-cat works so the following may be entirely redundant!
I have been building some TouchOSC templates that I would like to make publicly available for others to use. I became lulled into a false sense of security by testing them in a single patch without thinking through how things would work when trying to produce a generic setup.
What I am trying to achieve is the distribution of a (set of) TouchOSC file and a matching Midi-cat preset, to avoid the user having to do any of the tedious mapping that puts people off using TouchOSC in the first place. I want them to be able to use this in any patch rather than just distribute a patch where everything is correctly mapped.
This I now realise does not work, but there is a workaround. Midi-cat records the ID of the module it is referencing both as the ‘rightModuleID’ and as the ‘moduleID’.
Within a single patch as long as the mapped module does not change its ID you can recall the preset and everything is mapped and works as expected.
Start a new patch, however, and the module you want to map will have a different ID and the Midi-cat preset will not work (in the sense that it will not be mapped).
This can be fixed, however, by saving a preset for the mapped module, solely to get its ID, and then opening the Midi-cat preset in a text editor and searching and replacing the instances.
Saving and reloading the preset will then fix the problem and everything will be nicely mapped again.
That is obviously quite involved and not a hoop that many would want to jump through. For a module with a few CCs mapped you might as well just remap it. However, I have an iPad Pro template with 128 CCs (a mixer) and mapping that is not an experience you would want to go through more than once!
As I said, I might be missing an easier solution here, so I would be glad to hear it if I am. Failing that, is there some way the module could be enhanced to deal with this problem?
Obviously dealing with a single module template is a restricted use case but one that can always be referred to in the rightModuleID. I doubt there is an easy solution for a performance TouchOSC template that mapped parameters on multiple modules. Nevertheless, a solution for the ‘module to the right’ would be massively helpful.
Save as Template + a Load Template might negotiate this… Rack v2 FR?
Yes, this is a bit of a problem. Parameter mappings aren’t really transferable and presets for MIDI-CAT (and so MIDI-MAP) are kind of useless or need tedious manual fixing. You can try using my STRIP module and save the mapping and all the modules with mapped parameters. I implemented my own thing to repair the mappings within a strip.
I guess I was just hoping you could work some of your magic with some ‘magic wiring’ or somesuch. I was sure that the problem would have occurred to you already. I will look into Strip. Thanks.
Just sent a small donation for these. Have a beer or something on me!
My initial experiments with using Strip in this context are yielding positive results,
However, am I right in thinking that if one opens a saved Strip in a patch where there already exists modules that have been assigned those IDs by Rack then there will be a conflict and I will, for example, end up controlling more than one module with my controller ?
No, the modules in a strip will get new Ids. My module basically automates adding a bunch of modules and wiring them up, there won’t be any conflicts with the rest of the patch.
Additionally I fix the mappings by replacing the old Ids with the newly assigned Ids. I implemented the same process you described before in STRIP by inspecting the Json data and replacing some fields. Unfortunately there is no API or something for this but it works quite good this way. At least until v2 
I just figured out that was what was going on. Very clever ! (What had caught me out in thinking about this was that when loading the same Strip twice TouchOSC controls both mapped modules - but it would of course, because the relationships/mappings are preserved. )
Let’s hope nothing gets broken in V2 then
Thanks for your help, and for the modules !
I’ve thought about this and it would be a good feature to have but the solution I am after needs to be independent of patches/templates. I think Ben’s suggestion is going to work for me.
Thanks for the idea though !
Also big thanks for adding the dark theme mode, and… hiding the yellow midi mapping dots setting!
Quickly tested MIDI-STEP + PILE + μMAP on a Nektar Panorama P4, which has 16 infinite encoders.
It works well! INC and DEC seem swapped around, but it’s trivial to fix by crossing the wires.
You have to set up the encoders first. The procedure is as follows:
The same procedure is almost certain to also work on the Panorama P1 and P6.
I am not sure if this has already been discussed. It looks like the MIDI note toggle mode in MIDI-CAT is not working. Or am I just misunderstanding how it should work?
I was expecting that if that is turned for a control slot, each new note on message would toggle the assigned control. Say, for example, a mixer’s mute button is assigned to that, each MIDI key press would toggle the mute on and off in turn. Now it just appears to turn on the mute at the first MIDI key press and nothing happens with subsequent presses.
This is a bug in the current release and has been fixed already for the next version.
Just tested with Beatstep Pro Rel 1 mode and works like a charm!
@stoermelder would you consider adding polyphony to Pile, so I don’t have to create 16 instances of it? 
Bit of an edge case this one, but maybe there is a solution.
I have a TouchOSC template intended to be the single knob for SAIL. A simple fader works fine of course. However, I want to have three faders. One relative one the full height of the phone for fine adjustment (CC 0), one relative half height for rapid full range adjustment (eg in a performance) (CC 1), and one half height absolute fader (CC 2). All are sending feedback out.
It works, after a fashion, but there are, of course, conflicts, where moving one fader updates other faders, but not to the correct position.
Is there a conceivable way round this - eg by declaring that the Midi CC has priority (while being adjusted) and the other CCs must copy the underlying absolute value reported. SAIL is a single control solution so in this instance where more than one CC maps to the same parameter could this be intercepted in SAIL? I hope that makes sense.
EDIT: Solution found (set all faders to CC0 on TouchOSC0).
Don’t think faders can be relative. Relative mode is for infinite encoders something faders lack because faders need a start and end position.