Forums > MaxMSP

sending audio via the send object (not send~)

June 6, 2007 | 5:03 pm

Hello, I’m relatively new to Max/MSP patching (just shy of a year), and a more experienced max patching friend noticed I had a patch with audio being sent via the send object. That’s the one WITHOUT the tilde ~ at the end of the name…

strangely, it works… but obviously it shouldn’t, right?

Now I’m just wondering why it works and what sending an audio signal through an object designed for message routing would do to the audio… it sounded OK, but obviously gave me some random wacky behavior.

I’ve since done a search and replace on all my improperly patched send objects for the send~ object.

thanks for taking the time to educate a n00b.

cheers!


June 6, 2007 | 5:36 pm

ed guild wrote:
> strangely, it works… but obviously it shouldn’t, right?

It *should* work, although I’ll agree it can seem counter intuitive at
first. It’s been discussed on the list quite a few times, so an archive
search should turn up a more technical justification should you want one.

Send~ and receive~ are necessary for situations where you (may) want to
create feedback networks.

> Now I’m just wondering why it works

Because s/r cope with any data type whatsoever.

> I’ve since done a search and replace on all my improperly patched
> send objects for the send~ object.

No need – in fact (although I may be wrong) using vanilla s/r may carry
less overhead than s~/r~.


O


June 6, 2007 | 5:47 pm

it will work,

what send~ does is introduce one signal vector of delay so you can do
things like feedback.

you wont be able to do feedback type of operations because of the
lack of delay in send vs send~. Someone else with more audio chops
than I will be able to explain better, but that is my understanding
of it

On Jun 6, 2007, at 1:03 PM, ed guild wrote:

>
> Hello, I’m relatively new to Max/MSP patching (just shy of a year),
> and a more experienced max patching friend noticed I had a patch
> with audio being sent via the send object. That’s the one WITHOUT
> the tilde ~ at the end of the name…
>
> strangely, it works… but obviously it shouldn’t, right?
>
> Now I’m just wondering why it works and what sending an audio
> signal through an object designed for message routing would do to
> the audio… it sounded OK, but obviously gave me some random wacky
> behavior.
>
> I’ve since done a search and replace on all my improperly patched
> send objects for the send~ object.
>
> thanks for taking the time to educate a n00b.
>
> cheers!
>
>
> –
> //
> ed guild
> vizzie.com
> myspace.com/psylab

v a d e //

http://www.vade.info
abstrakt.vade.info


June 6, 2007 | 6:01 pm

On 6 juin 07, at 19:47, vade wrote:

> what send~ does is introduce one signal vector of delay so you can
> do things like feedback.

it introduces a signal vector of delay only if it’s required.

ej


June 6, 2007 | 6:01 pm

so I’m not doing anything like forcing the audio signal to conform to message processing cycles? e.g. every millisecond instead of 44.1KHz?

I feel like changing the send to send~ did actually seem to improve sound quality of my drum sampler patch, but it could have been merely suggestive since I thought I was fixing something…

thanks for helping me clear this up.


June 6, 2007 | 6:26 pm

On 6 juin 07, at 20:01, ed guild wrote:

> so I’m not doing anything like forcing the audio signal to conform
> to message processing cycles? e.g. every millisecond instead of
> 44.1KHz?
>
> I feel like changing the send to send~ did actually seem to improve
> sound quality of my drum sampler patch, but it could have been
> merely suggestive since I thought I was fixing something…

would be nice… but that’s something else. The length of the
connections does not affect the sound quality either ;)

> thanks for helping me clear this up.

You’re patch will be more efficient (CPU) ‘cos send~/receive~ copy
each vector. There some limitations though, as vade pointed out.

ej


June 6, 2007 | 6:35 pm

this previous post was also brought to my attention…

http://www.cycling74.com/forums/index.php?t=msg&th=944&start=0&rid=0&S=8d4a4b827892abfa571dcb242a571a15


June 6, 2007 | 8:55 pm


June 6, 2007 | 9:25 pm

On 6 juin 07, at 22:55, Roald Baudoux wrote:

> Do you mean the delay could be reduced to zero if it is "not
> required"?

Exactly (see patch bellow).

> This is the first time I hear about this possibility. How do you do
> do that?

it’s my little finger :) Actually, Ben Thigpen said me that once so…

ej

