How to get rid of bogus aliases

sjcaldwell

2016-11-06 00:39:34

Hi,

I frequently have to go into to my web browser after powering up bome box because midi ports aren't assigned correctly.
When I look at my ports screen there are all sorts of bogus aliases. How do I clear out the old ones?

To fix I have to go by trial and error to open up each of the aliases until I find the one that works. Then I'm good until the next restart.

florian

2016-11-07 15:20:24

oh, I wonder what's happening there!

The BomeBox normally:
  1. remembers port alias definitions
  2. hides/removes remove aliases that are not in use
Now of course, if your project file contains such bogus port aliases, they'll be recreated each time you start the project. So I assume that your project somehow includes such bogus aliases...

You can try this: close project file, power cycle the BomeBox. Now when looking at the MIDI ports, there should only be the existing MIDI ports. If the bogus ports reappear when loading the project file, you've found the cause...

Note that the routes (route sets) might also create port aliases. If all that does not help, could you post a screenshot of the web config's MIDI ports page? And attach the project file?

Thanks,
Florian

sjcaldwell

2016-11-07 15:48:45

See attached web config and project file. Zipped the mhtml file because this BB would not take it.

Note both the A-PRO and VI-61 expose two ports so maybe that is the issue. The second port is usually set up for programming the devices

However on last reboot they were assigned incorrectly and the NS2 (Nord Stage 2) was the problem.

Also, I often do not have the A-PRO turned on. So if there is some logic that breaks if one of the assigned devices is not connected, that could perhaps pose a problem.

Pretty much everything attached goes to the Nord Stage 2 device. In the future, I will be selectively routing to the NS2 and the Hammond SK2 (connected via DIN and also not always powered on).

The aliases I created are "NS2" (output - Nord Stage 2 Midi), "Triton Extreme"(input and output) and "FCB-In" (input mio). They are all USB devices.
Attachments
BomeBoxSteve - MIDI Ports - BomeBox.zip
(13.94 KiB) Downloaded 144 times
FCB-1010-13Map-2016-10-25.bmtp
(29.51 KiB) Downloaded 149 times

florian

2016-11-07 21:08:48

Hi,
thanks for the great info and the files. So the general "promise" is that the BomeBox will always behave the same when power cycled. If it doesn't do that, it's a bug and we should fix it in a firmware update. I'll note it in our bug database.

In general, the BomeBox (and also MT Pro) do it like this for all MIDI port (aliases) in a project file (the "project port"):
  1. Does a real MIDI port exist with exactly the name of the project port? If yes, use that directly.
  2. Otherwise, does a port alias exist with the name of the project port? If yes, use this alias. if the alias has a pre-defined assignment, that real port is used.
  3. Otherwise, create a new (unassigned) alias.
Then, if 2) and 3) yield any unassigned, used, aliases, prompt the user to assign them. Once assigned, the assignment should be remembered "forever".

So I'm not sure what happens in your case. Only 1) and 2) should happen after initial setup. If a used device is not plugged in, it's set to pending and that's fine, too.

There is quite some logic for adding indexes if there are multiple devices of the same name, and for adding square bracket indexes if one device has multiple ports with the same name. Now it might actually get confused because the NordStage already has an index appended! In any case, the NordStage has incorrect square bracket assignments in your BomeBox.

What you could try is to only trigger 1). I.e. in MT Pro, create aliases with the exact port names of the real devices as they appear on the BomeBox: "NordStage 2", "VI61 [1]", "mio", "A-PRO [1]" (I assume the latter).

We'll look into this. The Square brackets are a relatively new feature...
Thanks,
Florian

sjcaldwell

2016-11-07 21:34:28

Thanks Florian!

For now I think I will create aliases for only the port that is non-descriptive (MIO). And then use the real names (as exposed by the USB midi device) for everything else.

If that doesn't work then I will create descriptive aliases for all ports and use those. Actually this might be better if in the future if the USB ports get moved around.

I will also do as you suggested and reboot the Bome Box without a project file in attempt to clean up any existing mess.

Does this seem to be the most logical approach to you?

florian

2016-11-07 22:48:13

yes, sounds like a good approach. But, as said, the naming of ports should be consistent, no matter which aliases are in use or had been used previously.
Thanks,
Florian

sjcaldwell

2016-11-08 00:00:27

Well the first approach bombed but I seem to have consistency with the second approach.

sjcaldwell

2016-11-08 05:08:09

Florian

Here is a list of what Windows winmm.dll returns. Would any of this naming cause a problem?


