Forums > MaxMSP

forwarding signals

October 3, 2007 | 6:53 pm

Hello,

I would like to know if there’s a way to use signals with [forward], enabling to set the destination in realtime (more or less like the Pure Data [throw~] and [catch~] system). Apparently it doesn’t work but who knows ?

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 64 48 108 196617 1. Turn DSP on;
#P user ezdac~ 64 72 108 105 0;
#P comment 64 162 121 196617 2. Change these numbers;
#P user number~ 146 180 185 195 9 3 3 1 0. 0. 0 34. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 146 340 69 196617 forward fred;
#B color 5;
#P message 175 298 48 196617 send bob;
#P message 167 274 52 196617 send fred;
#P user number~ 64 180 103 195 9 3 3 1 0. 0. 0 106. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 327 234 366 249 9 3 3 2 0. 0. 0 70. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 281 233 320 248 9 3 3 2 0. 0. 0 30. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 64 340 65 196617 forward bob;
#B color 5;
#P newex 281 180 37 196617 r bob;
#P newex 327 180 41 196617 r fred;
#P comment 281 162 124 196617 3. Watch the output here;
#P message 83 298 48 196617 send bob;
#P message 75 274 52 196617 send fred;
#P comment 236 297 153 196617 4. Try to change the destination;
#P fasten 9 0 6 0 69 197;
#P connect 10 0 12 0;
#P connect 11 0 12 0;
#P connect 13 0 12 0;
#P connect 1 0 6 0;
#P connect 2 0 6 0;
#P connect 4 0 8 0;
#P connect 5 0 7 0;
#P window clipboard copycount 17;


October 3, 2007 | 7:05 pm

On 3 oct. 07, at 20:53, julienbreval wrote:

> Hello,
>
> I would like to know if there’s a way to use signals with
> [forward], enabling to set the destination in realtime (more or
> less like the Pure Data [throw~] and [catch~] system). Apparently
> it doesn’t work but who knows ?

You mean something like send~/receive~?

ej

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 64 48 108 196617 1. Turn DSP on;
#P user ezdac~ 64 72 108 105 0;
#P comment 64 162 121 196617 2. Change these numbers;
#P user number~ 146 180 185 195 9 3 3 1 0. 0. 0 34. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 146 340 69 196617 send~ fred;
#B color 5;
#P message 175 298 42 196617 set bob;
#P message 167 274 46 196617 set fred;
#P user number~ 64 180 103 195 9 3 3 1 0. 0. 0 106. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 372 234 411 249 9 3 3 2 0. 0. 0 70. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 281 233 320 248 9 3 3 2 0. 0. 0 30. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 64 340 65 196617 send~ bobo;
#B color 5;
#P newex 281 180 68 196617 receive~ bob;
#P newex 372 180 72 196617 receive~ fred;
#P comment 281 162 124 196617 3. Watch the output here;
#P message 83 298 42 196617 set bob;
#P message 75 274 46 196617 set fred;
#P comment 236 297 153 196617 4. Try to change the destination;
#P connect 13 0 12 0;
#P connect 11 0 12 0;
#P connect 10 0 12 0;
#P connect 4 0 8 0;
#P connect 5 0 7 0;
#P fasten 9 0 6 0 69 197;
#P connect 1 0 6 0;
#P connect 2 0 6 0;
#P window clipboard copycount 17;


October 3, 2007 | 7:12 pm

>
> I would like to know if there’s a way to use signals with [forward],
> enabling to set the destination in realtime (more or less like the Pure Data
> [throw~] and [catch~] system). Apparently it doesn’t work but who knows ?

It is working fine with send~ / receive~ ;)


October 3, 2007 | 8:32 pm

No, because [send~] / [receive~] adds a delay of one audio block : eg if you are working at 44100 Hz with a latency of 256 samples, you get a delay of about 6 msec between the send and the receive of the audio signal.

If you don’t need to be careful about timing (and CPU resources), then, that’s right [receive~] can receive a "set" message …
But why not using [send] and [receive] as it works also for signals ?


October 3, 2007 | 9:52 pm

On 3 oct. 07, at 22:32, julienbreval wrote:

> No, because [send~] / [receive~] adds a delay of one audio block :
> eg if you are working at 44100 Hz with a latency of 256 samples,
> you get a delay of about 6 msec between the send and the receive of
> the audio signal.

That’s not true. [send~]/[receive~] will add a vector delay only if
it’s required (when you do some feedback loop for example):

http://www.cycling74.com/forums/index.php?
t=msg&goto=107058&rid=0&S=41abc7d6fe311358a6cc4fa3c3af8131&srch=send%
7E+delay#msg_107058

> If you don’t need to be careful about timing (and CPU resources),
> then, that’s right [receive~] can receive a "set" message …
> But why not using [send] and [receive] as it works also for signals ?

because it requires to restart the dsp chain in order to rebuild the
correct signal path.

ej


October 3, 2007 | 9:55 pm

On 03 Oct 2007, at 22:32, julienbreval wrote:

>
> No, because [send~] / [receive~] adds a delay of one audio block :
> eg if you are working at 44100 Hz with a latency of 256 samples,
> you get a delay of about 6 msec between the send and the receive of
> the audio signal.