#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P user com 398 512 165 196617 28;
#K set 0 -23264 12576 25185 29216 28005 24942 29472 26996 10099 8307
31086 25357 -23264 29815 28448 25185 29299 8301 25953 28275 8308
26725 29285 10099 8289 8292 25964 24953;
#K end;
#P window setfont "Sans Serif" 18.;
#P window linecount 1;
#P comment 331 457 38 196626 (4);
#P comment 212 30 38 196626 (3);
#P comment 24 82 38 196626 (2);
#P window setfont "Sans Serif" 9.;
#P newex 260 92 33 196617 s rec;
#B color 6;
#P newex 30 429 33 196617 r rec;
#B color 6;
#P user ubumenu 62 88 100 196617 0 1 1 0;
#X add (Choice);
#X add direct;
#X add with 1 vs;
#X prefix_set 0 0 0;
#P newex 194 128 53 196617 tapin~ 10;
#P newex 194 101 37 196617 click~;
#P newex 209 206 48 196617 loadbang;
#B color 4;
#P message 209 232 65 196617 0 1 1 , 1 0 1;
#P user matrixctrl 209 255 35 35 MatrixDefaultCell.pct
MatrixDefaultBkgnd.pct 35 35 16 16 2 2 16 16 1 1 48 2 5120 0;
#P newex 62 385 71 196617 selector~ 2 1;
#P newex 194 324 65 196617 matrix~ 2 2;
#P newex 249 295 77 196617 receive~ delay;
#B color 6;
#P newex 221 355 63 196617 send~ delay;
#B color 6;
#P user ezdac~ 480 321 524 354 0;
#P button 194 34 15 0;
#P newex 194 68 76 196617 t b 1;
#P newex 92 264 87 196617 receive~ nodelay;
#B color 6;
#P newex 93 225 73 196617 send~ nodelay;
#B color 6;
#P newex 464 272 80 196617 buffer~ toto 50;
#P newex 62 464 67 196617 record~ toto;
#P newex 194 149 59 196617 tapout~ 10;
#P newex 372 412 89 196617 loadmess set toto;
#B color 4;
#P user waveform~ 372 432 200 74 3 9;
#W mode move;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P window setfont "Sans Serif" 18.;
#P comment 442 325 38 196626 (1);
#P window setfont "Sans Serif" 9.;
#P comment 257 140 122 196617 just for the visualisation;
#P connect 21 0 15 0;
#P fasten 4 0 5 0 199 178 349 178 349 411;
#P connect 22 0 5 0;
#P connect 15 0 5 0;
#P connect 8 0 15 1;
#P connect 4 0 7 0;
#P connect 14 0 15 2;
#P connect 10 0 9 0;
#P connect 9 0 19 0;
#P connect 19 0 20 0;
#P connect 20 0 4 0;
#P connect 4 0 14 0;
#P connect 16 0 14 0;
#P connect 18 0 17 0;
#P connect 17 0 16 0;
#P connect 14 1 12 0;
#P connect 13 0 14 1;
#P connect 9 1 23 0;
#P connect 3 0 2 0;
#P window clipboard copycount 28;


June 7, 2007 | 8:26 am

ed guild schrieb:
> I’ve since done a search and replace on all my improperly patched
> send objects for the send~ object.

It was properly patched, by the way, but beside the already mentioned
differences between send/send~ there is another one not mentioned yet.

A send without tilde is exactly the same as a patch cord, with one
difference, the DSP chain won’t know that a rebuilt is necessary, that
means if audio is on, and you create some s/r connections, they won’t
work until you switch audio off/on. This means also it won’t work with
scripting on the fly…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


June 7, 2007 | 1:47 pm

As a follow up, I changed all my sends that passed audio signals to send~

we used the drum sampler in the studio last night and it sounds much better… the drums are a bit "crisper" or smoother sounding, more realistic, and the drummer said the drums felt much more responsive (he triggers the sampler thru a Roland TD-20… and the reverb fxsend (that is routed via a send~) now has much better response and more detail.

so it definitely made a difference replacing sends with send~ for routing the audio.

thanks to all for helping me understand the difference in send vs send~

cheers,


June 8, 2007 | 8:18 am

ed guild schrieb:
> so it definitely made a difference replacing sends with send~ for
> routing the audio.
>
> thanks to all for helping me understand the difference in send vs
> send~

There is no difference in sound quality though. A digital signal is just
a bunch of 0s and 1s, the stay the same no matter if you send them
through s/r or send~/receive~. Or you changed somthing else as well,
maybe you had a feedback loop in your patch which would silently mute
the offending part…
Or its psychology, the most underestimated aspect of sound quality… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


June 8, 2007 | 8:41 am

Hi,

I think that IF the send~ introduces a signal vector of delat there
*could be* some phase difference in the audio generated.

All the best

Alessandro Fogar

> There is no difference in sound quality though. A digital signal is just
> a bunch of 0s and 1s, the stay the same no matter if you send them
> through s/r or send~/receive~. Or you changed somthing else as well,
> maybe you had a feedback loop in your patch which would silently mute
> the offending part…
> Or its psychology, the most underestimated aspect of sound quality… ;-)


June 8, 2007 | 2:07 pm


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