Sysex controller preset needs midi capture to start working

Dear,

I have been setting up a MT Pro preset to control an FM synth (Yamaha FB01) with a Livid Code 2 through my Bomebox. It was a struggle to create the patch, but it seems I’m nearly there.

On a first upload to bomebox nothing really worked, but when midi monitoring through MT Pro itself (via midi DIN sockets), all seems ok, except for the fact that I need to initiate a midi capture once, before it actually starts changing values in my sysex strings.

Upon opening the preset and sending Livid Code’s CC messages, it does create the right sysex strings per knob, but it doesn’t change the actual realtime values within them, unless I  enable midi capture (incoming or outgoing) once. After that all is changing and working as expected. Of course, when I connect the bomebox independantly to the FB01, I can’t do such a midi capture so none of the controls work as hoped for.

Is there a way of having the preset immediately work withour this midi capture inference?

I attached the file.

 

Thanks,

Ken

 

 

Hi Ken,

Looking at your project file, it looks like you are manipulating local variables without first setting them.

As an example, look at preset Yamaha FB01  (IN1) Translator [1] OP 1 Decay 1. You are monitoring for any incoming value of CC#9 but you are not setting pp to that value, you then start looking at the value of pp and manipulating it within the rules. Without defining the value initial value of pp (either by incoming value or by setting it in rules), it can have any random state.

I suggest you make sure that if you want to manipulate the incoming value for any of your rules, you set the proper variable.  So you might check for any value and then set pp to value.

I suspect this might be the problem. I’m not sure why it works at all the way it is.

Let me know after fixing this, if you are still having problems.

Steve
bome@sniz.biz
Independent Bome Programming Specialist
Bome Q&A moderator

 

Hi Ken,

Did this help?

Hi Steve,

I think it did. Upon opening the project, the sysex is automatically generated through the Livid controls (connected to bomebox).

But connecting to the FB01 didn’t really work yet. In standalone mode, the bomebox doesn’t seem to receive the Livid’s signals. It has to do with setting up the bomebox midi ports, which seem to act a bit weird. For instance, when Bomebox wifi is on, all led rings on Livid Code flash constantly and I can’t change any controller value, unless I put Wifi off. Any idea what this may be? While I edit the midi ports, they seem to siwtch all the time due to this wifi-Livid interference.

That Livid-Wifi flashing only started to occur, when I also tried to setup Bomebox as a router for my Allen & Heath Qu-Pac. Somehow I wasn’t able to make this work either yet. Is it possible to combine both functions at the same time: router for A&H and midi translator box for Livid-FB01?

I’m off for 1 week, but can test further and update when I come back.

Thanks,
Ken

Hi Ken,

Before we go into the odd behavior of running your project on BomeBox, let’s make sure your project file is good first. It doesn’t make sense to try and troubleshoot BomeBox when the project file is not properly written.

Right now you have translators that will not work. If you are capturing anything that specifies for instance any note, or any velocity, on input, the note and velocity need to set a variable.
——
This won’t work

Input Note-On Any Note Any velocity

Rules
pp=pp+1

Output Note-On Note pp Velocity qq

Because you never assigned the initial note input pp or velocity qq
—-
This will work

Input Note-On Any Note set to pp Any Velocity set to qq
Rueles
pp=pp+1
Output Note-On Note pp Velocity qq
—-
Looking at your project file, there are many translators that do not set the incoming values in variables, but you then later try to use those variables as output.of the translator

Does this make sense?

Steve

Hey Steve,

yes, I had captured that 🙂

I have been changing all these values to ‘pp’ and the project file seems to work fine, apart from some small programming issues (2-3 parameters acting a bit weird).

So were closer to realisation, but the problems mentioned above keep it from working with the FB01 for now.

I’m not in the postion to improve further this week, but I will continue right after. If things work, I could upload the patch if there’s the interest.
Do you have any clues to the other things mentioned?

Thansk for follow up.

Also, if your project file is running, it will set the ports up accordingly so if you change things in BomeBox, then start a project file. The project file will override any input and output ports and routings that it needs to operate.

This is the file with the new corrections.

All translators are changing ‘cc’ to sysex or ‘on/off toggles’ to sysex, so no velocities involved.