MiList =
3- A-PRO MIDI IN
3- A-PRO 1
3- A-PRO 2
VI61
MIDIIN2 (VI61)
Bome MIDI Translator 1
Nord Stage 2 MIDI
mio

MOList =
Microsoft GS Wavetable Synth
3- A-PRO MIDI OUT
3- A-PRO
VI61
MIDIOUT2 (VI61)
Bome MIDI Translator 1
Nord Stage 2 MIDI
mio


The following Autohotkey code segment was used to get this list. Although I did some post formatting of the output.

Code: Select all

;--- MIDI INS LIST FUNCTIONS - port handling -----

MidiInsList(ByRef NumPorts)
{ ; Returns a "|"-separated list of midi output devices
local List, MidiInCaps, PortName, result
VarSetCapacity(MidiInCaps, 50, 0)
VarSetCapacity(PortName, 32) ; PortNameSize 32

NumPorts := DllCall("winmm.dll\midiInGetNumDevs") ; #midi output devices on system, First device ID = 0

Loop %NumPorts%
{
result := DllCall("winmm.dll\midiInGetDevCapsA", UInt,A_Index-1, UInt,&MidiInCaps, UInt,50, UInt)
If (result OR ErrorLevel) {
List .= "|-Error-"
Continue
}
DllCall("RtlMoveMemory", Str,PortName, UInt,&MidiInCaps+8, UInt,32) ; PortNameOffset 8, PortNameSize 32
List .= "|" PortName
}
;Msgbox Inports are %List%

Return SubStr(List,2)
}

MidiInGetNumDevs() { ; Get number of midi output devices on system, first device has an ID of 0
Return DllCall("winmm.dll\midiInGetNumDevs")
}
MidiInNameGet(uDeviceID = 0) { ; Get name of a midiOut device for a given ID

;MIDIOUTCAPS struct
; WORD wMid;
; WORD wPid;
; MMVERSION vDriverVersion;
; CHAR szPname[MAXPNAMELEN];
; WORD wTechnology;
; WORD wVoices;
; WORD wNotes;
; WORD wChannelMask;
; DWORD dwSupport;

VarSetCapacity(MidiInCaps, 50, 0) ; allows for szPname to be 32 bytes
OffsettoPortName := 8, PortNameSize := 32
result := DllCall("winmm.dll\midiInGetDevCapsA", UInt,uDeviceID, UInt,&MidiInCaps, UInt,50, UInt)

If (result OR ErrorLevel) {
MsgBox Error %result% (ErrorLevel = %ErrorLevel%) in retrieving the name of midi Input %UDeviceID%
Return -1
}

VarSetCapacity(PortName, PortNameSize)
DllCall("RtlMoveMemory", Str,PortName, Uint,&MidiInCaps+OffsettoPortName, Uint,PortNameSize)
Return PortName
}

MidiInsEnumerate() { ; Returns number of midi output devices, creates global array MidiOutPortName with their names
local NumPorts, PortID
MidiInPortName =
NumPorts := MidiInGetNumDevs()

Loop %NumPorts% {
PortID := A_Index -1
MidiInPortName%PortID% := MidiInNameGet(PortID)
}
Return NumPorts
}


; =============== end of midi selection stuff


MidiOutsList(ByRef NumPorts)
{ ; Returns a "|"-separated list of midi output devices
local List, MidiOutCaps, PortName, result
VarSetCapacity(MidiOutCaps, 50, 0)
VarSetCapacity(PortName, 32) ; PortNameSize 32

NumPorts := DllCall("winmm.dll\midiOutGetNumDevs") ; #midi output devices on system, First device ID = 0

Loop %NumPorts%
{
result := DllCall("winmm.dll\midiOutGetDevCapsA", UInt,A_Index-1, UInt,&MidiOutCaps, UInt,50, UInt)
If (result OR ErrorLevel)
{
List .= "|-Error-"
Continue
}
DllCall("RtlMoveMemory", Str,PortName, UInt,&MidiOutCaps+8, UInt,32) ; PortNameOffset 8, PortNameSize 32
List .= "|" PortName
}
;Msgbox Outports are %List%
Return SubStr(List,2)
}

florian

2016-11-08 20:32:24

The names shouldn't cause a problem! And as you (hopefully) see, MIDI Translator Pro undoes the Windows name mangling, especially with this weird "MIDIIN2 (VI61)", which is just the second port of VI61. Or the "3- " for the A-PRO names!

