1.2(7) Win8/64 - Crash after disconnecting a USB controller

[chrisfoster]

This is the biggest challenge to CopperLanize existing MIDI gear

There's only so much control you can achieve over legacy midi gear I guess, but the issue you discuss sounds like nrpn/rpn issues and not that of sysex control?

I would have thought with nrpn/rpn, the CL target would be the controller i.e 'control the controller' ...it's been done already (understatement)

Real men wear Brut and want sysex control over their midi beasts...they dont want doof doof doof with the bullshit CC messages. Then again, real men (and women) probably use modular gear with those electrickery signals

Talk sysex to me....is there a problem inherent with sysex that CopperLan cannot overcome, as you allude may be the case with nrpn/rpn ? Should I sell my rack-mount hardware and buy 2 turntables and a microphone (Copperized of course)

Do tell me if you think my limited understanding of the difference between nrpn/rpn and sysex is misdirected!

For example I know of no device that has ever offered to stack sysex commands under the one physical/virtual control i.e 10 synths have the message for filter cutoff implemented differently and I wanted to move that parameter on all 10 synths at the same time...never been possible...and maybe never will be, unless......

Cheers

[CopperPhil]

is there a problem inherent with sysex that CopperLan cannot overcome

Not really, it's possible to transmit Sysex through CopperLan... So if the message source is sending Sysex on a MIDI->CopperLan bridge, it can be sent as is to a CopperLan->MIDI bridge.

But I don't see how to manage Sysex in a pure CopperLan point of view since this Sysex is so specific to a particular target. I mean, a CopperLan controller (or a MIDI control panel through CopperLan) has a set of "controller" entities aimed to be bound to "parameters". Okay, I can imagine that the CopperPlug MIDI Target is able to translate the knob position in some Sysex and send it to the MIDI gear. But how can I get back the current value from the MIDI stuff without creating a dedicated software for this target and considering that this software would be able to detect current value change in the MIDI equipment? I need this, not for the legacy MIDI control panels having just a few knobs and no display, but for enhanced controllers with motorized sliders, displays, leds...

Creating Sysex, NRPN/RPN from CopperLan messages is not a problem. Just need some time to design an editor and some translation logic that works in most cases. But I look further. CopperLan is bi-directional by design. MIDI not. How this could integrate with the new pure CopperLan Controllers without putting a mess in the user's understanding?

For example I know of no device that has ever offered to stack sysex commands under the one physical/virtual control i.e 10 synths have the message for filter cutoff implemented differently and I wanted to move that parameter on all 10 synths at the same time...never been possible...and maybe never will be, unless......

This issue will not occur in CopperLan. Interoperability is one of the most important thing we bring with our technology. So the future is shining, but using old gears in this context will be tinkering, always. Unless someone find THE brilliant idea to mix everything in a convenient way. I'll be pleased to help him to implement this idea, really.

[chrisfoster]

I might have a look at wrapping the http://ctrlr.org/ VST (C++/JUCE ) to get a start...

I wonder if it's a candidate to merge with CopperLan Free SDK since it's the same language and the source code is available.

They also have an excellent tutorial: http://ctrlr.org/getting-started/

[chrisfoster]

Had to go back to (6) as (7) is still a disaster on my system thus:

I tested a route off the hub that hosts my controllers - port 1 (Ch1) to the other 4 hubs on port 1 (Ch 1) ...all was good, did a cold boot. Now the port 1 I routed from has disappeared and will not come back through a subsequent re-boot.

The overview Tab, shows that all devices are present and accounted for which includes 5 other devices besides the 5 Midi Hubs x 8 ports.

The Connect tabs shows Vmidi 1-4 and all the ports of the 5 hubs, less the port 1 discussed above.
The connect hub does not show CP-Midi and Midi-CP

The edit Tab shows all the ports of the 5 hubs, less the port 1 discussed above...and nothing else.

Cheers

[CopperPhil]

It seems to me normal that the CP to MIDI and MIDI to CP are not visible in the Connect tab... Are you talking about the entries used to enable/disable a MIDI port? If so they are present in the Edit tab.

It seems like the port 1 is disconnected from CopperLan... did you check in the Edit tab if the port 1 is still enabled?

Moreover, under Windows MIDI ports are identified by their name. Do you get distinct names for all the MIDI ports created by your PCIe cards?

[chrisfoster]

Totally normal under (6) Unique names for every device, all ports present, CP/Midi present in Edit Tab, wiring shown on Overview Tab

When I install (7) initially it looks fine, I do the routing and check...it's all good. But when I do a cold re-boot and re-start that's when it's pear shaped. That doesn't happen with (6) ....the re-boot changes something

It seems like the port 1 is disconnected from CopperLan... did you check in the Edit tab if the port 1 is still enabled?

Under (7) there is no ability to enable anything...no CP-Midi functionality under Edit Tab after a re-boot.

I will send 3 files that might help pin down the issue form the Reporting Tool

1.26 = Normal Behavior
1.27_initial - Normal behavior
1.27_reboot - unusable but MidiOx confirms all hubs are present and consistently routing between swaps between (6) and (7)

whoops...1.27_reboot, should show a problem, because the reporting tool stalls at 50% complete!

Cheers