Why only 4 vports

[bcslaam]

Hi I am new to Copperlan

I'm really impressed by Copperlan but the fact that there are only 4 ports seems contrary to the whole concept. Why so little?

MOL has 16 or so.

I realise objects can be directly connected but that doesn't accomodate the fact that the DAW should be the hub that accesses all devices. Currently it can only see 4 MIDI ports. Or am I missing something?

In my case I have 3 other PC farms running VEPro using physical I/O and MOL and each instance would easily eat up 4 ports.

Please provide at least 32 VPorts.

Ideally VEPro AND my DAW (Reaper/Logic/PT10) would bypass midi and use copperlan but thats ages away from happening.

I am seriously considering buying a few Alyseum AL-22 but this limitation is stopping me from entering the platform.

BTW is there any other companies out there that make midi>copperlan/ethernet interfaces Alyseum are very expensive.

Cheers
Ben

[CopperPhil]

Hi Ben,

Actually, you can set up the number of VMIDI ports dynamically from 4 to 32. Just use the CopperLan Manager, Edit tab, MIDI on your_computer, MIDI settings, Number of virtual ports.

However, please note that you can patch MIDI on a channel basis. Take a look at this to get a better understanding of what you can do with CopperLan: http://alyseum.com/downloads/ALYSEUM_Application%20Note_Global%20MIDI%20Network_%20V1.6_EN.pdf

Today Alyseum is the only one selling MIDI <=> CopperLan bridges. Their product are not cheap, but their capabilities, performance and flexibility are far away from anything else...

/Phil

[bcslaam]

Hi Phil

Thanks for the reply. Great!! This looks cool.

However I expanded to 32 ports on the local pc and then the object for it dissappeared on the template and also the network card dissappeared from the list in settings and it also crashes on exit now.

WinXP sp3

P4 3ghz/1.5gb ram

intel gigabit network card

[CopperPhil]

Hmmmm... I know that there is some limitation under Windows XP about the maximum number of MIDI ports that can be used (even not simultaneously) on the computer...

I'm not sure this is the issue cause, but if you had installed a number of MIDI devices before, then increased the number of CopperLan VMIDI to 32 and finally got a crash, it seems to be coherent with this number of ports limitation.

Are you familiar with the regedit.exe application? If so, can you launch it, then go to HKEY_LOCAL_MACHINE\System\ControlSet001\Control\MediaProperties\PrivateProperties\Midi, right click on it, "export", save it as a text file and send it by email to pca@copperlan.org (it is important to save the file as a text file, or to zip the .reg with a password to prevent filtering by email firewall).

Then can you try to reduce the number of VMIDI ports to 4 and check if it fixes the issue?

[bcslaam]

I have sent the text file to your email. As mentioned in my email I cant get to the object now to change the number of ports. The app is kinda locked.

Beginners luck ey

So what's the maximum number of ports allowed in WinXP? I seem to remember 12. Which is less than what MOL is giving me.

[CopperPhil]

Thanks for the feedback.

Yes indeed, the missing object for the local PC means that the CopperLan service is crashed. You should read "no copperlan" in the bottom right of the CopperLan Manager.