There is one other difficult thing: A-PRO has 3 input devices, but only 2 input devices. MT Pro has extensive logic to match input to output ports. "A-PRO MIDI IN" vs "A-PRO MIDI OUT" should match, but the rest is somewhat inconsistent, especially with or without added index.

So it turns out that the "Nord Stage 2" only has one input and one output port? Then there is definitely a bug in the BomeBox, where it's reported as 2 output ports. Ah, also the VI61 has 3 input ports on your BomeBox! We'll have to find a way to reproduce this, and I hope we will, with all your info.

Glad though that you have found a setup where it works consistently.

Best regards,
Florian

sjcaldwell

2016-11-08 21:17:30

I hope the naming I provided helps in troubleshooting.

The controls and performance can be programmed to sent output to the host via either A-PRO 1 or A-PRO 2 or both.
Normally you send performance and control data through A-PRO 1 and A-PRO 2 is for bulk transmission (aka sysex).

You can also use the MIDI DIN in connector on the A-PRO to merge with either A-PRO 1 or A-PRO 2 (but not both).
You can also turn the merge function off but both USB input connections from the device are still exposed to the host.

This allows you to use the MID DIN in connector as an interface from another external midi device back to the host.

I don't think the is a way to not expose both incoming ports.

sjcaldwell

2016-11-09 19:26:52

Hi Florian,

I found out why A-Pro behaves badly. I'm now connecting it through IConnectivity Midi device and when I found it would not work I posed the following question to Roland.
Hi, what is the difference between the built in USB Driver on Windows 10 for A-300PRO and the advanced driver?
I'm trying to connect to iConnectivity 4x4 and it doesn't recognize the A-300PRO unless I have advanced driver turned off. What will I be missing if I hook back up to PC directly without the advanced driver?

I couldn't find this answer on the knowledge base.
Here is the response I received:
Roland Product Support (Roland Corporation)

Nov 9, 8:58 AM PST

Hello Steve,

The Advanced driver setting in the A-300Pro has two settings:

ON: This sets the A-Pro keyboard to use a Roland driver, which must be installed on the computer. If the Roland driver is not installed, the A-Pro will not connect correctly and will not function. We normally recommend using this setting if a Roland driver is available for the operating system you are using, as the Roland driver is optimized for the A-Pro and can have a greater throughput (faster).

OFF: This allows the A-Pro to use the built-in USB MIDI driver that both Macs and Windows PCs have already in their systems. Also this is the setting to use if you are going to connect to an iOS device (which has a core MIDI driver) and any other device that uses USB connectivity but does not have a way to install a Roland driver (like the iConnectivity device). Setting this to OFF makes the A-Pro keyboard a 'Class Compliant' device (also called "Plug and Play").

Best Regards,

Product Support
Roland Corp. U.S.
Here is what Windows sees in Class Compliant mode (only the APRO connected)


MiList =

Bome MIDI Translator 1
A-PRO
MIDIIN2 (A-PRO)
MIDIIN3 (A-PRO)

MOList =
Microsoft GS Wavetable Synth
Bome MIDI Translator 1
A-PRO
MIDIOUT2 (A-PRO)

florian

2016-11-10 15:38:09

ah! and in class compliant mode, I hope that in MT Pro the 3 A-PRO MIDI INPUT devices have a unified name? like
A-PRO [1]
A-PRO [2]
A-PRO [3]

On the BomeBox, you're bound to use class compliant mode, too (I guess).

In general, it's quite smart of Roland to give both choices. I suspect though that for almost all cases, class compliant mode is fast enough.

Thanks,
Florian

sjcaldwell

2016-11-10 16:08:29

Well, I plan on running in Class Compliant mode only, now that I know that I have the option.

My plan is to run all devices through the IConnectivity Interface back to the Bome Box. The advantages of doing this.
  • I now have 4 midi DIN in and 4 midi DIN out ports instead of only one on Bome Box
  • I can do some simple pre-routing of devices and rudimentary filtering and mapping between various devices
  • Unlike a midi merge box I can control input and output in any fashion I wish
  • I can have Bome set up as one host and Windows as a second host simultaneously
  • I don't have to move cables around to re-program my Alesis VI61, FCB1010 or Roland A-300 pro.
The only real disadvantages I see is the port names exposed via USB interface are non intuitive of the devices they actually represent as shown below. Also there along with additional flexibility, comes more complexity in configuring the device.
  • Iconnectvity 1
  • Iconnectivity 2
  • ...
  • Iconnectivity 16