Cranborne 500R8

[mrgroovy]

I have been researching various interfaces to replace my Apollo 6X. The top of my list was the Avett carbon but then I came across the Cranborne 500R8 https://www.cranborne-audio.com/500r8
With this unit I could incorporate some hardware processing on the front end and the mix end with the capabilities as an interface as well.
Seem to be large group who have nothing but good things to say at different sites. Also does away with physical patch bays and cables. Impressive.
Anyone have any experience with this unit and ProTools? Only found two posts so far in this forum.

[Darryl Ramm]

I would ran far away from this product. If you want an interface get a quality interface from a vendor who develops their own stuff, especially device drivers. By all means connect that up to 500 series racks but the interface does not need to live in the 500 series rack. Cranbourne may make great 500 series analog hardware, I have no idea. But that would not drive this decision on the interface for me.

These boxes are not great computer audio interfaces and do not have great interface drivers. Cranborne appears to use third party developed audio interface components inside this box, including also using a third party developed ASIO drivers. On macOS at least the class compliant CoreAudio drivers do not correctly report the interface latency, and the Cranbourne documentation has some pretty mind-numbing confused comments about latency in them. This is likely to cause phase errors for folks who are not careful about manually correcting stuff. There have been multiple users on DUC with latency problems with using these boxes as hardware inserts, all a direct result of this. With proper measurement and manual adjustment of ADC it's possible to get this to work. I've helped some users get sorted out who were having these problems, you can google for those posts. But that should not be needed. And the RTL latency is also just not impressive, if that's important to you. I also have no idea if the driver misreporting of latency was ever fixed or if anybody there understands any of this. Their support organization seems to have really wasted users time in the past not understanding latency related things.

There are so many really impressive interface available from vendors like RME, DAD, Motu, Focusrite, (and UAD),... companies that build the deep critical bits of their interfaces themselves and have great software teams developing and supporting their own drivers. RME is my personal favorite, but damn Avid partnering with DAD/NTP for MTRX and MTRX Studio just show up how nice stuff they have.

What is wrong with your Apollo 6X? You don't like the Apollo Console? Or would a Apollo 16 and a 500 series rack or two get what you want? Would you keep the 6X and thunderbolt chain that with other Apollo boxes?

[mrgroovy]

Thank you for your input. And yes, I did review some of the former posts which you assisted.
The issue that I have with the Apollo X6 is simply the need for the Console. If I were interested in Luna, that would be a different story. However, I really need to stick with ProTools for a number of reasons.
The concept behind the Cranborne 500R is pretty much exactly what I need for my workflow. I’m a one-man band that uses a lot of VIs with guitar, bass and vocals as the only audio, tracked only one at a time.
If it was completely functional with ProTools, I can’t see anything to dislike about an interface and 500 series rack in one unit with no patchbay needed. I hope Cranborne reads these posts.
You mentioned in Apollo 16. Did you mean Apollo X 16?

Originally Posted by Darryl Ramm

I would ran far away from this product. If you want an interface get a quality interface from a vendor who develops their own stuff, especially device drivers. By all means connect that up to 500 series racks but the interface does not need to live in the 500 series rack. Cranbourne may make great 500 series analog hardware, I have no idea. But that would not drive this decision on the interface for me.

These boxes are not great computer audio interfaces and do not have great interface drivers. Cranborne appears to use third party developed audio interface components inside this box, including also using a third party developed ASIO drivers. On macOS at least the class compliant CoreAudio drivers do not correctly report the interface latency, and the Cranbourne documentation has some pretty mind-numbing confused comments about latency in them. This is likely to cause phase errors for folks who are not careful about manually correcting stuff. There have been multiple users on DUC with latency problems with using these boxes as hardware inserts, all a direct result of this. With proper measurement and manual adjustment of ADC it's possible to get this to work. I've helped some users get sorted out who were having these problems, you can google for those posts. But that should not be needed. And the RTL latency is also just not impressive, if that's important to you. I also have no idea if the driver misreporting of latency was ever fixed or if anybody there understands any of this. Their support organization seems to have really wasted users time in the past not understanding latency related things.

There are so many really impressive interface available from vendors like RME, DAD, Motu, Focusrite, (and UAD),... companies that build the deep critical bits of their interfaces themselves and have great software teams developing and supporting their own drivers. RME is my personal favorite, but damn Avid partnering with DAD/NTP for MTRX and MTRX Studio just show up how nice stuff they have.

What is wrong with your Apollo 6X? You don't like the Apollo Console? Or would a Apollo 16 and a 500 series rack or two get what you want? Would you keep the 6X and thunderbolt chain that with other Apollo boxes?

[Darryl Ramm]

The concept is fine, if only their Audio interface got the most basic stuff like correctly advertising the latency through the driver, and for icing on the cake had good low latency then it might be interesting. Until then there are so many great interfaces, and many great 500 series racks that you can connect them to...

And yes I mean the x16. I would hope you can largely ignore the Apollo Console if you don't want to run UAD DSP plugins there. And if you are looking at 500 series hardware as an alternative to DSP plugins in the console nothing stops you doing that with a UAD, or any other, interface.

[mrgroovy]

