Javi Riverola

Captura de pantalla 2020-06-29 a las 15.18.51.png

Captura de pantalla 2020-06-29 a las 15.33.28.png

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. )

comment

print

unpack

midiselect

live.menu

live.numbox

outlet

sxformat

inlet

live.toggle

loadbang

message

number

ctlin

midiout

midiin

panel

( This user helped me a lot with the sysex control of the reface, mentioning in case he can help 

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.

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.

 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. ) 


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 )

Context:
I Want to control a hardware synth ( Yamaha reface dx ) with my midi controller
Some of its parameters are already controlable with

linking-cc-messages-coming-from-a-midi-controller-to-some-parameters-in-a-m4l-device-causing-buggy-behaviour-in-hardware-synth

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!!!!

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. 

Captura de pantalla 2020-06-29 a las 20.28.43.png

Captura de pantalla 2020-06-29 a las 20.31.44.png

Also, the video link to show you the problem:

https://www.dropbox.com/s/xnsdukekb6d37bd/Buggy-m4l-device.mp4?dl=0

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? ) 

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..

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.. 

It is difficult to analyise your problem without knowing how the midi flows

if you use some CC# numbers to generate sysex,

you shouls at least filter them out from direct output to

You use bunch of midiselect objects, and quite unefficient...

I am not sure if that midi CC#s are the cause of the problem

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


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:

Captura de pantalla 2020-06-30 a las 15.11.00.png

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?

@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!

and so am not the right person to give advices regarding

But if You don't want to use any automation , there is option to

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

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

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" ?

- 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

@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!

@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.


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