Linking CC messages coming from a midi controller to some parameters in a m4l device causing buggy behaviour in hardware synth

    Jun 29 2020 | 1:36 pm


    1. I Want to control a hardware synth ( Yamaha reface dx ) with my midi controller
    2. Some of its parameters are already controlable with cc's
    3. some of its parameters are only controlable with hex sysex
    4. I build a custom template for my midi controller ( novation launch control xl ) so it can control the CC ready params ( So for example if the Yamaha Reface DX param Y is controlable with CC 80, i set a knob on my Novation to send CC 80 ), this part is working obviously.
    5. I build a m4l device, so I can control with my midi controller the rest of the non-CC parameters ( so for this matter the m4l device recibes some CC values from the controller that i tie to controls in the device that then send sysex messages )
    6. I build the m4l device in a way that you can also control the sysex parameters with UI controls in the device.

    The problem:

    • Some of the controls ( marked in RED in the patch ) have a buggy behaviour in the real synth when using the controller, while apparently are changing correctly the values in the m4l ui elements ( live toggle, or live menu ). ( while other controls using this same technique are working perfect: in BLUE )
    • BUT if I change directly the live toggles or live menu without using the midi controller, the synth doesn't present the buggy behaviour. So if you compra the use of the device with the midi controller, or hands on with the m4l device ui the behaviour is the same. But the Synth only represents this changes correctly when using the straight ui controllers.

    The question:

    Is there a better way to do this? My main goal is to have a midi controller capable of controlling the sysex params in the synth ( without midi mapping at first, because the cc's are already controlling the params in the device and sending sysex ), while keeping all the benefits of a m4l device controls ( such as automation envelopes of this params etc. )

    The patch:

    Any help is much appreciated! THANKS! ;)
    ( This user helped me a lot with the sysex control of the reface, mentioning in case he can help CHAPELIER FOU )

    • Jun 29 2020 | 2:32 pm
      I don't have a reface dx to try this with. What do you mean when you say "buggy behavior"?
    • Jun 29 2020 | 2:37 pm
      could it be that you have to disconnect direct midiin to midiout connection ?
    • Jun 29 2020 | 2:46 pm
      As stated above, it could be a MIDI loop is happening somewhere.
    • Jun 29 2020 | 6:56 pm
      Thanks for your quick answers and help!!!! @jeremy : I made some changes to the patch so I can explain myself better ( you'll see that there's a toggle to enable "auto cc mapping", when its off everything is fine but when it's on and I play with the controller sending the cc values there's when the error comes after playing a bit. Also I recorded a video so I can show you the problem.
      See the new button auto cc maping
      See the new button auto cc maping
      see how this button enables or disables the auto mapping of cc incoming values to certain controls
      see how this button enables or disables the auto mapping of cc incoming values to certain controls
      Also, the video link to show you the problem: @source audio: If I disconnect the midiin from the midiout, the normal midi notes wouldn't flow from the keyboard to the synth, so I think It's correct as it is. ( may be I'm wrong? ) @chapelier fou: It smells like a midi loop but I don't understand why.
      I think I'm trying to solve the problem in the wrong way, this thing of wanting to have my midi controller all set without midi mapping and controlling some parameters in the m4l device, that can also be controlled with UI.. i don't know..
      huge thanks to everyone!
    • Jun 30 2020 | 7:04 am
      It is difficult to analyise your problem without knowing how the midi flows between controller, live and yamaha. But one thing is certain : if you use some CC# numbers to generate sysex, you shouls at least filter them out from direct output to yamaha. You use bunch of midiselect objects, and quite unefficient... Try this :
      I am not sure if that midi CC#s are the cause of the problem but filtering them out won't do any harm
    • Jun 30 2020 | 1:25 pm
      @source audio WWOOOOOWWWWW! Thank you so much!!!! Your approach completely solve the issue. Also learned some things regarding the midiselect object with your patch.
      Now I'm facing other related/collateral problems regarding how the general automation is breaking when recording a performance using the midi controller sending the cc's to the device:
      Once recorded the perfomance, automtically breaks the general automation
      Once recorded the perfomance, automtically breaks the general automation
      I guess it's due to having a live.numberbox or whatever other live. object, that comes packed with features regarding automation envelopes from live, but that at the same time is being controlled by CC's within the m4l device. ? Am i trying to tackle the problem in the wrong way? Thanks again!
    • Jun 30 2020 | 3:12 pm
      I am glad that this solved the issue. I must state that I am not using Live and so am not the right person to give advices regarding any Live issues. But if You don't want to use any automation , there is option to exclude live.objects from automation. Or simply use standard max numboxes toggles etc. If on the other hand you want to record automation than both sources - recorded automation and incoming CC# are both going to manipulate the objects, and in that way the sysex. Another thing - are you also recording the incoming CC# values into track, and playing that back ? And what is the track midi monitor set to ?
      I guess all that comes into play, but I have no idea how that works in Live.
    • Jul 01 2020 | 8:23 am
      In the inspector window of the live.number boxes, in "parameter visibility", select "hidden" or "stored only" ?
    • Jul 03 2020 | 8:27 am
      @source audio: - Using max numboxes etc.. solved the thing also. ( with the compromise of not being able to record automation with the live.controllers in the device, but only using the midi controller, that could be finallye the good option ). - Recorded automation of incoming CC's is being recorded in the track - The track monitor is activated to IN @chapelier fou: May be i build some toggle in the device between exposing or not exposing visibility.. let you know if that combination works, Thanks anyway! Thanks Both for your help. I'm happy with the results.