Can I keep multiple sets of IO Mappings around
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)
to map between logical and physical in/outs, may use matrix~, independent from I/O mapping in DSP.
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?
----------begin_max5_patcher---------- 1181.3ocyYstaiiBE92NOEn7qckxFYvWh87DLuCUipH1zDl0FrrIoM6n1m8E C1IlVbq6zDF2J4jdfC7w24Bmi6uV3sbK+IRyRv2.2A7790BOOknVAdc+s2xR 7SYE3F0zVxHOx29ykqzCIHOIThq.UXQ197Ckkm5GjlqFRN8+AF1KjcnjxJHB 0p42I7ANSvvkD07+No3HQPyvCTgePXSmF5+ozAhV2KVACJa280jLg9fgfAxg AIoWdBSV6C9wPUH0cG5tSsbCnEjij5FJmo1iUcxwUUCD6MPkVp5mb0BEs5rH JSKBdVTM4HsW+TsvmWzu7WvcTXKTSUOiC8a+HLw+BvklpcE7r+kjOfW7VlSd 3yrF7JB6x7Uyv3g4LorpZRCgIvhtCvv8EenPbucCi43OfyHip7ndBdK2USy4 rVfXncq39s7N.LRYhiFhc0LX3JKJK37hs35VSx1BhgoVFJfYzRrPhBMlP9m0 iVVUSYBi0hvvx0XeSVMunvXozibzxH4RugLxizbwd0ZcgwLBNG5mMLH0P9qB Vy3kkRaUO8YDwhY4fFNfyVK+Y3LFF1BGNfQnKbv.uuQazP32ILdrP4f3jVaK p2D6eIXtWumWrn+KqtAzVMop.mIQE3D+PMHGm8xHjWxLi6PPEagBRukbmw8C lTmLsQ9KfsiPWwyM5JMU6pE29gNOpKYqrSYEjw7shFkrPeAxZHQqEKNU0kTc YCcGCKyb8iu.ipBdgaPpqghbdraUMOizz.TUo.GgZCmY9gPjhtfPzenv1c0b 9wQ8DQiRWAeA5BMAOwUWEeRcsgvMA+Yhx04Dwic+6r6JjfomS7RwWET1X0wn 1j1wsSiMx6Xy5s6cI9.9F16bRifxNWN5cmuM4UyaOMO2rxOc044UbYUbcvah l8OKpQSD0vqHp6D12XwxF7QR98xcQZMuGKD0zsGDZyxvtdtFUo+AC+QMJHap YKtnqqryqiwp+Fj850ZwE1P8TaEmRCtlWfbIRsDSY.YTT0AQorEPYfwJ.Y8t 0fDP1dLiQJZVAxjvPVfOIGr8jrzZBHmjKO5Bo.YWD0zmdA7WsEdK1SjBp.MB dsbLAGrk.jwY3hVcebOgAXj16pv0m96dnz5vkwOna4HxRS1AVaxF5jlrg5jA cWwqukJNtO0vmzFLxKYPtaDp7pHvdauhA3U6z2qyGUCzmfdhSUoLQ9ndhYXl yqL8ryF83OqoGDzczyCVnmz4L6DoqUtmcBtorCwB6jLmYmvMNz2I2B6rYNyN A5LxtgcxrvNwyZ1AE3N1YqE1IZNyNnPG56fsvNgyY1o68XbSYm1WuH.BPf.P HHBDC1.RrvSHq7Thi9uqnR+FjnngfTzsfG5KdNQ9KbssxatZLP5G3or5Z8sB Zi32yuSmyJDoaBGZkvUKrYm2Z9+08t1YEdSOqPilQemFV2bdNuoYU6Mp9FWh ICI+IBoXmAozIhnHmgnjIhnPmgnMSDQANCQwSDQHmgnnIhHnyPT3DQju6B+M R1XGQH2lPxHWy3HJ1oHJZBHJxoHJbBHJzoHJXBHJvoHBMADgbJhfS.QPmhH+ Ifne27Qx+34E+OjOrgsE -----------end_max5_patcher-----------
I’m already doing that —- the
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.
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.