Forums > MaxMSP

Unwise to have multiple dacs?

August 9, 2009 | 6:47 am

Hi All,
Is it unwise to have multiple dacs in one patch? Is it best to have only one dac per patch?

Psmxam


August 9, 2009 | 8:47 am

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.


August 9, 2009 | 1:40 pm

It’s all going to get compiled down to an equivalent DSP graph in any case, so it really shouldn’t make any difference.


August 9, 2009 | 1:40 pm

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



kp*
August 9, 2009 | 2:58 pm

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:

off: dac~
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.


August 9, 2009 | 3:07 pm

You could use dspstate~ and an led/comment/label to tell you when audio is on. Not any different from using ezdac though really.


August 9, 2009 | 3:23 pm
goodparleyandorfing wrote on Sun, 09 August 2009 07:40
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

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.



kp*
August 9, 2009 | 3:57 pm

That works well too. It never occurred to me to do it that way.

– Pasted Max Patch, click to expand. –

August 9, 2009 | 4:58 pm

You could change the colour of the [dac~] directly for the [ezdac~] effect but with more channels.

lh

– Pasted Max Patch, click to expand. –


kp*
August 9, 2009 | 5:05 pm
[email
thereishopeforus@hotmail.com[/email] wrote on Mon, 10 August 2009 01:58]You could change the colour of the [dac~] directly for the [ezdac~] effect but with more channels.

woah…. very cool.



kp*
August 9, 2009 | 5:28 pm

but this doesn’t work…

– Pasted Max Patch, click to expand. –

How do you know which messages will work and what there names are? example sendbox bordercolor is not shown here:

file:///Applications/Max5/Cycling%20’74/docs/refpages/max-ref/jbox.maxref.xml

or

file:///Applications/Max5/Cycling%20’74/docs/refpages/max-ref/thispatcher.maxref.xml

sorry… i know this trivial and all but it is kind of fascinating discovering all these new bells and whistles.


August 9, 2009 | 5:36 pm

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.

lh

– Pasted Max Patch, click to expand. –


kp*
August 9, 2009 | 5:50 pm

oh…. dang. Right. I just had

0, plain;
1, bold;

this works too:

– Pasted Max Patch, click to expand. –


kp*
August 9, 2009 | 5:59 pm

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

transport @name foo
transport @name bar

Very cool.

-kp


August 9, 2009 | 8:24 pm

if you want to have multiple dac~s in your patcher/runtime, and
you want tro be able to turn them on and off one by one, you
can just put them in poly~s and mute them this way.


August 9, 2009 | 10:53 pm
timlloyd wrote on Sun, 09 August 2009 09:23
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.

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.

Regards,

Alex


August 9, 2009 | 10:58 pm

ahhh, thats awsome!

gonna be using that now


August 10, 2009 | 9:33 am
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.


August 10, 2009 | 1:10 pm

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.

– Pasted Max Patch, click to expand. –

August 11, 2009 | 10:28 pm

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.


Viewing 20 posts - 1 through 20 (of 20 total)