this is only true if you use send~/receive~ in a feedback loop.
otherwise it would render these objects useless.

#P window setfont "Sans Serif" 9.;
#P user number~ 157 192 215 207 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user ezdac~ 80 225 124 258 0;
#P window linecount 1;
#P newex 95 153 40 196617 -~;
#P newex 125 121 66 196617 receive~ bla;
#P newex 126 84 52 196617 send~ bla;
#P newex 95 55 39 196617 noise~;
#P connect 0 0 3 0;
#P connect 0 0 1 0;
#P connect 3 0 4 0;
#P connect 3 0 4 1;
#P connect 3 0 5 0;
#P connect 2 0 3 1;
#P window clipboard copycount 6;

> But why not using [send] and [receive] as it works also for signals ?

because you can’t use the set message to change the destination…

vb


October 3, 2007 | 10:31 pm

I slightly different direction…

I am making synthesizers in MSP each of which has its own local quad panner
to deliver 4 channels of direct signal and 4 channels scaled for location
and distance to be processed through a common reverb. I have been using
bunches of send~ and receive~ objects but it occurred to me today that with
an aggregate audio device I can use SoundFlower as a buss system. Sending
my signals from all of my synths to 8 channels of SoundFlower via dac~ and
then picking them up at the final output with adc~ makes for very clean
programming. This works fine but are there any caveats to doing things this
way?

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


October 4, 2007 | 2:33 pm

Quote: Gary Lee Nelson wrote on Wed, 03 October 2007 16:31
—————————————————-
> I slightly different direction…
>
> I am making synthesizers in MSP each of which has its own local quad panner
> to deliver 4 channels of direct signal and 4 channels scaled for location
> and distance to be processed through a common reverb. I have been using
> bunches of send~ and receive~ objects but it occurred to me today that with
> an aggregate audio device I can use SoundFlower as a buss system. Sending
> my signals from all of my synths to 8 channels of SoundFlower via dac~ and
> then picking them up at the final output with adc~ makes for very clean
> programming. This works fine but are there any caveats to doing things this
> way?

yes – situations where you want to use I/Os on the form of dac~ and adc~ also for other things beside soundflower or where you want to share your patch.

i am not sure where a soundlfower could be better or easier to program than using dac~, but i agree it works well.


October 4, 2007 | 4:00 pm

Here’s a tutorial patch to show what I am doing. In this scheme adc~ and
dac~ are used as arrays of send/receive ports.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 175 163 122 196617 < - to soundflower 9-16;
#P newex 15 160 151 196617 dac~ 31 32 33 34 35 36 37 38;
#N vpatcher 26 74 626 474;
#P outlet 328 307 15 0;
#P outlet 291 307 15 0;
#P outlet 254 307 15 0;
#P outlet 217 307 15 0;
#P outlet 180 307 15 0;
#P outlet 143 307 15 0;
#P outlet 106 307 15 0;
#P outlet 69 307 15 0;
#P pop;
#P newobj 15 136 151 196617 p SynthBWithQuadPanning;
#P comment 173 138 139 196617 < - another dummy patcher;
#N vpatcher 20 74 620 474;
#P outlet 117 291 15 0;
#P outlet 103 273 15 0;
#P outlet 89 255 15 0;
#P outlet 75 237 15 0;
#P inlet 126 175 15 0;
#P inlet 112 157 15 0;
#P inlet 98 139 15 0;
#P inlet 84 121 15 0;
#P pop;
#P newobj 110 214 82 196617 p AQuadReverb;
#P newex 15 110 151 196617 dac~ 31 32 33 34 35 36 37 38;
#N vpatcher 26 74 626 474;
#P outlet 328 307 15 0;
#P outlet 291 307 15 0;
#P outlet 254 307 15 0;
#P outlet 217 307 15 0;
#P outlet 180 307 15 0;
#P outlet 143 307 15 0;
#P outlet 106 307 15 0;
#P outlet 69 307 15 0;
#P pop;
#P newobj 15 86 156 196617 p SynthAWithQuadPanning;
#P newex 14 255 83 196617 dac~ 1 2 3 4;
#P newex 14 189 179 196617 adc~ 31 32 33 34 35 36 37 38;
#P comment 200 191 138 196617 < - from soundflower 9-16;
#P comment 101 258 164 196617 < - to MOTU828 and outside world;
#P comment 177 88 121 196617 < - just a dummy patcher;
#P comment 15 49 146 196617 MOTU 828 on channels 1-22;
#P comment 15 64 164 196617 SoundFlower on channels 23-38;
#P window setfont "Sans Serif" 12.;
#P comment 15 29 126 196620 Aggregate Device;
#P window setfont "Sans Serif" 9.;
#P comment 201 216 143 196617 < - shared reverb (dummy);
#P comment 178 110 122 196617 < - to soundflower 9-16;
#P window setfont "Sans Serif" 18.;
#P window linecount 3;
#P comment 364 34 238 196626 SoundFlower used as an alternative to many
send~/receive~ objects;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 365 111 161 196617 Gary Lee Nelson , Oberlin College;
#P window linecount 5;
#P comment 365 128 237 196617 My quad panner accepts location and distance
parameters for a mono signal that is panned into four channels of direct and
four channels to be reverberated. It is a descendant of spat4 and uses the
Chowning algorithm for local and global reverb;
#P connect 15 0 12 0;
#P connect 11 0 12 0;
#P connect 13 0 14 0;
#P connect 17 0 18 0;
#P connect 13 1 14 1;
#P connect 17 1 18 1;
#P connect 15 1 12 1;
#P connect 11 1 12 1;
#P connect 13 2 14 2;
#P connect 17 2 18 2;
#P connect 15 2 12 2;
#P connect 11 2 12 2;
#P connect 13 3 14 3;
#P connect 17 3 18 3;
#P connect 15 3 12 3;
#P connect 11 3 12 3;
#P connect 13 4 14 4;
#P connect 17 4 18 4;
#P connect 11 4 15 0;
#P connect 13 5 14 5;
#P connect 17 5 18 5;
#P connect 11 5 15 1;
#P connect 13 6 14 6;
#P connect 17 6 18 6;
#P connect 13 7 14 7;
#P connect 17 7 18 7;
#P connect 11 6 15 2;
#P connect 11 7 15 3;
#P window clipboard copycount 20;

