dhjdhjdhj

I have been using a Max based system on my laptop to control a live keyboard rig. There are two MOTU 828s connected via Firewire and I created an aggregate device so that the two MOTUs' inputs and outputs how up as a contiguous range from 1 to 60.

I bought a second laptop to take on tour as a backup in case first one dies. The new one has Mountain Lion installed. However, it turns out that there is a nasty problem where you cannot control the order of physical devices for an aggregate device and my MOTUs are showing up in the wrong order on my second laptop.

Although I just found out that I may be able to deal with this by editing the underlying plist file for the audio devices, I'd like to have a way to easily remap an entire set of inputs and outputs without having to do it manually from the I/O mappings stuff in DSP Status.

I'm assuming that the way to do this is with adstatus but it's not at all obvious how to do it without having to create an object for each output.

Alternatively, I've observed that when I change the mappings, they persist so there must be a file that I could get at, copy/edit and then put on the other machine

(Edit: changing underlying plist didn't seem to work)

can-i-keep-multiple-sets-of-io-mappings-around

to map between logical and physical in/outs, may use matrix~, independent from I/O mapping in DSP.

Hi,
to map between logical and physical in/outs, may use matrix~, independent from I/O mapping in DSP.
Best,
Helmuth


No, that doesn't help. For a start, I already have a large Max system implemented and it would be completely unfeasible to redesign it. Secondly, as I understand it, matrix~ is simply a way to redirect different audio paths. You still have to send them to [dac] objects and that's where the problem lies.

I have a large number of [dac] objects around the place (often getting instantiated on the fly, initialized to outputs depending on what's using them). Fortunately, those outputs are "logical" numbers although by default mapped to "physical" numbers. So changing the map is the only solution I've got at this point.

By replacing your 's by 's, in order to make your map more versatile/dynamic?

By replacing your 's by 's,  in order to make your map more versatile/dynamic?

I'm already doing that ---- the s are associated with a virtual mixer and audio is already transported from place to place through objects. I already have the flexibility to send audio from any vst to any dac although I'm doing it by changing the receiver of the object.

More importantly, this particular issue is one of configuration to address differences in hardware, not something that should be part of any patch. If this problem was addressed within patchers, then the same patchers would not work properly on different hardware.

For this particular issue, the fact that Max supports the extra level of indirection down at the [dac~] level addresses the problem completely. The I/O Mapping is exactly what's needed. Changes in I/O mapping are stored with the global Max environment on each machine and that's the right place for this kind of thing.

I suspect the Max developers must have been very familiar with David Wheeler's aphorism.

I'm already doing that ---- the s are associated with a virtual mixer and audio is already transported from place to place through  objects. I already have the flexibility to send audio from any vst to any dac although I'm doing it by changing the receiver of the  object.

I suspect the Max developers must have been very familiar with David Wheeler's aphorism.


If you pull I/O mappings apart you can see how it works as a Max patch. Should be a pretty simple pattr exercise.

If I had the luxury of spare time on my hands before leaving for tour, I might have gotten to looking it at it myself. But I'm leaving first thing in the morning and I only discovered this problem today when testing a backup machine which had Mountain Lion on it.

Everything worked perfectly fine when testing with a single MOTU device in my office, it was only when I connected it up to my keyboard rig where there are two MOTUs chained together that I encounted this --- who would have thought their aggregation stuff broke!

By the way, nice writeup of your work with Herbie.

If I had the luxury of spare time on my hands before leaving for tour, I might have gotten to looking it at it myself. But I'm leaving first thing in the morning and I only discovered this problem today when testing a backup machine which had Mountain Lion on it. 

By the way, nice writeup of your work with Herbie.


Can I keep multiple sets of IO Mappings around