It’s been a while…

I think there’s something quirky about Motu’s numbering.

I could be wrong, but I think the preamps are what shows up as 1 and 2, in your DAW. On the back of the Ultraluge, (autocorrect, but i’ma leave it.) what says Outlut 1 and 2, will actually be 3 and 4 in your DAW. Displace the output numbers on the back to accommodate the preamps as 1 and 2.

Does that make any sense?

4 Likes

Honestly, I’d check Cuemix just to see if outputs 3 and 4 are sending signal. If they aren’t, then it’s likely either an Ableton issue or a Motu problem. If CueMix indicates you’re outputting signal, try plugging the Motu output into another device (or really just plug a 1/4" heapdhone into the output and see if you hear something). Then it would be the Norns.
I haven’t used Ableton for a long time but I remember the output config being a bit of a pain… but if you’re certain the outputs are activated and the levels are up/not muted, then checking CueMix would be the next step in verifying the signal path…
As @MtL says, there is also the issue of output numbering. Ableton 1 and 2 are the main outs. Ableton 3 and 4 are labeled outputs 1 and 2 on the back of the ultralite.

1 Like

Gosh apologies, it was indeed the routing of the numbers being different between Ableton and Motu! Thanks!

2 Likes

Welp friends, it has finally happened:

NSFW (j/k)

MOTU UltraLite mk3 you have served me valiantly over the years. Thousands (millions?) of hours of audio has been routed through your venerable 8 ins and 10 outs. For the last year or two I haven’t been able to launch your software, but still you were able to be selected as my interface. Alas, today was the end. I didn’t know just a few days ago was to be our last time together.

I love you MOTU UltraLite mk3.

6 Likes

What happened? Mine is still working (I hope)! Why did it go bad?!?

1 Like

Is that perhaps just going into a Thunderbolt dock USB C port? I can generally get this same ridiculous adapter chain working as long as it is a thunderbolt 3 port at the end and not a USB C.

Many thunderbolt 3 docks I’ve run into have only a USB C/DisplayPort additional connector instead of an entire additional TB3 port.

2 Likes

@eblomquist @nojay OH WOW. It was the adaptor. When I plugged it direct in it worked!!! This is the adaptor I’m using. Wowwwwwwww. So USB C != Thunderbolt 3. Interesting…

6 Likes

I have a very similar setup to you and here’s what I do:

3 rows of 48pt patch bays
16ch converter
Rupert Neve summing mixer/panner

From the bottom:

Pb1, inputs: 8ch snake normals to input of 8 pres, output of 8 pres normals to input of my converter. Rest of this row is in/out of a Tascam syncaset 8ch cassette. 4 XLR taps directly to my converter for non-pre/no-color inputs, not via pb—just hanging tails.

Pb2 in/out of the box and summing: Line send/return from converter by way of Rupert neve summing mixer, Sum 1 & Sum 2 normalled to remaining 4inputs on converter, I/O for my favorite stereo bus compressor, I/O for Nagra IV-S.

Pb3 Effects and hardware: I/O for all the hardware compressors and EQs and delays etc as well as a Nakamichi Cr2A.

Converter AES out feeds a drawmer monitor controller.

That handles all the mixing desk stuff and record media (cassette multi and 2ch, 1/4” 2ch, computer).

My synth corner has the snake box: 8 ch in to PB1, 4 back out (from PB3). I can run stuff raw to the pres through this or, more commonly, I mix down to stems via SiX or a Tascam 8ch cassette mixer/recorder.

I have a plan for a patchbay for all my electro gear but haven’t committed to it yet.

The things which really make this work for me are:

The snake to bring my inputs where I need them (and the patchbay to flexibly route as I choose though honestly I rarely reroute as I like how the normals are set—but one thing I do often is route from snake to pre then patch a compressor in before the converter because I like compressing once before hitting the converter or tape etc).

The neve summing mixer absolutely solves my in-the-box/out-the-box style of mixing and processing. It’s useful for that even if you don’t go for the analog summing thing.

Drawmer monitor controller solves a ton of headaches with speaker selects, iPhone inputs, and some genuinely useful mix tools.

If you are only going 8ch in/out then you’d maybe plan on a different summing path or perhaps use the SiX to do both summing and monitoring. You’ll also have a lot more breathing room in your PB (room for more processors! :slight_smile:)

Let me know if any of this makes sense.

3 Likes

So I decided I needed a schematic to help me make some long term decisions about where I was headed with all of this and exactly how much money it would take to get things setup and organized. It’s certainly a worthwhile exercise. In the end, I made some more decisions:

  • 3 snakes: one for mics, one for things on the left, one for things on the right.
  • A new interface is next: the basic problem I’m trying to solve is how to use the gear I have and track more than 2 or 3 instruments/vocals at a time - my limit is Preamps and channel count.
  • Apollo 8 is most likely the best fit: I get 4 more preamps and it ties into my current workflow with the Apollo Twin seamlessly.
  • I still need a mixer: for now, I’ll keep using my small A&H for “loose” patching - random table top stuff and quick routing. Still want an X-Desk. (I even worked out a way to chain the A&H output to the X-Desk summing using their linking system!)

In that spirit, here is a concept of how it all might fit together with an X-Desk. I even did analysis on all the cables needed to make sure I wasn’t going to have a huge investment in cabling that I can’t use down the road.

I realize this isn’t directly relevant to anyone, but it was useful for me to do this for my situation so wanted to share my ideas. Definitely open to feedback on whether anything in this plan doesn’t look right or “isn’t done” for whatever reason. I’m not a pro!

(Done in Google Sheets I might add which made it REALLY easy)

2 Likes

Not to go too offtopic but this is a common misconception due to the connector format. They are indeed not at all the same.

Thunderbolt 3 is by far more capable and provides for a wider range of hardware possibilities and throughput. USB is simpler to implement and has some standards around behaviour that permit class based driverless behaviour which TB3 does not. They are targeted at different needs and optimized for different applications and markets. Sharing the connector is the only thing they have in common. For what it’s worth, DisplayPort did that with TB2 causing people to confuse those protocols too.

2 Likes

They made a complete mess of that connector which can carry a variety of “partner mode” data including HDMI, DisplayPort, and Thunderbolt, which itself can carry USB data. And obviously someone proposed Ethernet because didn’t stop to think if they should.
Expensive adapters for all. I’ll go by Firewire for as long as I can source stable adapters, or this perfect hash of a situation is resolved in favour of something I don’t have to dedicate cognitive resources to.

3 Likes

To avoid confusion, this is technically not correct. The Thunderbolt protocol is effectively an encapsulated, serial PCI-e bus (leaving out yet further complications). Since nearly any adapter can be given a PCI-e peripheral connection, you can adapt everything from graphics adapters to USB controllers to DSP cards. USB itself, as a protocol, however, is NOT directly encapsulated by Thunderbolt 3 - it still requires a PCI-e protocol conversion, which means active hardware (e.g. a dongle), not simply electrical interface conversion (e.g. a cable).

I get that people are confused by the sharing of the connector, but that’s analogous to saying “you can carry data over wires”… it’s useless without specifying how in a myriad variety of ways (electrical signal levels, which wire means what, thence what the signalling pattern is to indicate data, ack, nack, flow control, error detection, thence the sequence of bits to identify, control, and communicate with each device on the bus or link endpoint, thence the control protocol for the device, and so forth). The connector is just a way for wires outside the computer to connect to wires inside the computer, absolutely nothing more.

Also, “Thunderbolt” as I’ve outlined above, is a specific set of meanings for those wires AND signals that go on them AND a method for devices to communicate to the computer AND some very basic layers of the methods for controlling them. USB is a completely different set of these core protocol specifications, plus MUCH MORE in terms of how the OS itself is aware of and generically provides driver support for certain classes of them.

While USB-3 and to a much greater extent USB-4 provide commonalities by which the appropriate protocol can be chosen and thus each is a little more aware of the other, they’re still by no means the same standard, they’re just closer to interoperability. USB-4 will be, if anything, even MORE confusing as it, as a protocol, is even more similar to Thunderbolt 4 (and they both have a 4 in their name, and share a connector, etc) but there ARE differences even there (Thunderbolt won’t provide backwards compatibility to any USB protocol, for instance, whereas USB-4 is a negotiated layer that can provide access downwards to them as fallback), and boy I can’t wait for the confusion here to start when cheap devices and dongles that really can’t translate between them well are abused for that purpose unknowingly.

In short, it really pays to know the differences between the protocols versus the connectors and what types of devices (and thus dongles) you’ll need to adapt what to what. But in near-universal cases, Thunderbolt “upstream” (e.g. on the computer end) can always adapt to USB “downstream” (e.g. towards the peripheral) but NOT the other way around.

Another takeaway of this is that you will always be able to adapt Firewire (downstream) to Thunderbolt (upstream) but it’s highly unlikely you’ll be able to generically adapt Firewire to USB-* (at least until USB-* becomes identical to a Thunderbolt-like generic bus) because Firewire itself is a very generic bus and does not translate to the command-orientation of USB protocols.

As people re-discover the joys of older audio hardware (the human ear hasn’t, after all, changed much), adapting older hardware will only become more confusing to the newer interfaces you’re going to see coming down the pipe, so best to at least comprehend this non-symmetrical relationship between TB-X and USB-X as it will drive the next generation of expansion ports.

9 Likes

The USB4 specification is based on the Thunderbolt 3 protocol specification.[2] Support of interoperability with Thunderbolt 3 products is optional for USB4 hosts and USB4 peripheral devices and required for USB4 hubs on its downward facing ports and for USB4-based docks on its downward and upward facing ports.

I’ll take your word for it but that’s how it reads to me. I get that their idea was to basically merge the two but I can’t understand why they’re going through so many iterations. I understand that the meanings change depending on context - sometimes we talk about protocols and sometimes about electrical wires and connectors, but I always put on a user hat in this - if it looks like a USB cable, I expect USB to work, and if it looks like a Thunderbolt cable, I expect that to work, and now the cables both look the same, here we are — talking about PCIe which not many people care about…

adding wikipedia’s “data” section for Thunderbolt (interface):

I see USB 3.1 gen 2 there.

Yes, I mentioned this in the fact that you can adapt the USB protocol to the thunderbolt interface but not the other way around. The protocol is implemented using a UHCI bridge adjacent to the thunderbolt that participates in the port protocol negotiation process and takes over if the port is USB, just like the DisplayPort protocol handler does for DisplayPort. In some silicon this is integral to the chipset, in others it is a separate one that gets control passed through. The point remains - a thunderbolt upstream PORT (e.g. interface) is compatible with the USB protocol (but Thunderbolt, itself, is NOT USB and does not encapsulate it directly, the USB host becomes a device on the Thunderbolt bus, just like plugging in a USB PCI card into a motherboard adds USB ports to your PCI backplane, but PCI is not encapsulating USB) but USB interfaces even if they share the same connector are NOT compatible with Thunderbolt.

Edit: and in some cases, the USB host is not actually even on the Thunderbolt bus once the negotiation is successful, it connects via it’s own method or is passed through to the CPU’s own USB host interface.

…hence my saying USB-C connector carrying data from Thunderbolt controller but actually USB - be it a USB “device” on PCIe or controller passing through USB directly to CPU. Sure, USB ends up on USB-C connector but not before we got ourselves a fine mess of hosts, protocols, and connectors, and it’s hard to tell which one does what and where some incompatibility emerged. And thus my point about expensive adapters.

See Focusrite Red4 and Red16 - both Thunderbolt - mDP connector on the back of the former, USB-C on the latter. … just … no. too many variables.

One question: are you using dedicated snake boxes or just connecting cables directly to the snake (i.e., XLR chaining)?

I ask because I was kindly gifted a box of Gepco snake cables of various lengths and connections - all with E3s on one end which was awesome! One of the snake has a bunch of XLR connectors that I could use in lieu of a snake box which would cost about $100 or more.

Also, I like the idea of a monitor controller. I think I can use my small ZED mixer as a monitor controller - its not obvious from my schematic but I plan to connect my monitors directly to the mixer and use the Playback input on the ZED to control the computer/interface audio going to the monitors. I’m not 100% sure whether this is a good idea although I believe the mixer is reasonably transparent. If I ever upgrade to an SSL mixer, the monitor connections will move to that unit. Open to feedback on all of this…

Thanks for such a detailed post!

1 Like

We could probably use a dedicated Patchbays topic haha.

I connect gear directly to the snake box via TS/TRS->XLR cables or via passive DI (DIYRE are my faves but I also have some ART and others). If I had a snake cable then that’s what I’d use instead of the snake with the box.

The main purpose of this thing is to get inputs (and occasionally outputs if I want to mangle something I recorded in the computer) over to where my gear is. Right now I tend to plug into the box on the fly, but soon I’ll have another patchbay for the electronic toys section of my life and then that snake will get connected to 8 outputs on the patchbay. It’s a lot of excess cabling but I’m ok with that. If I need something especially precious I’ll run a long cable right to the pre or the converter.

If you can connect your gear to your patchbay with one cable I think that’s a good thing to do. You can always re-route them at your patchbay if you like.

I think your idea with using playback via the ZED is perfect as is your upgrade path. No need to get another piece of equipment if you don’t have to. The Drawmer is handy for me because multiple monitors/headphones and being able to source from computer and two or three different tape-based machines (plus some handy filtering/phase/mono stuff mixing which is tasty gravy). But I think your plan sounds great, it’s exactly what the playback input on your ZED was designed for.

Nothing is transparent except a live performance in an anechoic chamber. As long as you learn what your gear sounds like and how it translates in different playback situations, then you’ll be fine and can worry less about how transparent everything is. In this way, it’s good to find a setup and spend some real time listening to it and using it so that you learn how it sounds vs other environments. And then learn how to adjust your mix accordingly instead of tearing apart your house or buying gear in an attempt to fix it.

1 Like

Ok, quick sanity check. I’m still running an i7 3770k, 32GB of ram on an Intel motherboard that has a TI FireWire chipset, an OG PCI slot as well as a 16x PCIe 3rd gen slot. It might be showing its age but it’s “modern” enough to track audio without a hitch. I’ve been using Saffire 40 this whole time as well for home and person use - since 2012 at least. I’ve noticed that the old RME PCI cards are going cheap these days and I’m still running a machine that can use them.

Is this a dumb idea? I suppose I’m thinking that yeah, it isn’t that fast by modern standards but there are loads of high performing usb2 interfaces out there pushing loads of audio with less theoretical bandwidth. Perhaps the round trip latency on the PCIe stuff is better but I’d imagine we’re talking less than a millisecond. Plus it’s RME so I know the Windows driver is stable.

Considering it’s probably going to be more stable than FireWire on Windows 10 I’d also be gaining more adat I/o so I could justify fooling with the expert sleepers stuff. Just let me know if I’m crazy, my wife listens but doesn’t have much practical advice on the topic.

1 Like

People still do MIDI sequencing on Ataris, of course you can record audio on a slightly outdated PC.

We’re culturally indoctrinated to thing that the presence of new things make old things less useful. We should try to judge the thing on its own merits. Does it solve the problem? In your case I think the answer is yes. Audio isn’t that intense, old computers can handle it. The RME card should compare well to newer, cheaper audio interfaces.

3 Likes

What can you recommend as audio interface? 8 channels, preamps are not needed. Very Stable on Win, clean sound. Midi out is good as a plus. I’m thinking about RME UFX i/ii gen but have some doubts in adc. I have babyface and axe-fx 2(as audio interface) and all the time prefer recording through Axe.