On 10/4/07 10:33 AM, "Roman Thilenius" wrote:

>
> Quote: Gary Lee Nelson wrote on Wed, 03 October 2007 16:31
> —————————————————-
>> I slightly different direction…
>>
>> I am making synthesizers in MSP each of which has its own local quad panner
>> to deliver 4 channels of direct signal and 4 channels scaled for location
>> and distance to be processed through a common reverb. I have been using
>> bunches of send~ and receive~ objects but it occurred to me today that with
>> an aggregate audio device I can use SoundFlower as a buss system. Sending
>> my signals from all of my synths to 8 channels of SoundFlower via dac~ and
>> then picking them up at the final output with adc~ makes for very clean
>> programming. This works fine but are there any caveats to doing things this
>> way?
>
>
> yes – situations where you want to use I/Os on the form of dac~ and adc~ also
> for other things beside soundflower or where you want to share your patch.
>
> i am not sure where a soundlfower could be better or easier to program than
> using dac~, but i agree it works well.
>
>
>
>

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


October 5, 2007 | 9:21 am

Hello,

Thanks everybody for the clarification about vector delay.

Quote: Emmanuel Jourdan wrote on Wed, 03 October 2007 23:52
—————————————————-
> > But why not using [send] and [receive] as it works also for signals ?
>
> because it requires to restart the dsp chain in order to rebuild the
> correct signal path.
—————————————————-

In the case of a static signal routing, can [send] and [receive] still be used (as they save some CPU resources) ?
Sorry I don’t understand clearly this DSP restarting thing (or does this just mean : "you can’t use [send] and [receive] for dynamic routing as it would otherwise need to restart the DSP chain" ?)

Best,
-j


October 5, 2007 | 11:04 am

On 5 oct. 07, at 11:21, julienbreval wrote:

