Are Increment/Decrement Parameters Supported?

edited September 2017 in Support
I'm just playing about mapping Macros to find a configuration that I get on with.

I absolutely loathe endless 360 dials which send a MIDI CC over a control range, especially when you're switching between different banks of parameters.

All my controllers support sending Increment/Decrement NPRN info. BM3 mapped the dial in Focus Actions, but didn't seem to react to it. Is BM3 compatible with this, or should I open a Feature Request?

Oscar

Comments

  • I think i saw elsewhere that they were looking in to NRPN (But i am not 100% on that memory)

    Personally i am opposite, i despise NRPN, but that harks back to actually designing software that had to support NRPN haha.
    Just out of interest, why do you need that sort of resolution ?
    MIDI CC can be sent in Increments/Decrements, even on encoders by the way.

  • It's not so much resolution that I lack (although I certainly wish I could use 'fine tune' dials with a higher res, but that's beside the point). I don't really get on with 'static' values on controls that don't have some kind of physical or visual mechanism for knowing where in its range you are. For example, even though they're nice and visual and I could use the 'preview' function to smooth them out, I map all faders across all control banks to the same parameter numbers. I can't deal with controls whose parameters aren't represented by their physical position.

    Endless dials don't have that same problem as they don't need to 'hold' their value physically, but come with their own issues. Having no reference to where in their range they are left is just a total headfuck in a performance - I'm thinking about soooo many things, remembering vital technical compositional preparations, playing different things on pads and keys and often a guitar or bass, so I just can't spread my attention thinly enough to look at little LCD screens or pay close attention to exactly which control bank I'm in.

    Also, a lot of these controls tend to be mapped to parameters which are saved to a 'middle value' in the projects they're saved in, so when you touch the dial - BAM, big parameter jump, possibly a different dial or a different control bank to the one you intended to operate and then you've got to to fine tune that parameter back to where it should be (on stage, almost definitely with sub-optimal stage monitoring) before picking up where you left off.

    That's just a few 'off the top of my heas' examples of how 'static value' endless dials fuck with me. To be honest, if I could just do the same with dials as I have with faders (all control banks mapped to same values, so that only button and pad functions which change colour with the active bank vary) then I'd do it in a second. That'd give me 12 dials total, which along with the other misc controls I have available to me is enough for prepared performance.

    A simple system of 'move the dial, the parameter moves from its current value in the direction you moved it' would be MUCH more practical for me.

    Are you saying I can operate dials in BM3 in this way using standard MIDI CC? (and that it's currently supported?). I'm not sure if one of my controllers can do that, but the other might. I'll have a play.

    I've *more or less* accepted that I'm just going to have to bite it and practise with a fixed layout until I get used to it (with creative range mapping in BM3 and AUM and some familiarity, I can minimise the potential problems) but I'm exhausting all possible alternatives first.
  • No i was just saying that NRPN is not needed for pots, pots will work with CC/NRPN/SYSEX a message is a message is a message, as it where.

    As far as i know (Haven't tried, but read from others) BM3 has a soft takeover when its dials are MIDI controlled via CC, so should work better with pots than encoders anyway, I am pretty sure that encoders don't work well at all with BM3 from what i have read.

    As for fine control, from a user standpoint, it is much better using two MIDI CC to create fine control than using NRPN.
    Example
    NRPN =16384 values on a dial, you think you will ever find any one of those values ?
    Two MIDI CC = 128x128 (16384) values, super easy to find one of the 128 values, now press a button that has another MIDI CC, this dial now becomes fine values.

    As you can see, the MIDI CC has the option of course and fine setting, it is a much better way to work and works very much like VST plugins do with there fine control key shortcut, also it is less intense on the MIDI cables (MIDI is a crap old standard that we push to the limit)

  • Yeah that does make more sense. I'm not really worried about fine control though, as it's all in the moment anyway - ballpark is good enough and 128 values is enough for that.

    My main concern is the logic of how moving the encoder moves the macros/parameters in question. I'd much much rather just have each dial instruct the software to 'move up/move down' that to send a specific value based on what it was last set to. That's what I mean!
  • Yeah i'm a little lost again, sorry.
    A pot (as far as i know) in BM3 right now has soft takeover, so the dial in BM3 will only move when the pot reaches its matching position.
    An encoder will not work at all with this system, because it has no matching position (Endless rotary)

    So, what you have now is an encoder controlling a dial in BM3, and it is jumping about when you adjust it ?

  • edited September 2017
    I tried my second controller (which has a different way of sending relative encoder info - basically just sending a max or min CC message as far as BM3 is concerned). Defo doesn't play with BM3.

    I don't have any software or hardware issues with jumping parameters, but using absolute values from endless encoders isn't really that great for live performance. Especially when saving and recalling patches where the values mapped to those encoders are saved at middle range values and the encoders boot up at '0' (this is when jumping occurs - though BM3's pickup behaviour definitely does improve that a whole lot!). In general though I'd prefer to use relative messages where the dial is just telling BM3 'up' or 'down'. I don't think this is possible so I'll experiment a bit more to get to grips solidly with what's there, then post a feature request for a relative/absolute encoder behaviour option.
  • edited September 2017

    Yeah i think this is a feature request Oscar, I don't think BM3 even supports encoders properly because of the soft takeover, i may be wrong, but i have seen it mentioned elsewhere.

    For the record, encoders should only ever be up and down, nothing else, thats their job, so even if its not a feature request its a bug.

Sign In or Register to comment.