You might check it out?

One of the other minor issues is the additive build up of the 4 operators on-off toggles. Their values interact with each other.

I had difficulties making that happen (just notions of programming…), I managed to get it working in some way, but not perfect. You might have a look at this?

The other messages seem to work fine, but didn’t manage to test the full patch in detail (just general testing through miditranslator to FB01).

So for me the biggest issue is the midi ports thing and the flashing leds/uncontrollability of Livid when Bomebox wifi is on.

Hope this clarifies a bit.

 

Thanks,

Ken

 

 

 

 

 

Ok, I see. So I need to attach the bomebox to miditranslator to make the right connections, save the preset and then upload it bomebox tomake it standalone?

Yes, once you have it working on your PC. You need to upload it to BomeBox and start the project there. When you start the project, if you have set any aliases, you will find messages on BomeBox to define the correct output ports for each alias. If you didn’t use an alias and the defined port does not exist on BomeBox, it will prompt you to define the port names you want to use for each of the undefined ports. Then you should be all set.

When you get back or whenever you are ready to progress, just let me know. I don’t plan on going anywhere.

Steve

You more than likely have collision of one or more global variables. I usually define them all in one place so that I don’t mistakenly use them somewhere else.

Hey Steve,

I gave it another try, but am still stuck at the point of not being able to get midi input signal from Livid controls into bomebox in standalone mode.

When I connect Livid (USB) directly to computer and then open the FB01 preset in MTP, Livid controls are processed correctly as sysex messages. Only midi route I set up in MTP is Livid Code Controls as input and Iconnectaudio Midi DIN Output. I’m able to control the FB01 with the Livid hardware controls through MTP. So this way, I would assume things are setup fine and save the preset file, loading it up to bomebox and use standalone.

When I load it up to bomebox and check the midiports/routes, bomebox gives some strange behaviour:
1) When Bomebox-Wifi is on (which is needed to edit it via webconfig), the Livid Leds surrounding the encoders flash all over the place. Livid becomes uncontrolable as to say, until the point that I disbale the Wifi on Bomebox, which stabilizes all leds on Livid and controls seem to function as they should. I’ve already done a factory reset and network reset on bomebox, and tried different presets to no avail. As far as I remember, this behaviour was not apparent when I connected Livid with Bomebox the very first time. It seems there’s some interferencial behaviour between network midi (Wifi) and USB host port on Bomebox. So far my knowledge 🙂

2) I can only use webconfig (with Ipad) when Bomebox wifi is on, obviously. I need Livid to be connected to USB port of bomebox to get the right midiports/routes. As mentioned, this triggers the flashing led behaviour on Livid and in the midi ports window of bomebox, I get intermittantly changing input/output options, changing every 3 seconds let’s say. This is probably caused by the flashing behaviour of Livid, caused by the Wifi-USB interference. This way I can’t edit the ports properly and the basic bomebox ports like USB1 and 2 don’t even appear… So basicly that’s why I’m blocked in the progress.

Any ideas on these matters? As mentioned, I will only be able to verify further on the hardware next week saturday.

Thanks already for thinking it through,

Ken

Hi Ken,

This seems very odd. Is your Lived connected via wired USB or are you using some kind of WiFi dongle?
How is the FB01 connected? Are you using a powered USB hub? How are you powering BomeBox, through the USB hub or with a wall power adapter of sorts? The most common issue with erratic BomeBox behavior is the power source. Many powered USB hubs have special “usb charging ports” that don’t provide consistent power. The cycle current up and down depending on the state of the batteries that are charging. Obviously you would not want to plug into this type of USB port to power your BomeBox.

I might ask that you show me some screen shots of your BomeBox config.

Network
Routes
Ports

I’ll also look at your latest project file but it is probably OK if it is working using MT Pro and a PC or Mac.

Steve

I think it’s more of an issue with the addition rules I use for the 4 operators (OP1 Enable ….. OP4 Enable).
It took me some serious experimentation to come up with what I have now.
It works for the most part, but sometimes enabling an operator, it seems to lose sound (I think mainly OP4).
Then I need to enable it again + disable/enable the others to get back some sound, then it works ok again. It’s a bit vague.