> In the case of a static signal routing, can [send] and [receive]
> still be used (as they save some CPU resources) ?
> Sorry I don’t understand clearly this DSP restarting thing (or does
> this just mean : "you can’t use [send] and [receive] for dynamic
> routing as it would otherwise need to restart the DSP chain" ?)

exactly. You can use send/receive when the routing is not dynamic, it
just acts like a normal connection.

ej


October 5, 2007 | 11:34 am

okay, thank you very much



jln
October 5, 2007 | 11:57 am


October 5, 2007 | 12:51 pm

On 5 oct. 07, at 13:57, jln wrote:

> Do they really save CPU ? Ot if so, does it really matter – unless
> you use a huge number of s/r in your patch ?
>
> I’m sorry, I think it has been discussed in the past but can’t
> remember the verdict…

send~/receive~ have a slightly overhead because of the additional
features.

ej


October 6, 2007 | 8:54 am

You may also try this :

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 442 95 65 196617 s AudioBus2;
#B color 6;
#P newex 442 74 140 196617 funnel 4;
#P user number~ 571 52 610 67 9 3 3 1 0. 0. 0 0.4 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 528 52 567 67 9 3 3 1 0. 0. 0 0.3 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 485 52 524 67 9 3 3 1 0. 0. 0 0.2 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 442 52 481 67 9 3 3 1 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 355 128 65 196617 r AudioBus2;
#B color 6;
#P newex 270 95 65 196617 s AudioBus2;
#B color 6;
#P user number~ 484 173 523 188 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 441 173 480 188 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 398 173 437 188 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 355 173 394 188 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 355 149 182 196617 route 0 1 2 3;
#P newex 270 74 140 196617 funnel 4;
#P user number~ 399 52 438 67 9 3 3 1 0. 0. 0 0.4 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 356 52 395 67 9 3 3 1 0. 0. 0 0.3 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 313 52 352 67 9 3 3 1 0. 0. 0 0.2 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 270 52 309 67 9 3 3 1 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P comment 316 32 212 196617 (implicite addition);
#P comment 104 121 69 196617 parse signals;
#P newex 36 120 65 196617 r AudioBus1;
#B color 14;
#P newex 36 87 65 196617 s AudioBus1;
#B color 14;
#P user number~ 165 165 204 180 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 122 165 161 180 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 79 165 118 180 9 3 3 2 0. 0. 0 3. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 36 165 75 180 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 36 141 182 196617 route 0 1 2 3;
#P newex 36 66 140 196617 funnel 4;
#P user number~ 165 44 204 59 9 3 3 1 0. 0. 0 0.54 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 122 44 161 59 9 3 3 1 0. 0. 0 0.33 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 79 44 118 59 9 3 3 1 0. 0. 0 0.38 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 36 44 75 59 9 3 3 1 0. 0. 0 0.76 250 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P comment 46 26 124 196617 tag a signal with an index;
#P comment 102 89 77 196617 use a single bus;
#P comment 170 387 76 196617 parse message;
#P newex 98 340 65 196617 s AudioBus3;
#B color 5;
#P newex 98 386 65 196617 r AudioBus3;
#B color 5;
#P newex 275 445 68 196617 loadmess set;
#P message 257 489 89 196617 with float 0.;
#P newex 257 467 62 196617 prepend set;
#P user number~ 216 451 255 466 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 216 429 51 196617 zl slice 1;
#P user number~ 157 431 196 446 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 98 431 137 446 9 3 3 2 0. 0. 0 0.1 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 98 407 187 196617 route iamsignal1 iamsignal2 iamsignal3;
#P comment 161 233 133 196617 tag a signal with a message;
#P button 273 289 15 0;
#P newex 255 322 175 196617 sprintf iamsignal3 %s with float %f;
#P user number~ 255 257 296 272 9 3 3 1 0. 0. 0 0.99 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 116 304 96 196617 prepend iamsignal2;
#P user number~ 116 280 155 295 9 3 3 1 0. 0. 0 0.66 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 98 254 96 196617 prepend iamsignal1;
#P user number~ 98 230 137 245 9 3 3 1 0. 0. 0 0.33 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user ezdac~ 495 289 539 322 0;
#P flonum 420 273 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 23 0 27 0;
#P connect 27 0 33 0;
#P connect 34 0 28 0;
#P connect 28 0 29 0;
#P connect 24 0 27 1;
#P connect 28 1 30 0;
#P connect 25 0 27 2;
#P connect 28 2 31 0;
#P connect 26 0 27 3;
#P connect 28 3 32 0;
#P connect 0 0 8 0;
#P connect 0 0 7 1;
#P connect 17 0 16 0;
#P connect 15 0 16 0;
#P connect 13 1 15 0;
#P connect 8 0 7 0;
#P connect 6 0 7 0;
#P connect 13 0 14 0;
#P connect 10 2 13 0;
#P connect 10 1 12 0;
#P connect 4 0 5 0;
#P connect 10 0 11 0;
#P connect 18 0 10 0;
#P connect 3 0 19 0;
#P connect 5 0 19 0;
#P connect 7 0 19 0;
#P connect 2 0 3 0;
#P connect 37 0 41 0;
#P connect 41 0 47 0;
#P connect 38 0 41 1;
#P connect 48 0 42 0;
#P connect 42 0 43 0;
#P connect 39 0 41 2;
#P connect 42 1 44 0;
#P connect 40 0 41 3;
#P connect 42 2 45 0;
#P connect 49 0 53 0;
#P connect 53 0 54 0;
#P connect 42 3 46 0;
#P connect 50 0 53 1;
#P connect 51 0 53 2;
#P connect 52 0 53 3;
#P window clipboard copycount 55;


October 6, 2007 | 10:18 am

Interesting

I think I have currently never used [funnel] in any patch :)


October 6, 2007 | 2:33 pm

One little remark:

When using [send] / [receive] for signals, if the [send] is in a [poly~] subpatcher and the [receive] in an abstraction, the signal is not transmitted. One solution is to use the outlets of the [poly~] subpatcher for connecting the [send] "outside" the [poly~] …


October 7, 2007 | 4:47 am

My recollection is that send~/receive~ are buffered whereas
send/receive are not; consequently the use of send/receive has the
potentiality for more flakiness. (though this recollection may be a
case of same as it never was, so if anyone has more insight…) My
policy has always been to use inlets and outlets as much as possible
and only to use send~/receive~ where absolutely necessary, and this
saves CPU. Oftentimes the use of poly~ can achieve the same effect.

For me I’d much rather have a patch running at 80% with very little
control-rate than a patch running at 60% but with a massive amount of
control-rate events, simply for the reason that I know the audio-rate
stuff won’t spike, though YMMV.

Peter McCulloch


October 12, 2007 | 9:57 pm

Peter McCulloch schrieb:
> For me I’d much rather have a patch running at 80% with very little
> control-rate than a patch running at 60% but with a massive amount of
> control-rate events, simply for the reason that I know the audio-rate
> stuff won’t spike, though YMMV.

If you connect audio with send/receive you don’t add any control-rate
event, absolutely zero. It is only used in the moment audio is switched
on, to build the dsp chain. After that it stays as it is, that’s why
dynamic change of forward/receive doesn’t work for audio, and that’s why
it doesn’t work into, or out of a poly~. The poly has it’s own dsp chain
independent of the main dsp chain…

Stefan


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


October 12, 2007 | 9:58 pm

Gary Lee Nelson schrieb:
> Sending my signals from all of my synths to 8 channels of SoundFlower
> via dac~ and then picking them up at the final output with adc~ makes
> for very clean programming. This works fine but are there any
> caveats to doing things this way?