Great input. Regarding the Cranborne 500 interface: are the latency issues only a reality using ProTools and inserting the hardware duriing mixdown?
Or is it also an issue during tracking? For example, it should not be an issue while tracking a vocal bye, using the following chain: mic > 500 preamp in the Cranborne > input in a PT track. Correct?
Another words, all tracks completed, in mix down mode, then insert 500 hardware from the Cranborne using any Q and compression, for example. That is when the latency issue comes into play - correct?

[Darryl Ramm]

All DAWs including Pro Tools rely on a set of latency data that an interface provides via it's the driver. That's a part of CoreAudio and ASIO. It's actually a set multiple parameters for input and a separate set for output, representing different parts/causes of the latency.

Pro Tools and other DAWs always use this latency data to correct the placement of recorded audio, Pro Tools does this always regardless of ADC being enabled or not. Without this things would be all over the place. With the wrong latency reported by the interface driver, as seems to be the case with the Cranborne your recorded signal will be laid down at the wrong time. So yes recording your vocals like you describe the vocals would be recorded at the incorrect time. How much this is noticeable, depends on what the actual latency is vs the reported latency, what the other content/backing tracks are etc. and how sensitive to latency/timing/possible phase problems the listeners are. I've never had a 500R "on the bench" if I did I'd have a whole run up of all the reported and measured latency specs at all sample rates and HW buffer sizes. Some owners shared some measurement numbers with me in the past and I think I've posted them on DUC before.

When the 500R reports incorrect latencies and you are trying to do H/W inserts though it then you have the sum of errors between the difference of reported vs actual input and output I/O errors. For hardware insert or especially hardware bus mixing folks may notice phasing errors, although the errors in these Cranbourne racks that I've seen users have to deal with are quite noticeable. The H/W insert latency errors are almost always manageable by manually adjusting the +/- ADC settings for a track that has an insert (or multiple, you can also jiggle around input tracks using that but folks might find just sliding around recorded content or using a delay correction plugin (like Eventide Precision Time Align) easier.

HW insert latency would just be easier to manage in Pro Tools had a ping function like every other DAW product. I don't understand Pro Tools not having this ages ago, it's just stupid. But just stupid on the part of Avid does not forgive a hardware interface vendor having an interface that publishes incorrect latency data, and these clear do based on a few folks I've worked with to solve H/W insert problems with them.

For a mix that is mostly done, if you run say a drum bus though a final EQ or compression then you'll have those misaligned with the other tracks unless you have corrected for the error in reported latency. None of this is rocket science but it sure is easy to slip up and leave something out of alignment/phase, how much that affects the final product depends .... and if you are dealing with external digital hardware then you likely have significant delays you have to manually adjust for there (again no ping function in Pro Tools). And many interface with multiple types of IO will not work correctly here either as Pro Tools (and most other DAWs?) will only use the input and output latency data for the first I/O ports on the device, others might be different, especially say if digital ADAT or MIDI, and then there is no way for the ADAT or MIDI analog interfaces/preamsp to tell the interface what their additional conversion latency is (but that often only a small number of samples). I've written about all this multiple times before on DUC.

So again, it's horrible that Pro Tools lacks ping, but that is still no excuse for hardware vendors to screw up and make stuff even harder. Most problems with H/W inserts seem to be caused by user confusion, and stuff where interfaces are reporting wrong latencies just push folks over the cliff, even if they are correctable, but then if there was a ping users would not have to deal with this frigging mess. Occasionally there are bugs in Pro Tools that need to be worked around.. but you should always be able to H/W insert latency to work correctly, it's just the pain level involved.


And then there is the other issue of how the absolute latency of the interface and if you want low-latency software tracking if this is small enough for your needs, largely dependent on your ability to run tracking sessions at small H/W buffer sizes. And for stuff like that I'd personally be most comfortable with an RME driver especially on USB interfaces (low absolute latency and good performance at small H/W buffer size).

My annoying auto spell corrector is driving me crazy insisting on correcting Cranbourne to Cranberry, so in addition to fixing their latency reporting issues it would be great if they could please rename their company

[mrgroovy]

Thanks for the detailed info, Darrell. It was very clear. Some comments - you write:
… I don't understand Pro Tools not having this ages ago, it's just stupid. But just stupid on the part of Avid does not forgive a hardware interface vendor having an interface that publishes incorrect latency data, and these clear do based on a few folks I've worked with to solve H/W insert problems with them.

Totally agree. I’m not a code expert, but I can imagine that it would not be a high cost item for AVID to fix. If other companies can do it, such as Reaper -they can

You write: And many interface with multiple types of IO will not work correctly here either as Pro Tools (and most other DAWs?) will only use the input and output latency data for the first I/O ports on the device, others might be different, especially say if digital ADAT or MIDI, and then there is no way for the ADAT or MIDI analog interfaces/preamsp to tell the interface what their additional conversion latency is (but that often only a small number of samples). I've written about all this multiple times before on DUC.

Well that would add even more fun for the hair pulling. As you could probably surmise - I was really hoping this chain would work for me. An interface and 500 box in one which would allow me to take advantage of some hardware when I needed in home studio seemed to be a dream come true. I am primarily a songwriter who works best when my engineering needs are minimal to reach maximum fidelity.