Holiday notice: Cycling '74 will be closed Monday, October 9th. Manual authorization, support cases, and manual order processing will be delayed.
Can I keep multiple sets of IO Mappings around
Jan 30 2013 | 5:38 pm
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
Thanks for any help or suggestions.
(Edit: changing underlying plist didn't seem to work)
- Jan 30 2013 | 6:34 pmHi, to map between logical and physical in/outs, may use matrix~, independent from I/O mapping in DSP. Best, Helmuth
- Jan 30 2013 | 8:30 pmNo, 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.
- Jan 30 2013 | 9:20 pmBy replacing your 's by 's, in order to make your map more versatile/dynamic?
- Jan 30 2013 | 10:44 pmI'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.
- Jan 30 2013 | 11:17 pmIf you pull I/O mappings apart you can see how it works as a Max patch. Should be a pretty simple pattr exercise.-A
- Jan 30 2013 | 11:34 pmIf 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.