I bet you get either a signal vector of delay or probably more likely an
i/o vector of delay…
There is nothing wrong with send~/receive~, or if you can garanty that
there is no feedback, use send/receive…
It would not hurt your design philosophy if you use the suggestion with
funnel/send/receive. I also have sends/receives abstractions which would
allow you to send multiple audio channels with a (virtually) single name
in my abhaXions…

Stefan


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


October 13, 2007 | 1:23 am

On 10/12/07 5:58 PM, "Stefan Tiedje" wrote:

> Gary Lee Nelson schrieb:
>> Sending my signals from all of my synths to 8 channels of SoundFlower
>> via dac~ and then picking them up at the final output with adc~ makes
>> for very clean programming. This works fine but are there any
>> caveats to doing things this way?
>
> I bet you get either a signal vector of delay or probably more likely an
> i/o vector of delay…
> There is nothing wrong with send~/receive~, or if you can garanty that
> there is no feedback, use send/receive…
> It would not hurt your design philosophy if you use the suggestion with
> funnel/send/receive. I also have sends/receives abstractions which would
> allow you to send multiple audio channels with a (virtually) single name
> in my abhaXions…
>
> Stefan

Just did a benchmark. Stefan is correct. There is a delay but I can’t tell
whether it is signal or I/O vector.

I tried using small values for both vectors in the extreme case where the
"notes" are very short cycle~ 1000 with line~ at 1,0 100 or click~. My test
patch is below.

With vectors 64 and below I hear very little delay. At 128 the delay is
just noticeable. At 48K these delays are 2-4 ms. What are the ramifications
of using vectors as small as 64?

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 224 306 31 196617 set 1;
#P message 182 285 139 196617 set 0.25 0.5 0.75 1 0.67 0.3;
#P newex 282 509 46 196617 dac~ 23;
#P toggle 281 379 15 0;
#P newex 282 401 58 196617 metro 500;
#P newex 282 435 37 196617 click~;
#P newex 282 471 55 196617 *~ 0.25;
#P toggle 326 334 15 0;
#P newex 123 505 49 196617 dac~ 1 2;
#P toggle 122 375 15 0;
#P newex 123 397 58 196617 metro 500;
#P newex 123 431 37 196617 click~;
#P newex 123 467 41 196617 *~ 0.25;
#P user ezdac~ 51 377 95 410 0;
#P newex 283 532 46 196617 adc~ 23;
#P newex 283 566 49 196617 dac~ 1 2;
#P window linecount 2;
#P comment 349 518 100 196617 chznnel 23 is first in soundflower;
#P connect 9 0 7 0;
#P connect 7 0 6 0;
#P connect 16 0 5 0;
#P connect 15 0 5 0;
#P connect 6 0 5 0;
#P connect 5 0 4 0;
#P connect 4 0 8 0;
#P connect 4 0 8 1;
#P connect 9 0 13 0;
#P connect 13 0 12 0;
#P connect 16 0 11 0;
#P connect 15 0 11 0;
#P connect 12 0 11 0;
#P connect 11 0 10 0;
#P connect 10 0 14 0;
#P connect 2 0 1 0;
#P connect 2 0 1 1;
#P window clipboard copycount 17;
Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


October 18, 2007 | 2:46 pm


November 17, 2007 | 12:44 pm

Hi,

is there any way of making send~ and receive~ local to a patch? I am not on mac, so i cant use poke~.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 38 37 33 9109513 action;
#P button 137 65 15 0;
#P user number~ 143 339 234 354 9 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 144 286 63 9109513 receive~ test;
#B color 6;
#P newex 144 265 52 9109513 send~ test;
#B color 6;
#P newex 144 214 73 9109513 count~ 1 16 1 1;
#P toggle 192 70 15 0;
#P message 192 90 65 9109513 autoreset $1;
#P window linecount 2;
#P newex 177 153 40 9109513 adstatus sigvs;
#P user ezdac~ 429 160 473 193 0;
#P window linecount 1;
#P newex 207 187 27 9109513 + 1;
#P newex 241 187 29 9109513 +~ 0.;
#P newex 241 214 108 9109513 >=~ 44100;
#P number 339 89 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 241 263 27 9109513 t b b;
#P button 241 368 15 0;
#P newex 241 240 33 9109513 edge~;
#P newex 144 240 28 9109513 sah~;
#P newex 153 112 103 9109513 count~ 1 99999999 1 1;
#P comment 279 71 133 9109513 metro rate in samples;
#P fasten 19 0 18 0 153 72;
#P connect 16 0 17 0;
#P fasten 16 0 8 1 149 315 363 315 363 156 265 156;
#P connect 8 0 7 0;
#P fasten 1 0 8 0 158 140 246 140;
#P fasten 7 0 2 1 246 235 167 235;
#P connect 7 0 3 0;
#P connect 14 0 2 0;
#P connect 2 0 15 0;
#P connect 5 0 4 0;
#P connect 18 0 1 0;
#P connect 12 0 1 1;
#P fasten 5 1 1 0 263 293 420 293 420 36 159 36 159 116;
#P lcolor 6;
#P connect 9 0 14 1;
#P connect 11 1 9 0;
#P connect 13 0 12 0;
#P connect 3 0 5 0;
#P connect 6 0 7 1;
#P window clipboard copycount 20;



