restarting service necessary

[TabSel]

Hi,

I used rtpMIDI to have a MIDI Keyboard "MK" attached to computer B available on Computer A, too.

I installed Copperlan, just to try it out. I started the Manager on Computer B, went to the Editor Tab in order to switch on the "MK" in the "MIDI to CP interface". I clicked on "on" but nothing happened, the "MK" stayed off...

Of course, the "MK"s MIDI driver is a non-multiclient driver, so only ONE application can open the device at an given time. As rtpMIDI was configured to use the device, the Copperlan Manager could not siwtch on the devive.

Thus, I deactivated the rtpMIDI connection which opened the MK device. The device was closed, as I could open it with another app, like MIDI-OX. I quit MIDI-OX, too, ran the CP Manager and wanted to switch on the "MK" device, but CP still refused to switch it on...

I stopped and restarted the CPVNM service, ran the CP Manager again and was since then able to switch on the "MK" device for "MIDI to CP interface".

A) Now my question: Isn't there a more comfortable way of doing this? Does Copperlan check only once wether a device is available for opening? Some Kind of "Rescan für available devices" would be cool, or an automatic rescan when the user wants to switch on a device...

Or am I doing something completely wrong here?

B) Another question is: How am I supposed to connect the CP Manager on the iPad with my Copperlan?
I have to Computers A and B, hooked to a GB switch via Ethernet, which is connected via Ethernet to a WIFI capable router. The iPad is connected to the Router via WIFI for Internet Access.

The CP Manager on my iPad always shows "No Copperlan" bottom right.

Thank you!

[CopperPhil]

Hi!

Well, I just made a try here and I can't reproduce the issue... it is possible to activate the MIDI controller on the CopperLan network as soon it is released by the application/service previously using it. This is the normal behaviour of CopperLan. It is sniffing Plug&Play and ports activations in order to dynamically provide the user with an up-to-date list, manual refresh is not needed in normal operation.

Have you seen this problem just after CopperLan installation, or did you get it again after a reboot? It is interesting to know to determine if it is related to the installation process, needing in some rare occasions a reboot to be complete.

For the second question, the iPad CopperLan Manager is normally able to get connected automatically to the network. We had many difficulties to get it working during Musikmesse or NAMM Show, due to so many WIFI networks all around. So if your WIFI is functional, did you check that it is sharing the same IP address range/local network as your cabled computers?

[TabSel]

A)

Have you seen this problem just after CopperLan installation, or did you get it again after a reboot? It is interesting to know to determine if it is related to the installation process, needing in some rare occasions a reboot to be complete.

after troubleshooting it again today (after a reboot), it appears to work correctly now.

The rtpMIDI connection created a MIDI port "MK". I deactivated the connection and DELETED the session (thus, the Midi Port "MK" gets deleted). I opened an app, say Kore2 and verified that the Port "MK" is no more available in the List of Kore2s list of MIDI devices.

However, in the Copperlan Manager MIDI device list, it still is listed. I guess, after a reboot, the device is no more present in the CP Manager MIDI device list...

B) of course, same subnet/mask for the iPad. No Copperlan found in CP Manager on iPad.


Further Questions:

C) I noticed that in Kore2 for example I have the "VMIDI" ports of Copperlan in the device list. So CP installs these ports? And I won't have to use Loopback Midi ports to connect a VMIDI to it via CP to MIDI device interface in CP Manager? Great!

Or am I wrong? Well, it works at least

[CopperPhil]

The iPad CopperLan Manager is using UDP broadcast in order to find a VNM (= Virtual Network Manager = the CopperLan engine running on each CopperLan Machine, it is the CPVNM service you've already found) hosted somewhere on the network. In some case (antivirus/active shield/firewall) computers are not allowed to receive such UDP packet, and so the iPad can't get connected to a VNM, nor to CopperLan of course...

Yes indeed, you are right the CopperLan package installer creates a set of virtual MIDI ports allowing you to bind MIDI applications to the network in both directions. You can setup from 4 to 32 of these ports using the Editor tab, pointing on a computer's MIDI sub-device.

[TabSel]

concerning A) I was right: after rebooting the machine, the MIDI device list doesn't include the "MK" MIDI port any more...

maybe a manual or automatic "refresh" of the available MIDI ports can be implemented? MIDI devices CAN become available or unavailabe during a Win session. CP should reflect the available devices only, right?

