Bidirectional Feedback for MIDI controllers

2

Comments

  • Thanks so much for the clear responses.


    Bidirectional might not be as important as I think right now anyway. Would be amazing for some things but I can probably wait. 🙏🏽


    This is the first thing I've tried to do with Drambo that is just not available yet, that's pretty incredible in my books.

  • To get a pseudo feedback with midi controllers one has to send the midi controller information that lights up it’s pads or buttons, generally speaking that requires using midi notes and cc messages.

    For sysex messages then you will certainly need third party software, Mozaic for example.

    I’ve done extensive mapping of my projects and I use midi notes and cc messages

    to light up the pads on the launchpad X, Launchcontrol XL and the Behringer X-Touch.

    Here’s an example from when I first started experimenting;

    This particular piece simple uses midi notes played into the sequencer in dRambo.

    Simply use a Midi Out module to send the notes externally though you can set it up in the Track settings.

    For switches telling one when something is on and off it does get more intricate as you have to do it per note.

    i.e for the Launchpad that’s 64 notes therefore 64 switches.

    Here’s another example.

    This project is a 32 step input sequencer using the LaunchPad X.

  • Sorry to revive this thread, but is LED feedback midi mapping still in the works? This is currently the only thing that I'm missing in Drambo. Being able to midi map controllers with LED feedback would be really awesome.

  • Now worries.

    We still have to DIY using the inbuilt modules.

    What midi controller or controllers do you have?

  • After building a solution for this with Drambo modules, I found it too brittle and cumbersome for my uses. I now use a MIDI controller that sends incremental MIDI messages instead (Faderfox UC4/EC4).

  • Agreed. I'm still voting for a more streamlined solution that allows for custom control surface adaptions like in the free "Mixxx" DJ software.

    Looking back at how different people use Drambo, there's no such thing as the perfect Drambo hardware controller: Some would want a DJ style controller with crossfader to get that breakbeat & scratching session going, with track mutes and pattern selectors, others would want a 16x8 step sequencer to program drum and bass beats and yet others just want enough knobs and buttons for controlling synth and effect parameters.

    Drambo could even use the same adaptions as Mixxx does.

  • edited August 2023

    It seems odd that this hasn't been implemented yet tbh. I'm currently using Drambo with a LaunchControl XL. This seems like such an obvious and necessary feature for Drambo. I want to be able to map the sequencer to controllers. I suppose the only thing we can do is hope this is being worked on (fingers crossed).

  • Correct me if I'm wrong. But isn't bi-directional midi control something you can only achieve if you have access to the sourcecode of the hardware controller? Midi is very much a one-way protocol. That is why midi-controllers that do have bi-directional control are created for a certain software, e.g. Maschine or Push.

    I've seen people build their own diy controllers for specific hardware. I'd crowdfund a controller made for Drambo. Even if the integration is just a quarter as deep as it is with a Maschine.

  • edited September 2023

    You are wrong :-)

    Bidirectional Feedback means:

    • You MIDI-learned a hardware knob/button to a parameter, virtual knob/button
    • When you move the hardware knob it changes the parameter on the iPad by sending a MIDI value on the MIDI-learned Channel and CC
    • BUT, when you move the virtual knob on the iPad or change the parameter by, lets say, loading a new preset ...
    • ... the according value gets send to the hardware knob ... on the same MIDI-learned Channel and CC

    So the hardware knows the new state. This is essential for rotary encoders or buttons that can light up to show a state. It is also essential for external software MIDI controllers like TouchOSC.

    If the hardware does not know the state, you have to manually change your hardware knob positions every time you start, worked with an other project or changed a preset. Every hardware will be degraded to potentiometers. And even worse, while you realign your hardware knobs, you change your parameters in the software.

    I decided long ago to go all-in iPad. Dynamically changeable touch control surfaces are incredible. But after some time I really wanted to have something you can feel with your fingers for some parameters. Using a physical controller is unmatched.

    Programming-wise this is super easy to implement. No special code for a specific hardware required. When the hardware listens to MIDI, it will work.

    I love Drambo. Because of this, I hate that this is not implemented.

    I love AUM. Because of this, I hate thats this is not implemented there either.

    But there is one shining light.

    Loopy Pro has it implemented from the start. It just works!

    Therefore i use Drambo only for its internal features, not for whole projects.

    And i use AUM for some fiddeling around, but not for whole projects either.

  • edited September 2023

    But you are also right ;-)

    If you want to control specialized hardware with specific functions.

    Lets say you want to use a Novation Launchpad as a clip launcher in Drambo.

    Then yes, you have to code the communication with the hardware using the specifications of the hardware manufacturer.

    Programming this is a lot of work.

  • @HarlekinX To use a Launchpad as a Clip launcher all you have to do is map the correspond pad on the LaunchPad to a Clip.

    You don’t have to access the extra functions of midi controllers via firmware all you need is the sysex and quite often simply the midi or cc messages that it will respond to and from my experiments I’ve discovered that most of what users describe as bi-directional feedback is basically a ready made easy to go template for whatever midi controller with flashing lights because it’s the interaction with the user that is important.

  • edited September 2023

    Correct me if I’m wrong:

    I bought an Arturia mini lab some while ago. At the time I tried that bidirectional thing, spent quite some time on it, but Drambo doesn’t do sysex yet, so I thought I should have bought the launchpad x instead. I wanted keys, and the minilab is joy, powered by the ipad, rotary encoders, easily mapped, I don’t regret it.

    But launchpad uses note commands, right? So I can get that visual reference? I am almost a total noob in this department so any advice is welcome

    edit: said CC when I meant sysex 🤦‍♂️

    I have the codes for the minilab, and maybe some scripting would get it working, it just became too much effort for the reward

  • @emertz @HarlekinX @gravitas @pedro

    The MIDI spec gives developers a lot of freedom so what happened naturally is that we now have all kinds of controller and value feedback mechanisms, from simple 1:1 CC mappings which are the same for sending and receiving, to weird long SysEx messages controlling all kinds of displays, including LCD graphics.

    Supporting many MIDI controllers would require some kind of simple programming language to adapt to them, otherwise @giku would have to write the adaptions himself which is far too much work for a single developer.

    Supporting only a limited set of controllers is not a good idea IMO because sooner or later, another set of controllers would need to be adapted anyway.

  • Understandable for specific controller implementations, but at least the simple 1:1 CC mapping could easily be implemented and would solve most needs. Encoders, Switches and software-based controllers like TouchOSC.

  • Agreed.

    Though I enjoy creating projects with deep midi controller integration using midi notes and cc messages to light up pads n stuff I realised that it would be difficult in a modular environment to

    create set bi-directional feedback unless the module or modules are dedicated to each specific midi controller and even then it depends upon user purpose.

    Loopy Pro has really good integration because it’s static, dRambo on the other hand can go in

    any direction which is brilliant but it’s also a limitation.

    I wouldn’t mind exploring creating dedicated modules for specific hardware but I think a “simple"

    sysex module combined with the modules we currently have will go a long way to add greater user control.

    Yup, I am aware that a "simple" sysex module doesn't exist but humour me. ;)

  • I personally think Traktor DJ software has the best midi mapping implementation. I have all my controllers mapped with multiple layers/modifiers and it works really great with LED feedback on everything. I'm hoping Drambo takes this direction for advanced midi mapping templates.

  • You can do a lot with existing modules and midi notes and cc messages.

    For instance if you press a note on the Launchpad X in note mode and route

    it directly back to itself then the corresponding pad will change colour.

    So using that principle in itself you can use the Knob, Button and CC generator modules to create visual feedback.

    Mapping Clips as you know is straightforward.

    If you want the controllers to be automatically detect then it's all about using sysex messages and queries.

  • edited September 2023

    At the moment it really is DIY for midi controllers in dRambo if you're up for it.

    My rig is now tight in regards to midi controllers and visual feedback for my needs.

    All of my controllers that send cc or receive cc messages are now mapped with visual feedback.

    It's not a simple task at all but well worth it in the end.

  • edited September 2023

    You misunderstood my Launchpad example. Im not interested in Launchpad integration.

    I want parameter feedback to my Faderfox EC4 encoders.

    I tried, with Drambo modules, to send changes in values that are mapped to a AUv3 synth, back to my hardware encoder. It was mess and didn't work. I probably just dont understand it.

    If you show me an example how to do it, i'm interested.

    But in reality i gave up long ago. This discussion is more than 2 years old.

    As i said, 1:1 feedback should be easy to implement by the developer, because almost everything required is already there. Just listen to a parameter change event, check if the parameter has been MIDI learned, convert the value to the configured CC range and send it to the configured MIDI channel/CC. No complicated module constructions by the user needed. And because time is money and work has to be paid, make it an IAP. I happily would pay 9.99 for this feature alone.

  • i would pay too, without hesitation.. I think Drambo needs more IAPs to support developement…

    But i would avoid thinking “it’s easy to implement” - only Giku knows how much code changes (and potential of introduxing of new bugs) would it mean … in coding, it is not rare case that completely simple thing from UX point of view needs deep refactoring and lot of code changes …

  • I don't think I'm willing to go into hacky DIY territory for large midi mappings. It's already tedious enough when using the right tools, so I don't want to go through that mental torture for many hours or even days 😂. A bidirectional midi protocol with modifiers is simply an essential feature that Drambo needs. Fingers crossed this is being worked on, but it seems like the logical next step in Drambos development.

  • @HarlekinX My apologies in regards to the LP X.

    Yup I could show you but as you say time is money and I'm not the Dev.

    I seem to remember that you had issues with midi communication before with the FaderFox?

    @DrConflict True not many are interested in a DIY setup the same way that many are not

    actually interested in the modular side of dRambo and are simply using dRambo as a host.

    In the main most would prefer simply to plug and play.

    The thing is how do we implement midi feedback to the many midi controllers out there

    in a clear efficient way.

    So first things first we need a list of all the midi controllers that dRambo users use regularly

    and then we need to go through all of those manuals and see what they all respond to

    and then start looking at making modules or midi protocols per midi controller

    and then simplify it in away that users can understand.

  • edited September 2023

    Why do we need a list of midi controllers though? I don't understand your reasoning. Any midi controller can be mapped to software with LED feedback afaik. Drambo simply needs a robust mapping system with IN/OUT and modifiers. It would be far too cumbersome to make modules for individual controllers. This makes no sense to me.

  • We need a list because not every midi controller implements feedback the same way.

    We already have midi mapping.

  • edited September 2023

    Every single controller I've ever mapped worked with the same system. The only difference was the colour values. From my Maschines to my Launch controllers. I have no idea what controllers you're talking about to be honest. I still don't see why we would need a list if people are going to make their own midi mappings anyway. Midi map IN/OUT + modifiers is everything we need for advanced mappings.

  • @DrConflict I'm heading out, we'll pick up this discussion later on. :)

  • edited September 2023

    "I seem to remember that you had issues with midi communication before with the FaderFox?"

    No issues, FaderFox devices are pretty straightforward regarding MIDI.

    But there was a great discussion on the topic of 14-Bit MIDI which is supported by FaderFox for finer value stepping.

  • Agreed whatever midi controller I've used I've been able to map with ease

    however it's the visual feedback that's the issue and that's per midi controller it seems.

    Midi mapping in dRambo could be streamlined for sure so suggestions

    from users will enable this for all users.

    I've created another thread to focus on this alongside this one.

  • As DrConflict says, it's actually pretty straightforward feature: just let users map what MIDI message should be sent when the UI element (button, fader, knob,…) value changes. Also, on project load, Drambo would need to send all the MIDI messages from mapped controls to the controller to sync their states.

    This would work for basic mapping, but in desktop world like e.g. Ableton Live, there’s much more to it.

    1. Handling some sort of scrolling/paging: typically for clip launchers like Launchpad or APC40. You see red rectangle around clips on the screen, indicating which clips you’re currently controlling. Of course, with the same colors of buttons on controller than you see on the screen. This is tricky to do in a generic way, although I have a proposal in my mind how to do it.
    2. The same goes for controlling more tracks than the physical amount of e.g volume faders on the controller. Exactly what Mackie HUI protocol is focused on. That would allow even more controllers like Korg nanoKONTROL and many other similar to be much more useable. It would also require some more substantial changes, since there is currently no mapping for e.g “scroll controlled tracks to the right” and since currently you can map only a buttons visible in the UI, there would need to be some completely other way of mapping, e.g in settings. The same actually applies for point 1.
    3. Another nice feature is “device focus” - very similar principle with “red rectangle” that indicates focused clips, just for devices. Also a thing that works nicely in Ableton live. If you have e.g 8 encoders with LED rings, you can control 8 parameters of the device and optionally scroll to control all the available parameters, without the need to manually map anything and giving you hands-on control to every single parameter.

    So yeah l, this would be the ultimate way to get real value from MIDI controllers with LED feedback (or motroized faders). But it’s definitely not a simple thing. For starter, the simple way mentioned in the beginning would cover at least the basic cases.

  • "For starter, the simple way mentioned in the beginning would cover at least the basic cases."

    👆All standard encoders, value displays, motorized faders and software-controllers like TouchOSC would instantly work automagically

Sign In or Register to comment.