jln
November 17, 2007 | 1:35 pm


November 17, 2007 | 3:06 pm

Hi,

Poke~ is Windows only, maxobjects.com has wrong information.

I hope I get understand your idea correctly:

#P window setfont "Sans Serif" 9.;
#P user number~ 142 117 181 132 9 139 3 2 0. 0. 0 -174. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 187 115 226 130 9 139 3 2 0. 0. 0 -174. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#N vpatcher 25 70 625 470;
#P outlet 102 186 15 0;
#P window setfont "Sans Serif" 9.;
#P user number~ 50 167 89 182 9 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 50 142 76 9109513 receive~ $0.test;
#P connect 0 0 1 0;
#P connect 0 0 2 0;
#P pop;
#P newobj 187 90 26 9109513 p p1;
#P user ezdac~ 261 87 305 120 0;
#N vpatcher 25 70 625 470;
#P outlet 102 186 15 0;
#P window setfont "Sans Serif" 9.;
#P user number~ 50 167 89 182 9 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 50 142 76 9109513 receive~ $0.test;
#P newex 50 50 43 9109513 sig~ 354;
#P newex 50 113 65 9109513 send~ $0.test;
#P connect 1 0 0 0;
#P connect 2 0 3 0;
#P connect 2 0 4 0;
#P pop;
#P newobj 143 90 26 9109513 p p1;
#P connect 0 0 4 0;
#P connect 2 0 3 0;
#P window clipboard copycount 5;

Thank You



jln
November 17, 2007 | 3:46 pm

Quote: itchy wrote on Sat, 17 November 2007 16:06
—————————————————-
> Hi,
>
> Poke~ is Windows only, maxobjects.com has wrong information.

Are we talking about the same poke~ object ? It is part of the standard Max objects and works fine on both Mac and PC as far as I know.

http://www.maxobjects.com/?v=objects&id_objet=318&requested=poke&operateur=AND&id_plateforme=0

> I hope I get understand your idea correctly:

Sorry for my lack of precisions. The ‘#0.test’ will only work for patchs saved as abstractions. The attached patch should make sense. Check the chapter "Arguments: $ and #, Changeable Arguments to Objects" in the Max Topic manual for more info, if needed.

Best,
Julien.


November 17, 2007 | 3:57 pm

Hi,
You mean through arguments. I get it now. I thought it would be possible somehow without having to give arguments to a patch. I only have 16 of these bangers so I guess there wont be too much typing:) In other cases an input to script these sends/receives would work as well.

Thanks

..oh, sorry I meant pause~


November 17, 2007 | 4:04 pm

On 17 nov. 07, at 16:57, itchy wrote:

> Hi,
> You mean through arguments. I get it now. I thought it would be
> possible somehow without having to give arguments to a patch. I
> only have 16 of these bangers so I guess there wont be too much
> typing:) In other cases an input to script these sends/receives
> would work as well.

If you use #0 in an abstraction, the #0 will automatically be replace
by an unique number. So yo don’t have anything else to type. You may
have a look to the "$ and #, ChangeableArguments to Objects" chapter
from Max46Topics.pdf.

HTH,
ej


November 17, 2007 | 4:44 pm

Piece of cake then!:))


November 17, 2007 | 5:12 pm

On 17 nov. 07, at 17:44, itchy wrote:

> Piece of cake then!:))

Exactly ;-)

ej


November 19, 2007 | 7:19 pm

itchy schrieb:
> is there any way of making send~ and receive~ local to a patch? I am
> not on mac, so i cant use poke~.

The correct answer to your question has been given, but in your example
you might want to break the feedback loop instead of using
send~/receive~ taking a tapin~/tapout~. It will have the same effect and
doesn’t need any names…

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 38 37 33 196617 action;
#P button 137 65 15 0;
#P user number~ 143 339 234 354 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P newex 144 286 52 196617 tapout~;
#B color 6;
#P newex 144 265 52 196617 tapin~;
#B color 6;
#P newex 144 214 87 196617 count~ 1 16 1 1;
#P toggle 192 70 15 0;
#P message 192 90 65 196617 autoreset $1;
#P window linecount 2;
#P newex 177 153 40 196617 adstatus sigvs;
#P user ezdac~ 429 160 473 193 0;
#P window linecount 1;
#P newex 207 187 27 196617 + 1;
#P newex 241 187 29 196617 +~ 0.;
#P newex 241 214 108 196617 >=~ 44100;
#P number 339 89 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 241 263 27 196617 t b b;
#P button 241 368 15 0;
#P newex 241 240 33 196617 edge~;
#P newex 144 240 28 196617 sah~;
#P newex 153 112 122 196617 count~ 1 99999999 1 1;
#P comment 279 71 133 196617 metro rate in samples;
#P connect 16 0 17 0;
#P fasten 16 0 8 1 149 315 363 315 363 156 265 156;
#P connect 15 0 16 0;
#P connect 2 0 15 0;
#P connect 6 0 7 1;
#P connect 3 0 5 0;
#P connect 13 0 12 0;
#P connect 11 1 9 0;
#P connect 9 0 14 1;
#P fasten 5 1 1 0 263 293 420 293 420 36 159 36 159 116;
#P lcolor 6;
#P connect 12 0 1 1;
#P connect 18 0 1 0;
#P connect 5 0 4 0;
#P connect 14 0 2 0;
#P connect 7 0 3 0;
#P fasten 7 0 2 1 246 235 167 235;
#P fasten 1 0 8 0 158 140 246 140;
#P connect 8 0 7 0;
#P fasten 19 0 18 0 153 72;
#P window clipboard copycount 20;


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


