no, i don’ t change default settings,
but i precise i’m on Mac /Mojave , this can change the game…
Sorry, I’m talking about the output on SAIL when I say Voltage! Take a param [0, 1] setting the step to “0.083333V” will step in 0.083333 increments. Knobs [-1, 1] step in half that 0.0416666. [-10, 10] step in double [0.166666] shouldn’t it step in 0.0041666 increments? Fundamental Freq param is [-54, 54] the step multiplier has a remainder of 6 so doesn’t step correctly (54 / 12).
Also stepping a param skips 0.
Edit: I changed Fundamental Freq param to a multiple of 12 [-60, 60] and recompiled in dev this will step perfectly to the Hz value when the step is 0.083333v. Seems to have fixed not finding 0, might be the dev version.
Are you saying it works correctly? I’m not sure if I can follow…
Besides that I added the “step-function” on SAIL for endless rotary knobs found on hardware like the Beatstep Pro. Or for someone who wants to use keyboard events to adjust parameters in fine steps.
I had not in mind to step some params on a VCO in exact octaves. I don’t think it makes much sense to adjust anything exactly because moving your mouse to the next parameter will break it anyway. SAIL is about using your hardware without static mapping in an intuitive way…
I’m can hardly believe that these settings work as expected with MIDI-STEP and SAIL 
But if it does I’m happy 
It works correctly for unsigned params [0, x] it doubles the step value for signed params, it’s a corner case with the VCO possibly: A VCO’s frequency param that is not multiples of 12 when the step value is 0.083333 or a multiple of this, which would also be a multiple of 12. 1v or rather [1.f], a multiple of 0.0833333 (within the rounding error of the tooltip value) I’m saying that when there is a remainder on the min/max value of the parameter compared to the step value it will not step correctly. For Fundamental the min / max is [-54, 54] 108 is a multiple of 12 but because the param has negative values it only counts the absolute value of the knob. The absolute value has a remainder of 6 which throws the step multiple off
54 / 12 = 4.5
12 * 0.5 = 6 the unsigned remainder of [-54, 54]
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…
5 Likes
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!
1 Like
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 
1 Like
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 !
1 Like
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 !
1 Like
Also big thanks for adding the dark theme mode, and… hiding the yellow midi mapping dots setting!
1 Like
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:
- Press the Internal button
- Press the Setup button
- Navigate to Control Edit and press Enter
- Turn the encoder to edit to select it
- Change the message type from “MIDI CC” to “MIDI CC(Rel)”
- Repeat for each encoder (both the 8 fader encoders and the 8 transport section encoders work)
The same procedure is almost certain to also work on the Panorama P1 and P6.
1 Like