CopperLan

I run
- MacOS X on a late 2013 Haswell MacBookPro
- a Win8.1Update1 Parallels virtual machine on this MBP using a bridged network with MacOSX
- Win8.1Update1 on a desktop PC

- Copperlan v1.2(7) on all three machines.

After booting into the Win VM, the CPVNM in the VM consumes a lot of CPU cycles for a few seconds until it crashes.

Hi,

A new version of CopperLan is currently under test.

Can you try this and tell me if it fixes your issue?

https://dl.dropboxusercontent.com/u/215 ... %29%5D.exe

Thanks,
/Phil

v1.3(1) seems to be running stable along v1.2(7) on Mac now

Ok thank you.

This new version 1.3(1) would be published very soon. I'll tell you here when it's done.

V1.3.2 again seems to crash in the VM...

Hi,

We need to determine which part of the CPVNM is causing the crash.

- Are you managing any MIDI device from the VM? If so, can you disconnect all external MIDI device and tell me if the CPVNM is still crashing?
- Please select no Ethernet inferface for the CopperLan running into the VM. Then tell me if the CPVNM is still crashing.
- Try to change the number of virtual MIDI ports, going down if possible (if you have currently 8 VMIDI ports, then select 4 ports). Is it still crashing?

Thanks,

/Phil

not in front of my setup currently, but from what I at least remember:

1) I am not doing anything within Copperlan. I installed the latest v1.3.2 (manually, as the "check for update" did not find anything) on all my machines, leaving evertyhing to install default. So, basically, the CPVNM is crashing without me doing anything despite booting the machines.

2) will have to check again to be sure, but, as far as I remember, relaunching the cpvnm service after crash, or even after machine boot, sometimes the VM machine device isnt visisble in the VM hosts CP Manager, and the VM host device isnt visible in the VM CP Manager, so I select "-none-" ethernet interface and reselect the proper net interface again, which works most of the times until the CPVNM crashes after about half a minute; cpu load is "quite high" when ethernet interface selected in the VM...

3) no changes to vMIDI ports (default 4) after install

(I've got a lot of midi devices, but these haven't changed, and worked with v1.3.1. The only thing that changed with installing v1.3.2 is an install of Evan Balster's Imitone/virtual MIDI driver and a newer (beta) version of tobias erichsons LoopMIDI/rtpMIDI/midi driver)

All in all, I'm pretty sure that the crash has nothing to do with MIDI at all, but with ethernet. Is there a "logging/debugging" possibility for the CPVNM I could use to gather more information? Do the windows event/crash logs help you?

The only thing that changed with installing v1.3.2 is an install of Evan Balster's Imitone/virtual MIDI driver and a newer (beta) version of tobias erichsons LoopMIDI/rtpMIDI/midi driver

Ha ok, you nevertheless did install some extra virtual MIDI ports

Ok I can't install the Imitone software, but I just installed all the Tobias stuff and it's still working fine here. However I saw that the virtual MIDI drivers related to Rtp/LoopMIDI are not plug & play, the CopperLan engine is not notified when they are created/destroyed. So you can handle them in CopperLan only after a CPVNM restart. Moreover the VNM still believe they are there even they have been deleted from the Rtp/LoopMIDI software. This could put a mess actually. So can you check the MIDI to CP and CP to MIDI interfaces and disable all ports related to Rtp or LoopMIDI to be sure that these virtual ports are not in cause?

Ok, i actually DID some changes after install: I DID deactivate ALL midi ports in the cp to midi and midi to cp

(BTW, I know that the teVirtualMidi port creation/destruction is not issuing plugn'play events, which is a pity. Did not check for changes with the new beta though. May be Tobias is able to implement the events?)

Just another idea, can you check that the VM Ethernet adapter is not sharing the same Mac address than the host computer? Each VNM must be using an Ethernet adapter having its unique Mac address, so VM Ethernet bridging config is maybe the clue...