November 26, 2007 | 11:47 am

Hi,

and thank you all for the input. The outcome is a "proper.phasor" that outputs:

signal: 0.-1. according to Master bpm, bpm multiplier and time signature

bang: at the end of a bar

float: 0.-1. according to Master bpm, bpm multiplier and time signature

float: a value representing total movement within a signal vector

(…it needs to be saved as an patch and loaded up as an object to work in multiple instances)

——————————————————————-

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 245 74 34 9109513 abs 0.;
#P newex 690 125 46 9109513 change 0;
#P newex 690 105 70 9109513 adstatus sigvs;
#P newex 626 218 33 9109513 edge~;
#P newex 690 149 27 9109513 + 1;
#P newex 626 192 102 9109513 ==~ 32;
#P newex 626 170 73 9109513 count~ 1 33 1 1;
#P window linecount 2;
#P comment 680 222 100 9109513 banger to create max data;
#B color 1;
#P window linecount 1;
#P comment 363 393 39 9109513 bar end;
#B color 1;
#P comment 416 393 44 9109513 progress;
#B color 1;
#P window linecount 2;
#P comment 491 394 148 9109513 progress delta (per signal vector*precision multiplier);
#B color 1;
#P window linecount 1;
#P newex 492 351 28 9109513 * 32.;
#N comlet progress delta (per signal vector);
#P outlet 492 376 15 0;
#P newex 492 257 67 9109513 snapshot~ 0 0;
#N comlet barend bang;
#P outlet 367 375 15 0;
#P newex 367 351 33 9109513 edge~;
#P outlet 414 376 15 0;
#P newex 414 351 67 9109513 snapshot~ 0 0;
#P newex 10 24 45 9109513 loadbang;
#P message 10 151 18 9109513 60;
#P newex 493 79 46 9109513 change 0;
#P button 10 49 91 0;
#P newex 294 360 31 9109513 *~ -1.;
#P newex 294 246 27 9109513 -~;
#P newex 294 404 65 9109513 receive~ $0.d;
#B color 6;
#P newex 294 384 54 9109513 send~ $0.d;
#B color 6;
#P newex 294 340 28 9109513 *~ 0.;
#P newex 368 313 34 9109513 ==~ 1.;
#P newex 368 273 34 9109513 >=~ 1.;
#P newex 368 293 33 9109513 delta~;
#P newex 294 179 36 9109513 sig~ 1.;
#P newex 294 219 23 9109513 +=~;
#P newex 493 59 55 9109513 adstatus sr;
#P newex 378 59 52 9109513 unpack f f;
#P newex 420 80 57 9109513 prepend set;
#P flonum 277 96 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 410 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 372 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 333 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 294 133 103 9109513 pak 60. 1. 1. 1. 44100.;
#N comlet bpm multiplier;
#P inlet 336 40 15 0;
#P newex 294 155 167 9109513 expr (1/($f5-1))*($f1*$f2/60*($f3/$f4));
#N comlet time signature x y;
#P inlet 378 40 15 0;
#N comlet master bpm;
#P inlet 294 40 15 0;
#P user ezdac~ 12 182 56 215 0;
#P window linecount 2;
#P comment 453 112 128 9109513 bpm , bpm multiplier , time signature x/y , sampling rate;
#B color 1;
#P window linecount 5;
#P newex 503 277 17 9109513 adstatus sigvs;
#P connect 45 0 42 0;
#P connect 0 1 35 1;
#P connect 27 0 46 0;
#P connect 27 0 11 0;
#P connect 46 0 11 0;
#P connect 43 0 29 0;
#P connect 43 0 33 0;
#P connect 44 1 45 0;
#P connect 42 0 40 1;
#P connect 41 0 43 0;
#P connect 40 0 41 0;
#P connect 14 1 26 0;
#P connect 35 0 34 0;
#P connect 33 0 35 0;
#P connect 16 0 15 0;
#P connect 16 0 23 1;
#P fasten 16 0 33 0 299 210 497 210;
#P connect 13 1 12 0;
#P connect 29 0 30 0;
#P connect 15 0 23 0;
#P fasten 15 0 29 0 299 240 419 240;
#P connect 26 0 7 4;
#P connect 4 0 13 0;
#P connect 17 0 19 0;
#P connect 18 0 17 0;
#P connect 23 0 20 0;
#P fasten 23 0 18 0 299 268 373 268;
#P connect 31 0 32 0;
#P fasten 19 0 20 1 373 335 317 335;
#P connect 19 0 31 0;
#P connect 12 0 7 3;
#P connect 10 0 7 3;
#P connect 13 0 7 2;
#P connect 9 0 7 2;
#P connect 6 0 7 1;
#P connect 8 0 7 1;
#P connect 24 0 21 0;
#P connect 20 0 24 0;
#P fasten 22 0 15 0 299 429 276 429 276 213 299 213;
#P lcolor 6;
#P connect 25 0 27 0;
#P connect 25 0 15 0;
#P connect 5 0 16 0;
#P connect 7 0 5 0;
#P connect 3 0 7 0;
#P connect 11 0 7 0;
#P connect 28 0 25 0;
#P window clipboard copycount 47;