[CopperPhil]

Well, ok will add a manual refresh feature in the next CopperLan release. You are the first to report a MIDI port list issue. This list is maintained by the plug & play notifications, so it is supposed to reflect the current status... If a port does not appear on the list it is certainly due to some missing 3rd party driver notification. We have never seen this before but it is always possible; we have no control on drivers not provided by us

Code: Select all

CP should reflect the available devices only, right?

Actually not exactly. It is showing the complete list of all MIDI ports enumerated by the system, even they are available or not, and currently the list is updated on plug & play notifications. The only way to know if a port is available is trying to open it. You understand that CopperLan is not doing that continuously of course...

[TabSel]

...list is maintained by the plug & play notifications, so it is supposed to reflect the current status... If a port does not appear on the list it is certainly due to some missing 3rd party driver notification. We have never seen this before but it is always possible; we have no control on...

I fully understand, and that's what I meant with "CP should reflect the available devices only..."

The ports in question here are maintained by LoopMIDI/rtpMIDI and its underlying virtualMIDI driver by Tobias Erichsen, a driver which is able to dynamically create and destroy freely nameable MIDI-ports. My guess is, that the driver won't issue plugn'play notifications on creation/destroying ports.

I rely on LoopMIDI/rtpMIDI because:
a) the CP VMIDI.. ports can't be renamed
b) there's no way to use iOS CoreMIDI with CP on Windows without the rtpMIDI "bridge"

It would be great to be able to rename the VMIDI ports (even when it's applied after reboot only)
And of course, it would be great to support iOS Core MIDI in CP Windows directly.

Until then

...will add a manual refresh feature in the next CopperLan release...

will be a perfect interim solution. It could be halfway automated, too: always refresh the list when the user expands the "CP to MIDI" or "MIDI to CP" interface node. Plus a manual refresh possibility, if the node already is exanded?

...You are the first to report a MIDI port list issue...

somebody has to be the first.

[CopperPhil]

t would be great to be able to rename the VMIDI ports (even when it's applied after reboot only)
And of course, it would be great to support iOS Core MIDI in CP Windows directly.

Yes indeed, we decided not to allow virtual MIDI port renaming due to the difficulty to make it matching between the CopperLan network and the system MIDI port name (non-CopperLan application side). The first can be changed dynamically, the second needs driver restarting... resulting in the closure of all VMIDI ports, even those who are normally not affected by the operation. This seemed unacceptable.

There is a blocking issue about iOS Core MIDI. iOS does not allow raw socket operation, but since CopperLan is not IP based we need to create our own network packets following our own protocol (Ethertype IEEE 0x8927). So it is currently impossible to bring CopperLan natively to an iOS device, and it is the reason why a CopperLan iOS application relies on a computer equipped with CopperLan. But we have some workaround ideas that could bring a solution in the future.

I appreciate your suggestions about refresh, thanks!

[TabSel]

...we decided not to allow virtual MIDI port renaming due to the difficulty to make it matching between the CopperLan network and the system MIDI port name (non-CopperLan application side). The first can be changed dynamically, the second needs driver restarting... resulting in the closure of all VMIDI ports, even those who are normally not affected by the operation. This seemed unacceptable.

it is, at least in a running situation. But who changes names in a running situation?

However, what about a possibility to give VMIDI system MIDI ports a custom name (in the CP Manager) but don't actually change the name, but do it only on driver restart (reboot). Until then, indicate a "name change pending" with the "MIDI Port renaming possible" dot top left of the Port name in the CP manager... (orange for "MIDI Port renaming possible", blue, or blinking orange for "Name change pending until Driver restart"...)

...There is a blocking issue about iOS Core MIDI. iOS does not allow raw socket operation, but since CopperLan is not IP based we need to create our own network packets following our own protocol (Ethertype IEEE 0x8927). So it is currently impossible to bring CopperLan natively to an iOS device, and it is the reason why a CopperLan iOS application relies on a computer equipped with CopperLan. But we have some workaround ideas that could bring a solution in the future.

hmm, seems to be difficult to integrate iOS as whole into a non-IP based network. I still can not use the CP Manager on my iPad, as I don't know what to do to have it "see" the Copperlan. It always shows "no Copperlan", no matter what I try...