So you can force manually the number of virtual midi ports from the registry, HKLM\SOFTWARE\CopperLan\CPVNM, key NumVMIDI, set it to 4, then try to restart the CPVNM service (tell me if you don't know how to proceed).

If it does not fix the issue, try to delete the complete HKLM\SOFTWARE\CopperLan branch and then restart the VNM, it will result in a first startup, like you just installed the package.

I see that you are using Mapple... I'm not sure if it could or not interact with CopperLan. I'll check that as soon as possible, but I'm at the NAMM Show for the moment so I can't do it right now...

About the number of MIDI ports, I don't remember exactly but I think it's 32 for XP SP3. But the windows registry retains the old ports, this limitation is not related to the current number of MIDI ports but the number of different types of MIDI port that have been connected from the Windows installation. And I have identified 20 ports in/out in your registry abstract, without mention of any CopperLan VMIDI port. So to be secure, I suggest you don't try to create more than 8 VMIDI from CopperLan.

[bcslaam]

Hi Phil

Ive got some experience with regedit and first tried changing the number of ports. No luck. Then deleted the whole tree. No luck.

network card wasnt showing up still as well as no objects. But it did say "local" or something in the bottom right. Not "no copperlan"

Anyway uninstalled and re-installed solved it. Changed ports to 8 successfully.

mmm come to think of it I think I forgot to restart CPVNM service earlier. Not to worry uninstall fixed it.

So where does that leave me...well this is only my test machine anyway but if the old registry entries of midi drivers restricts CL then that sucks. I'm sure you can resolve it. How do I clean the old ones cause I'm sure I uninstaslled maple eons ago.

[edit]
I just tried 32 ports again and it worked. I could go to connect etc. So not sure what happened earlier.

Suggestion: 1.Be nice if you could draw cables between objects
2. I've been trying to sync two Ableton Live rigs together without experiencing un-workable tempo jitter. I'm yet to test this but I'm hoping its better with CP. Be nice if there was no jitter. I've found the best way was to have a master hardware midi clock (in our case novation sl) that was sent to both rigs. Do you think if CP had an internal master midi tempo clock that could be run from another pc or better still an android tablet that it might solve this problem. A clock that you could control by another midi controller.

I'll let you get back to namm I'm off to sleep. Thanks for your responses.

[CopperPhil]

... I'm sure you can resolve it. How do I clean the old ones cause I'm sure I uninstaslled maple eons ago.

Unfortunately not... this is a strange behavior of WinXP, this issue does not exists anymore from Windows Vista.

I just tried 32 ports again and it worked. I could go to connect etc. So not sure what happened earlier.

Good news!

Suggestion: 1.Be nice if you could draw cables between objects

Acutally the links are visible from the Overview tab... don't you see them?

2. I've been trying to sync two Ableton Live rigs together without experiencing un-workable tempo jitter. I'm yet to test this but I'm hoping its better with CP. Be nice if there was no jitter. I've found the best way was to have a master hardware midi clock (in our case novation sl) that was sent to both rigs. Do you think if CP had an internal master midi tempo clock that could be run from another pc or better still an android tablet that it might solve this problem. A clock that you could control by another midi controller.

Actually, we made a lot a measurement related to latency and jitter. We have seen that it is very stable and low between two hardware systems, but unpredictable as soon one of the peers is a computer, the worst case is when the computer is the sender. However we have measured that the jitter is quite low when a Mac is used as a sender, PC induce higher jitter.

Sure that if you are using WIFI, the result will be very very very bad! Always use cabled network for better performance.

You should get good result using a hardware MIDI clock generator -(midi)-> Alyseum AL-22/88 -(copperlan)-> target since in this case only embedded systems are involved in the transmission chain. AL-xx products are inducing very low jitter (under 500 micro-seconds).

[bcslaam]

The links are drop down with an info tab etc but I meant like in EnergyXT, Plogue or Scope the ability to draw a cable from one input to another. No biggie though. It works well as is.

I appologise for OT:
Your tests are what I have to deal with all the time and a hardware clock would be my usual solution but I thought if the copperlan manager was running on a separate computer (that has minimal load) with a "midi clock object" present locally and patchable in the CP environment, you'd think it could output a steady clock. What if it was on a linux machine?

After all a hardware machine is basically a computer. And if your saying that once the clock is generated steadily it can be piped steadily down a copperlan wire then whats the diff? Is it really that even an i7 pc cant do it. Wow!!

If this is the case then thats one of the major flaws in midi and should be in your mandate as copperlan is the new midi, no? There a heaps of people complaining about midi jitter. Certainly a way of capturing more market.

Sorry for rant. Obviously the OT is resolved.

[CopperPhil]

After all a hardware machine is basically a computer. And if your saying that once the clock is generated steadily it can be piped steadily down a copperlan wire then whats the diff? Is it really that even an i7 pc cant do it. Wow!!

The difference is the operating system... Modern computers are using preemptive operating systems (Windows, MacOSX, Linux) running apps in a special "user mode", a kind of sand box virtualizing the computer resources. Under such OS the application is not directly in touch with the hardware, so it has to travel through a lot of layers down from the user mode to the kernel mode and finally the hardware control to send a message on the network. Those OS are not real-time, it means that they can decide to switch from task A to task B for any reason, so the time needed to perform a specific operation is not predictable. Timers are virtual objects managed by the OS, and the time granularity is usually around the millisecond. So if we add the uncertainty of timers triggering time to the time required to cross the layers from the app to the hardware, you get the reason of latency/jitter.
Embedded systems are usually running without operating system, or using a real-time OS. An embedded application can use a hardware timer to be interrupted at very accurate time interval, then it is directly in touch with the hardware so it can drop a message on the network very quickly!
A Core i7 is offering an incredible CPU power, but it is not a guarantee to get accurate timings due to the operating system behavior.

If this is the case then thats one of the major flaws in midi and should be in your mandate as copperlan is the new midi, no? There a heaps of people complaining about midi jitter. Certainly a way of capturing more market.

I understand your point of view, but I can't transform a preemptive OS into a real-time OS Maybe a solution would be to use ASIO driver providing accurate timing callbacks calls, but I'm not sure it's possible without disturbing other audio applications, and finally it's just solving a part of the issue.