Here’s the rules I use for OP1 Enable to OP4 Enable and their addition of values. They should just simply add or substract their values (and thus interacting with each other) when their corresponding toggle buttons are pressed. I also provide the corresponding outgoing sysex strings per translator.

OP1 Enable:
qq=pp
if pp==0 then qq=0
if pp>0 then qq=8
gl=qq
Outgoing Sysex: F0 43 75 00 18 4B gl go F7
OP2 Enable:
qq=pp
if pp==0 then qq=0
if pp>0 then qq=1
gm=qq
Outgoing Sysex: F0 43 75 00 18 4B gl gm F7

OP3 Enable:
qq=pp
if pp==0 then qq=0
if pp>0 then qq=2
gn=qq+gm
Outgoing Sysex: F0 43 75 00 18 4B gl gn F7

OP4 Enable:
qq=pp
if pp==0 then qq=0
if pp>0 then qq=4
go=qq+gn
Outgoing Sysex: F0 43 75 00 18 4B gl go F7

I hope this clarifies a bit more? Any ideas on how to improve the rules for these translators?
Thanks,
Ken

Hi Steve,
I did some further reading and experimentation.
I decided to connect to power Livid not through bomebox, but powered USB hub to avoid that wifi collision.
Then I only use the midi DIN output port of Livid to go into DIN Midi in of Bomebox. From DIN Output of Bomebox, I go into Iconnectaudio4+ Midi DIN Input and see what happens in MTP.

What I see happening, is that MTP receives plain CC messages, apparently not translating it into sysex, while the preset seems to be loaded in Bomebox. To test this, I use a new, clean preset window in MTP, just connecting Iconnectaudio4+ DIN input to it’s output (See screenshots in next post to show what happens). When I load the corresponding MTP Preset, that translates the messages, turning Livids controls make sysex translations happen correctly (see screenshots).

So clearly, somethings doesn’t translate well in Bomebox.

Since I’m using the DIN Ports on Bomebox, I shouldn’t be adding any midi routes, apart from Bomebox DIN to Bomebox DIN. Is this correct? (see screenshots)

I also ignore all other midi ports, apart from Bomebox DIN in & outputs, since I wouldn’t be needing any others right? (see screenshots, all in next post).

Do you see what’s going on?
Hope it works out. I can still work on it today.

Thanks,
Ken

Her are the webconfig screenshots.

 

These are the ones of MTP.

The thread is getting a bit messy, we might want to clean it up, when resolved.

 

 

Hi Ken,

I will run your project on my BomeBox to see what is happening.  I will use one of my available controllers to take the place of your Livid.

I’m still not clear on how you are powering BomeBox. Could you look at the diagrams below and confirm that this is how you have things set up?

 

One of the issues seems to be resolved.
In Midi Routes, I added an Iconnectaudio4+ to Bomebox DIN route.
This gave good values in a clean preset in MTP. Good!

One step further, while reconnecting all devices, I connected the incoming midi note info to the DIN midi Input of LIVID, then LIVID DIN Out to BOMEBOX DIN Input, then Bomebox DIN Out to Iconnectaudio4+ DIN IN and monitor in MTP.

It gave sysex when using LIVID controls, but didn’t get the note info that should merge with the control values of LIVID.

One phrase in LIVID’s manual grabs my attention:

“MIDI merge
The MIDI jacks on the controller provide a link to external MIDI hardware. By default, they function as independent MIDI translators, and send their data over unique ports on the computer. You can enable MIDI Merge to send MIDI data from the controller’s controls out the MIDI Out jack on the back panel, merging it with any other MIDI data sent to the MIDI Out jack from the computer.
It is worth noting that the same is not true for MIDI input. The controller only responds to MIDI data sent via USB. This is only relevant if your controller has MIDI Jacks. If it does not, the setting is ignored. For example, the OHM RGB Slim models do not have MIDI jacks, but this setting will still appear in the Editor.”

From how I understand: LIVID is using it’s USB port as separate I/O for transfer back & to computer. The DIN I/O of LIVID are independant ports, not connected with the USB port on it.

