Breakout Adaptors

[spettitt]

So I'm trying to look at the best way forward for a very common type of adaptor.

 

On one hand, ConnectCAD adaptors can be said to change sockets of one signal type to another, but a user views a real-world adaptor as more than that - they also change one multi-circuit connector in to multiple single-circuit connectors, even if the signal type is the same.

 

A common occurence are breakouts of various forms, such as a CA-COM(/PA-COM) to 4 x NL4. L-Acoustics call this a DO-SUB. It's used for taking a PA-COM and breaking it out to tails that feed individual sub loudspeakers. Each tail goes directly in to the loudspeaker box - there is no loose cable between the breakout and the loudspeaker.

 

One solution I had was to make an adaptor representing this, but have the origin of the adaptor be the first output tail - docking it on the input socket of the first loudspeaker. Then three output tails and an input tail:

 

The problem with this is that it requires three 'fake' circuits that show up in reports, and confusingly misses a fake circuit for the first loudspeaker. It also shows three connections (2, 3, 4) where a connection doesn't actually exist in real life - it is a continuous tail from the IN to the loudpseaker.

 

I don't want to use the Connector Panel tool, because CC will detect it as a panel, which it isn't.

 

So rather than a panel device, I tried making a simple 1-in, 1-out device that I can customise to not look like a device (having things that are cables in real life but look like devices on a schematic is dead confusing). The bubbles are pulling some record data to show which tail is which.

 

The problem with devices is that they require explicit circuits to connect to each of their sockets, so this solution uses four fake circuits that appear on reports. But now, at least all loudspeakers are treated the same. The tail number is a property of the circuits, so the circuits can't be filtered from the report, but their presence on a report suggests there is a cable to install, but there isn't - just a single adaptor.

 

So the reason for my post: I believe the device solution above is the best compromise here and intend to go forward with (at least for the moment) - but I'm just curious how others would approach this with the tools available?

 

[Conrad Preen]

Hi Simon @spettitt

 

Thanks for the detailed use case. I shall think about that!

 

Conrad

[Conrad Preen]

Hi Simon @spettitt

 

Adapters have always fallen into that grey area "is it a device? is it a cable? no, it's an adapter!". Circuits on schematics vs. the physical cables that implement them are another area that I have left a little murky - deliberately... For a lot of uses circuit = cable is a pretty reasonable assumption. But of course there are exceptions.

 

These DO-SUB "adapter cables" are effectively 4 circuits packaged in the same wire. So, in a very simplistic way you could give each circuit the same Cable parameter and have them share a common path on the schematic up to the point where they break out to different devices. This will look fairly nice. But it doesn't help you count the number of DO-SUB's you need to order.

 

So I think you do have to consider them as devices. After all you can connect a circuit to the multi-pin end and another circuit to extend the single end. So your "fake circuits" may not always be fake. And it needs to be on the bill of materials. Even though it looks like a cable, it walks like a device and quacks like device!!!

 

The alternatives involve extreme complication of the Adapter object. Or a new Adapter Cable object... that could connect to device sockets or circuits at both its ends, and be re-shape-able. Guess that could be a project...?

 

Conrad

[tk_]

@spettitt I like you last idea the best, the device that doesn't look like one approach, I am in a similar boat as we often use network cable to split off various signals, like a DMX sneak snake or the audio equivalent (Radial Catapult box or sound tools cat box).

 

I would be interested to know how you pull the record data into the cable field or is that just a linked text field that looks the same.

 

Thank you

[jfreberg]

Hi Conrad,

 

I vote for  the Adapter Cable Object approach. I think that best captures the bulk of the actual use cases of cable adaptors in the field.

 

The Adapter Cable Object would have to be capable of multiple circuits to allow for breakouts. The object would have to support direct connection to a device connector (socket with multiple circuits) as well as being applied to the end of ConnectCAD circuit (which we would typically call a cable in the physical world).

I agreee that this new object is best considered as a special case of a device. It would need a different graphical appearance compaired to  a regular device instance.

For a little extended thought, a new object of this type might find use in IP-based designs. Think VLAN Trunking and Multicast applications where multiple channels are carried on virtual routes, and delivered to multiple destinations.  I have not seen any IT documentation solutions that bring clarity to media systems as we design and use them today.

Most of the media systems I am aware of tend to be configured logically to look alot like the legacy cable plants we built in the past. In many ways, they were self-documenting: just follow the wire.

 

Now all the cabling has been replaced by the network switches. But those legacy channels are still hidden away in cryptic configuration files. 

 

Any estimate of when we might see the Adapter Cable Object?

 

Regards, 
 

John Freberg

[Conrad Preen]

@jfreberg great points that you make! Not really sure of an ETA for this though I do agree there are some kinds of adapters that we haven't got to yet, namely adapter-as-connection and break-in adapters. I think it would be best to add these functionality to the Adapter object rather than spawn a new object type. Needs some thinking about to get to the correct design.

 

Conrad

[Bluetones]

On 12/15/2025 at 5:14 AM, Conrad Preen said:

@jfreberg great points that you make! Not really sure of an ETA for this though I do agree there are some kinds of adapters that we haven't got to yet, namely adapter-as-connection and break-in adapters. I think it would be best to add these functionality to the Adapter object rather than spawn a new object type. Needs some thinking about to get to the correct design.

 

Conrad

Variations of the Adapter type, including;

Inline adapters: BNC barrels, CAT-5 barrels, BNC-RCA, XLR to TRS 1/4", etc

Adapter cables: 15-pin to 5-wire (who uses these anymore?) K-COM, CAT-5 breakout looms, etc.

 

Other?