efficiency questions - multiple adc~?

Zh's icon

Hi -
There's recently been a discussion of the efficiency of multiple dac~ objects, here: http://bit.ly/FHIS1
Someone said that it doesn't matter how many dac~ objects you use, because it all gets compiled down...

Question 1: is this the same with multiple adc~s? I've dropped in an adc~ object just above wherever i need one, (e.g. above a record object) and now i'm worried that it's inefficient. Is it more efficient to have one adc~ with send~s and receive~s? Or is an adc~ object already the equivalent of a receive~ from something central behind the scenes?

Question 2: is it the same for midi inputs becoming max events? is it more efficient to have one midi'in object sending and receiving around your patch, or several midi'ins dotted around? same thinking - is each midi'in really its own midi-event-watcher, or is there some kind of a central one in max that all midi'in objects share?

NB i'm talking about send/receive here & not patch cords, because I have several patches using the same main audio and midi i/o patch, not all of which are open all the time.

hope you can help - i have a performance in a week and i need to make my (big) patch as efficient as i can!

eek
nick

diatom's icon

Amazing this appears to be the only post I can see asking this yet I thought it would just be in the docs. I've inferred from arbitrary specification of outputs and channel IDs that it is basically pub/sub.

Roman Thilenius's icon

maybe it is think ice, but from what i know all these IO objects, be it audio, midi, serial, firewire, networking, can be considered just instances of the same object.
just as 2 copies of [buffer~ foo] or [thispatcher] in the same patcher are the "same object", too.

dac~ and adc~ for example are representing the audio driver (or virtual audio driver) currently active in your system, and those audio IOs are usually not multiclient (i.e. at least not with the same driver.)

so you save nothing with using less instances. the use of s~ and r~ will raise the CPU consumption.