In the Webconfig of LIVID, there is a ‘Merge midi’ function, but this seems only to be merging incoming midi data (through USB from a computer) with the outgoing DIN Midi data from LIVID’s controls. As far as I can understand then, it seems LIVID won’t merge incoming midi notes from it’s DIN port to it’s DIN out port to get into Bomebox DIN Input. Which would render the entire connection chain non-useable.

The other option would be to send the incoming Midi note data to Bomebox DIN Input. Then Bomebox DIN Midi out to Iconnectaudio4+ DIN Input to monitor in MTP. LIVID would be connected then with USB to Bomebox USB host, merging it’s control values with incoming midi. I can’t manage to get this working, since when I want to experiment with midi routes in the webconfig, I get this flashing LIVID Leds issue (wifi interference through USB), in which no controller info can be send. This is a bit frustrating for now.

The Bomebox is powered by a USB-Hub 5which by itself is powered by AC-adapter. The USB Hub clearly indicates 2 ports for phonecharging and 5 regular ones. Bomebox is connected to one of these regular ones.

LIVID CODE doesn’t have a separate AC Power Adapter input. Instead it uses it’s USB port to get powered. You have to know that LIVID CODE is originally intended to work with a computer, not as a standalone unit. In a big firmware update, they implemented standalone mode (and this works), but there are some quirks, like no separate power adapter input + the DIN Ports doesn’t seem to be connected internally with the USB I/O. I think this is problematic for my setup, as I want to avoid a computer in the chain. That’s why I bought LIVID, Bomebox and MTP in the first place. It looks like a great match, but I fear problems are in the details here.

Another thing in configuration, is that I created the MTP Preset to be able to edit 2 FB01 instruments (on midi channels 5 and 6), where I use a ‘shift’ translator to go to the second instrument layer (as seen in one of the MTP Video Tutorials). This way, I only need 2 banks, instead of 4 on LIVID.

Would it be possible that LIVID doesn’t get enough power when Bomebox Wifi is on? If this is the case, there is no other way for powering the LIVID, since it’s power comes from Bomebox…

a quick note on power: we do have occasional reports that WiFi can lower the voltage of the USB host connector slightly — depending on the stability of the power supply of the BomeBox. It cannot pass on more than it gets minus what it needs for itself. Trying a different micro-USB power supply for the BomeBox might help. The best solution is a PoE injector, which provides rock stable 5V at the BomeBox USB host connector to attached USB devices. We recommend this one:
https://www.bomeloft.com/shop/poe-injector-digitus
It has the additional advantage that the power plug cannot unplug accidentally.

Hi Ken,
Can you power the Livid via another USB port on the hub and still use DIN to communicate between Livid and BomeBox? That way both BomeBox and Livid would be drawing power from the USB hub and that shouldn’t effect the power output on the BomeBox.

I ran your project on my BomeBox and it worked flawlessly.

I assigned the input and output ports to my Network MIDI and sent MIDI CC messages over the network and received Sysex messages back.

I didn’t yet check your code on the translators you said were having problems.

Good to see the preset works in your setup.
Yes, I can power Bomebox and Livid separately, I had that work too.
Main issue is how I can merge incoming midi notes with the Livid/bomebox sysex data out to FB01.
I’m still searching for something that would work.

Now I found a way to send the Livids data over USB to Bomebox, while it stays powered well, avoiding the wifi issue. I removed the USB hub completely and now Bomebox gets powered directly by Iconnectaudio4+ USB host. Problem now is that my computer doesn’t recognize my Iconnectaudio anymore, so no connections are found in MTP. This should work though, since there’s another USB port on Iconnect (not a host) that is connected to my mac. I thought it should be able to get recognized this way in MTP?

On my version of the file you sent, gm is used in both OP2 and OP3, gn is used in both OP3 and OP4.

The logic you show above looks sound assuming your output is correct. OP1 and OP 4 seem to be sending out
the same parameters gl and go

Steve

You can use MT Pro project in the Bomebox to FB01 by setting up another route. As long as you have swallow set on all your translators, then anything not swallowed by a translator will pass through the default routing untouched.

BomeBox is only a host, not a device. The micro USB connection is for power only.

You can still use Network MIDI port to look at BomeBox from your computer (MTP)