Linking CC messages coming from a midi controller to some parameters in a m4l device causing buggy behaviour in hardware synth
Context:
I Want to control a hardware synth ( Yamaha reface dx ) with my midi controller
Some of its parameters are already controlable with cc's
some of its parameters are only controlable with hex sysex
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.
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 )
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 )
I don't have a reface dx to try this with. What do you mean when you say "buggy behavior"?
could it be that you have to disconnect direct midiin to midiout connection ?
As stated above, it could be a MIDI loop is happening somewhere.
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.
Also, the video link to show you the problem:
https://www.dropbox.com/s/xnsdukekb6d37bd/Buggy-m4l-device.mp4?dl=0
@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!
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
@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:
Let me show you the issue in a video here:
https://www.dropbox.com/s/0cnuwf1rqp1e04e/Reface-breaks-auto.mp4?dl=0
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!
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.
In the inspector window of the live.number boxes, in "parameter visibility", select "hidden" or "stored only" ?
@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.