November 26, 2007 | 11:50 am

there was a mistake, the proper version here:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 245 74 34 9109513 abs 0.;
#P newex 718 106 46 9109513 change 0;
#B color 9;
#P newex 718 88 70 9109513 adstatus sigvs;
#B color 9;
#P newex 523 226 33 9109513 edge~;
#P newex 587 157 27 9109513 + 1;
#P newex 523 200 102 9109513 ==~ 32;
#P newex 523 178 73 9109513 count~ 1 33 1 1;
#P window linecount 2;
#P comment 615 159 100 9109513 banger to create max data;
#B color 1;
#P window linecount 1;
#P comment 363 393 39 9109513 bar end;
#B color 1;
#P comment 416 393 44 9109513 progress;
#B color 1;
#P window linecount 2;
#P comment 491 394 148 9109513 progress delta (per signal vector*precision multiplier);
#B color 1;
#P window linecount 1;
#P newex 492 351 28 9109513 * 32.;
#N comlet progress delta (per signal vector);
#P outlet 492 376 15 0;
#P newex 492 257 67 9109513 snapshot~ 0 0;
#N comlet barend bang;
#P outlet 367 375 15 0;
#P newex 367 351 33 9109513 edge~;
#P outlet 414 376 15 0;
#P newex 414 351 67 9109513 snapshot~ 0 0;
#P newex 10 24 45 9109513 loadbang;
#P message 10 151 18 9109513 60;
#P newex 493 79 46 9109513 change 0;
#P button 10 49 91 0;
#P newex 294 360 31 9109513 *~ -1.;
#P newex 294 246 27 9109513 -~;
#P newex 294 404 65 9109513 receive~ $0.d;
#B color 6;
#P newex 294 384 54 9109513 send~ $0.d;
#B color 6;
#P newex 294 340 28 9109513 *~ 0.;
#P newex 368 313 34 9109513 ==~ 1.;
#P newex 368 273 34 9109513 >=~ 1.;
#P newex 368 293 33 9109513 delta~;
#P newex 294 179 36 9109513 sig~ 1.;
#P newex 294 219 23 9109513 +=~;
#P newex 493 59 55 9109513 adstatus sr;
#P newex 378 59 52 9109513 unpack f f;
#P newex 420 80 57 9109513 prepend set;
#P flonum 277 96 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 410 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 372 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 333 102 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 294 133 103 9109513 pak 60. 1. 1. 1. 44100.;
#N comlet bpm multiplier;
#P inlet 336 40 15 0;
#P newex 294 155 167 9109513 expr (1/($f5-1))*($f1*$f2/60*($f3/$f4));
#N comlet time signature x y;
#P inlet 378 40 15 0;
#N comlet master bpm;
#P inlet 294 40 15 0;
#P user ezdac~ 12 182 56 215 0;
#P window linecount 2;
#P comment 453 112 128 9109513 bpm , bpm multiplier , time signature x/y , sampling rate;
#B color 1;
#P fasten 44 0 34 1 723 338 515 338;
#P lcolor 10;
#P fasten 44 0 41 0 723 152 592 152;
#P lcolor 10;
#P fasten 44 0 40 1 723 190 620 190;
#P lcolor 10;
#P connect 26 0 45 0;
#P connect 26 0 10 0;
#P connect 45 0 10 0;
#P connect 42 0 28 0;
#P connect 42 0 32 0;
#P connect 43 1 44 0;
#P lcolor 10;
#P connect 41 0 39 1;
#P connect 40 0 42 0;
#P connect 39 0 40 0;
#P connect 13 1 25 0;
#P connect 34 0 33 0;
#P connect 32 0 34 0;
#P connect 15 0 14 0;
#P connect 15 0 22 1;
#P fasten 15 0 32 0 299 210 497 210;
#P connect 12 1 11 0;
#P connect 28 0 29 0;
#P connect 14 0 22 0;
#P fasten 14 0 28 0 299 240 419 240;
#P connect 25 0 6 4;
#P connect 3 0 12 0;
#P connect 16 0 18 0;
#P connect 17 0 16 0;
#P connect 22 0 19 0;
#P fasten 22 0 17 0 299 268 373 268;
#P connect 30 0 31 0;
#P fasten 18 0 19 1 373 335 317 335;
#P connect 18 0 30 0;
#P connect 11 0 6 3;
#P connect 9 0 6 3;
#P connect 12 0 6 2;
#P connect 8 0 6 2;
#P connect 5 0 6 1;
#P connect 7 0 6 1;
#P connect 23 0 20 0;
#P connect 19 0 23 0;
#P fasten 21 0 14 0 299 429 276 429 276 213 299 213;
#P lcolor 6;
#P connect 24 0 26 0;
#P connect 24 0 14 0;
#P connect 4 0 15 0;
#P connect 6 0 4 0;
#P connect 2 0 6 0;
#P connect 10 0 6 0;
#P connect 27 0 24 0;
#P window clipboard copycount 46;


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