Describe the bug
There appears to be a couple of minor bugs with ProjectRed's bundled cable API which mean that its CC compatibility is non-functional.

To Reproduce
Steps to reproduce the behaviour:

1. Place down a computer, a bundled cable to the right of it, then a white insulated cable and finally a lamp.
2. Open the computer and run rs set right white true.
3. Notice the lamp does not turn on.
4. Replace the lamp with a lever and turn it on.
5. Run rs probe on the computer.
6. This detects no redstone inputs.

Expected behaviour
I would expect the lamp to turn on, and rs probe to indicate that the white channel is active.

Versions
Include versions of the dependencies. And since you're looking at it, make sure ProjectRed is up to date. Don't submit bugs for old versions, as they could have been fixed.

• ProjectRed Version: Tested in a dev environment at 292850d.

Additional notes
I've managed to find the cause of a couple of these problems, but afraid not everything:

• The transmission API always returns null, rather than the newly generated signals array:

  ProjectRed/transmission/src/main/java/mrtjp/projectred/transmission/TransmissionAPI.java

  Line 67 in 292850d

  return null;

  I noticed that BundledSignalsLib also contains a copy of this method with the correct return signals;. I suspect this is just a relic of the Java port (which serious kudos, that must have been an incredible amount of work)

  ProjectRed/core/src/main/java/mrtjp/projectred/core/BundledSignalsLib.java

  Lines 62 to 65 in 292850d

  	return signal;
  	}
  	return null;

• The CC bundled redstone provider offsets the position and flips the direction:

  ProjectRed/core/src/main/java/mrtjp/projectred/compatibility/ComputerCraftCompatibility.java

  Line 32 in 292850d

  byte[] signal = ProjectRedAPI.transmissionAPI.getBundledInput(world, pos.relative(side), side.getOpposite());

  This shouldn't be needed - doing ProjectRedAPI.transmissionAPI.getBundledInput(world, pos, side); and fixing the above bullet fixes issues with flipping the lever not being detected by the computer.

• The side passed to IBundledTileInteraction.getBundledSignal doesn't appear to be correct. I'm afraid I got a little lost here with how PorjectRed handles rotations, so haven't been able to debug this further.

Thanks for looking into this. Definitely seems like remnants from when we moved from Scala to Java.

According to the old Scala code, ITransmissionAPI#getBundledInput should give you the incoming signal to the block specified, meaning it will offset the given pos towards the face, then ask that neighbor block for its output. The function BundledSignalsLib.getBundledInput actually does this (see line 36), while the other does not (I believe I started writing this method in TransmissionAPI, then realized it fits better in BundledSignalsLib, copied it there, and forgot to redirect the call).

This is also why the IBundledRedstoneProvider I implemented offsets the side/face. Your API is an output getter, while mine is an input getter, so it has to operate from the other block's perspective. At the time, both of our APIs were stable so I couldn't just change mine to match unfortunately. Maybe I'll revisit it.

So overall, I think we fix it like this:

1. For ProjectRed -> CC, point TransmissionAPI.getBundledInput to BundledSignalsLib.getBundledInput. This alone should fix probing.
2. For CC -> ProjectRed, like you said, there's a bug with the sides that PR's cables are querying interactions with. Looking into this now.

Found it! Here, the Bundled Cable asks its neighbor for a bundled signal. This line specifically is for registered interactions. For whatever reason, it's using the rotation index rather than converting it into a direction index.

Instead it should be doing what line 230 does, converting that rotation to direction.

Same deal with Bundled gate parts: