I use multiple dac~ and adc~ in a lot of patches so I hope not! For example I use an adc~/dac~ 1 or 2 or 3 or 4 in the area of the patch it needs to connect to rather than having a massive web of signal cables all over the place, or using sends and getting a vector delay.
I've run into no problems at all doing this, so I think it's fine to do.
perhaps there are exceptions in which multiple adc~/dac~ objects might be necessary, but 99.9% of the time these objects should be used analogously to your hardware. this is fundamental to your balance - you don't get two stereo master mixers in cubase, nor do you on your analogue mixing desk
I use both dac~ and ezdac~ in many of my patches. I use the dac~ for signals as part of my patch, the ezdac is usually just set to be eyecandy and configured so that the icon changes to some obnoxious color so that i can tell at a glance when my patch is live. I kind of wish dac~ just had an indicator light on it:
on: dac~ *
* == bright LED
I would just set that to so huge-ass font and use that, but i like to have some indication that the dac is on.
It never had a problem doing this and it never occurred to me that it would be one.
goodparleyandorfing wrote on Sun, 09 August 2009 07:40perhaps there are exceptions in which multiple adc~/dac~ objects might be necessary, but 99.9% of the time these objects should be used analogously to your hardware. this is fundamental to your balance - you don't get two stereo master mixers in cubase, nor do you on your analogue mixing desk
You won't get two stereo master mixes when using multiple dac~ objects, each [dac~ 1] would be like a connection to the output channel 1 master bus on a mixing console (apart from you have no "master fader"). Also, if there were potential problems involved with using multiple instances of the same output channel, they would probably be in the dac~ reference.
The only downside I can see from not summing all channel 1 signals into a single [dac~ 1] inside maxmsp is that there is no way to monitor the summed signal level internally. You would have to rely on the metering of your audio interface, which is what I prefer to do in many cases. Keeping a good gain structure within a patch is just common sense really.
Try the patch below instead. I assume the problem was the "symbol" being prepended onto your [coll] output but you didn't save the [coll] contentes with the patcher so I couldn't see what you had in there.
You can see all the attributes of an object if you open the inspector and click on the @ sign in the bottom left corner. You can also drag an attribute onto the patch it will create a preformatted message, if you drag it onto the object it will make the connection as well.
Actually if you look at the one i just posted and toggle the dac~ on and off a dozen times look at what happens to the size of the dac~ box. It just keep inching it's right border over getting longer and longer. So... i guess that is going to muck up the patch to dynamically mess with the font like that. I just kind of liked the idea of the dac~ going bold when on.
This stuff seems silly, but it is actually helping me learn some helpful stuff in Max 5 like how to use attributes, which, just last night i used to make transports locked into metros that went at different speeds. by using
timlloyd wrote on Sun, 09 August 2009 09:23The only downside I can see from not summing all channel 1 signals into a single [dac~ 1] inside maxmsp is that there is no way to monitor the summed signal level internally. You would have to rely on the metering of your audio interface, which is what I prefer to do in many cases.
adoutput~ ? It's delayed by one signal vector, but that's not really going to be an issue for visual monitoring. That way you can avoid cabling headaches when necessary, but still maintain the ability to see what your levels are.
timlloyd wrote on Sun, 09 August 2009 16:23(apart from you have no "master fader").
well this is what im referring to really.. only using a single dac~ or ezdac~ after a master gain control is just a good way to think about routing audio. i still can't see why you could possibly want more, aesthetic reasons aside.
I think it's completely an aesthetic reason. It is sometimes confusing to have signal cables all over the place if they don't need to be, and it makes it easier to see what is going on in the patch. I tend to get annoyed when looking at messy patches.
It's just personal preference I guess.
Its easy enough to do something like this to have a master volume without the cable mess, and without vector delay from send~/receive~ pairs.
heh.. that's an interesting way to implement a master mixer.
but your method is somewhat idiosyncratic. id maintain that, at least as beginners rule, the [dac~] object should be used only in your parent patch to represent your audio channels. having a bunch of them nestled away in different sub-patchers etc is a classic beginners goof; no global control, balance/clipping issues etc etc etc
that said, i think i'll pinch that scripting trick, it's nice.