Rodrigo

So I'm trying to build a patch to recreate a "no-input mixer" type

setup using tapin/tapout with some feedback loops.

It's working OK so far(this is the seedling of the patch), but it

seems that after running the patch for a bit, or if signals get to

hot, max crashes, not in the program crashing sense, or stack overflow

sense, the audio just stops working, and i have to restart the program

When conntect disconnect cables, or start/stop dac~ after the crash it

I searched the mailing list archive but I didn't find anything related

I also found that I needed to 'inject' a little sound into it to get

it working at first, since a digital feedback loop won't startup on

its own. This will probably end up being a 'silent' sample of an

unplugged cable in the actual patch, for 'authenticity'.

Has anyone had problems with max dying a silent death when running

So I'm trying to build a patch to recreate a "no-input mixer" type
setup using tapin/tapout with some feedback loops.

It's working OK so far(this is the seedling of the patch), but it
seems that after running the patch for a bit, or if signals get to
hot, max crashes, not in the program crashing sense, or stack overflow
sense, the audio just stops working, and i have to restart the program
to get it working again.
When conntect disconnect cables, or start/stop dac~ after the crash it
makes a clicking sound.

I searched the mailing list archive but I didn't find anything related
to this, or a 'feedback' patch.

I also found that I needed to 'inject' a little sound into it to get
it working at first, since a digital feedback loop won't startup on
its own. This will probably end up being a 'silent' sample of an
unplugged cable in the actual patch, for 'authenticity'.

Has anyone had problems with max dying a silent death when running
feedback loops?

feedback-loop-causing-max-crash

Runaway feedback will kill any system, analog or digital - the 

difference is in how that manifests. I'd suggest you make sure in 

your patch that you have some way to control (and monitor) feedback 

levels. Manual controls are good (faders work well for this task), 

and compression/limiting can also be very effective. Put some level 

meters on the feedback loop, and watch what happens right before your 

audio cuts out - undoubtedly the levels are 'off the meter' by then.

On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:

> So I'm trying to build a patch to recreate a "no-input mixer" type

> setup using tapin/tapout with some feedback loops.

> Has anyone had problems with max dying a silent death when running

Runaway feedback will kill any system, analog or digital - the  
difference is in how that manifests. I'd suggest you make sure in  
your patch that you have some way to control (and monitor) feedback  
levels. Manual controls are good (faders work well for this task),  
and compression/limiting can also be very effective. Put some level  
meters on the feedback loop, and watch what happens right before your  
audio cuts out - undoubtedly the levels are 'off the meter' by then.

> So I'm trying to build a patch to recreate a "no-input mixer" type
> setup using tapin/tapout with some feedback loops.
>
> ...

> Has anyone had problems with max dying a silent death when running
> feedback loops?
>

----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe

Home 
SFIFEM 
Atrium Sound Space 
OVOS 
CMP 

In addition to what Steven has already reported here, I'd like to 

suggest a saturation, which is also great for adding that "analogue" 

It is also worth noting that tapin~ accepts the "clear" message, which 

should free up the buffer and make your patch work again.

> Runaway feedback will kill any system, analog or digital - the 

> difference is in how that manifests. I'd suggest you make sure in your 

> patch that you have some way to control (and monitor) feedback levels. 

> Manual controls are good (faders work well for this task), and 

> compression/limiting can also be very effective. Put some level meters 

> on the feedback loop, and watch what happens right before your audio 

> cuts out - undoubtedly the levels are 'off the meter' by then.

> On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:

>> So I'm trying to build a patch to recreate a "no-input mixer" type

>> setup using tapin/tapout with some feedback loops.

>> Has anyone had problems with max dying a silent death when running

> ------------------------------------------------------------------------

In addition to what Steven has already reported here, I'd like to 
suggest a saturation, which is also great for adding that "analogue" 
touch (sic).

It is also worth noting that tapin~ accepts the "clear" message, which 
should free up the buffer and make your patch work again.

Steven Miller skrev:
> Runaway feedback will kill any system, analog or digital - the 
> difference is in how that manifests. I'd suggest you make sure in your 
> patch that you have some way to control (and monitor) feedback levels. 
> Manual controls are good (faders work well for this task), and 
> compression/limiting can also be very effective. Put some level meters 
> on the feedback loop, and watch what happens right before your audio 
> cuts out - undoubtedly the levels are 'off the meter' by then.
>
> On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:
>
>> So I'm trying to build a patch to recreate a "no-input mixer" type
>> setup using tapin/tapout with some feedback loops.
>>
>> ...
>
>> Has anyone had problems with max dying a silent death when running
>> feedback loops?
>>
>
> ----
> Steven M. Miller
> Professor, Contemporary Music Program
> College of Santa Fe
>
> Home >
>
> SFIFEM 
> Atrium Sound Space 
> OVOS
> >
> CMP 
>
>
> ------------------------------------------------------------------------
>
>


it seems to be the normalize object who has problem.

it seems to be the normalize object who has problem.
i changed it by clip~
or put some limiter instead.
f./


I was a little disheartened at first, since I figured 'taming' the

loops down would make them cycle~ objects essentially.

I did do some further testing, and putting "normalize~ 15." between

tapout/tapin keeps things within reason. Peakamp~ was reporting values

I will probably crank the normalize up some more to see how far I can

I also created an 'empty' sample that is running the whole time looped

in the background very quietly. It stops the patch from running out of

Would there be any benefit to using comp/limiter/clip inplace of the

normalize here?(In the feedback loops, or the preoutput stage)

I tested the patch with just a clip~ at the end and it still crashed

As far as saturation/treating the sound as it loops, any suggestions there?

I haven't done much signal processing in max yet(still new to it), so

I plan on adding more routing(probably adding a matrix~ setup now), as

well as more general fx(longer delay(more analogy), chorus, eq etc..).

> Runaway feedback will kill any system, analog or digital - the difference is

> in how that manifests. I'd suggest you make sure in your patch that you have

> some way to control (and monitor) feedback levels. Manual controls are good

> (faders work well for this task), and compression/limiting can also be very

> effective. Put some level meters on the feedback loop, and watch what

> happens right before your audio cuts out - undoubtedly the levels are 'off

I was a little disheartened at first, since I figured 'taming' the
loops down would make them cycle~ objects essentially.

I did do some further testing, and putting "normalize~ 15." between
tapout/tapin keeps things within reason. Peakamp~ was reporting values
of 5000+ in my original patch!.
I will probably crank the normalize up some more to see how far I can
get it before crashing the audio.

I also created an 'empty' sample that is running the whole time looped
in the background very quietly. It stops the patch from running out of
material to feedback.

Would there be any benefit to using comp/limiter/clip inplace of the
normalize here?(In the feedback loops, or the preoutput stage)

I tested the patch with just a clip~ at the end and it still crashed
after a bit, as per elt's suggestion.

I haven't done much signal processing in max yet(still new to it), so
I'm dealing more with 'broad strokes'.

I plan on adding more routing(probably adding a matrix~ setup now), as
well as more general fx(longer delay(more analogy), chorus, eq etc..).

On 8/27/07, Steven Miller  wrote:
>
> Runaway feedback will kill any system, analog or digital - the difference is
> in how that manifests. I'd suggest you make sure in your patch that you have
> some way to control (and monitor) feedback levels. Manual controls are good
> (faders work well for this task), and compression/limiting can also be very
> effective. Put some level meters on the feedback loop, and watch what
> happens right before your audio cuts out - undoubtedly the levels are 'off
> the meter' by then.
>
> On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:
>
>
> So I'm trying to build a patch to recreate a "no-input mixer" type
> setup using tapin/tapout with some feedback loops.
>
> ...
>
>
> Has anyone had problems with max dying a silent death when running
> feedback loops?
>
>
>
>
> ----
> Steven M. Miller
> Professor, Contemporary Music Program
> College of Santa Fe
>
> Home SFIFEM 
> Atrium Sound Space 
> OVOS 
> CMP 
>
>
>
>


On Aug 27, 2007, at 1:33 PM, Rodrigo Constanzo wrote:

> Wouldn't anything under 1.0 eventually drop to nothing though? If

> every time its fed back in, its less than before, and it's the only

> input being fed into the tapin(besides the very quiet 'cable' sample),

> which is only there to startup the feedback since theres no

> imperfections in a digital loop to get it started(as compared to a

> Ideally I'd want the *~ value to be high so the feedback gets out of

> control, but that apparantly crashes maxes audio engine(sending

> 'clear' to tapins doesn't work). So I want something to limit it to a

> fixed value, where the *~ is a relative object, forever

> increasing/decreasing, unless I set it to *~1. Normalize~ worked but

> at first, but when it gets quiet again, as pointed out, its gain is

> I might try clip~ after dinner, but I wouldn't want to color the sound

> too much, at this point. Maybe a plain limiter is what I need, but I

> don't have a good understanding of compression(in max specifically,

> Wouldn't anything under 1.0 eventually drop to nothing though? If
> every time its fed back in, its less than before, and it's the only
> input being fed into the tapin(besides the very quiet 'cable' sample),
> which is only there to startup the feedback since theres no
> imperfections in a digital loop to get it started(as compared to a
> physical mixer feeding into itself).
>
> Ideally I'd want the *~ value to be high so the feedback gets out of
> control, but that apparantly crashes maxes audio engine(sending
> 'clear' to tapins doesn't work). So I want something to limit it to a
> fixed value, where the *~ is a relative object, forever
> increasing/decreasing, unless I set it to *~1. Normalize~ worked but
> at first, but when it gets quiet again, as pointed out, its gain is
> way too low to be usable.
>
> I might try clip~ after dinner, but I wouldn't want to color the sound
> too much, at this point. Maybe a plain limiter is what I need, but I
> don't have a good understanding of compression(in max specifically,
> but in general as well).
>
>

Sticking a limi~ in the feedback path is definitely worth doing.

Putting resonant filter(s) in the feedback path can be fun - try using

several taps with filters tuned to different frequencies in each one. Again,

you're asking for a blow-up if you're not careful with the resonance

settings, but you can make some nice noises on your way there :)

When making this sort of patch, I tend to include a global 'clear' button

as a matter of course, which sends the 'clear' message to anything likely to

need it - this includes most filters and delays.

Iirc, to check if an object understands the 'clear'message, command-alt

clicking on an object should give you a list of the messages that the object

understands - I say 'should' because, bizarrely this has suddenly stopped

working here (but then alt clicking is not giving me a .help file either...)

On 27/8/07 16:16, "Rodrigo Constanzo" wrote:

> I was a little disheartened at first, since I figured 'taming' the

> loops down would make them cycle~ objects essentially.

> I did do some further testing, and putting "normalize~ 15." between

> tapout/tapin keeps things within reason. Peakamp~ was reporting values

> I will probably crank the normalize up some more to see how far I can

> I also created an 'empty' sample that is running the whole time looped

> in the background very quietly. It stops the patch from running out of

> Would there be any benefit to using comp/limiter/clip inplace of the

> normalize here?(In the feedback loops, or the preoutput stage)

> I tested the patch with just a clip~ at the end and it still crashed

> As far as saturation/treating the sound as it loops, any suggestions there?

> I haven't done much signal processing in max yet(still new to it), so

> I plan on adding more routing(probably adding a matrix~ setup now), as

> well as more general fx(longer delay(more analogy), chorus, eq etc..).

> #P newex 286 167 65 196617 groove~ one;

> #P newex 317 556 88 196617 buffer~ one noise;

> #P message 93 132 79 196617 1.1 1.1 1.1 1.1;

> #P message 376 153 103 196617 150. 300. 450. 600.;

> #P message 94 153 79 196617 0.5 0.5 0.5 0.5;

> #P flonum 302 518 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 234 556 78 196617 normalize~ 0.2;

> #P flonum 98 488 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 98 467 75 196617 peakamp~ 125;

> #P flonum 193 487 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 193 466 75 196617 peakamp~ 125;

> #P flonum 290 486 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

Sticking a limi~ in the feedback path is definitely worth doing.
 Putting resonant filter(s) in the feedback path can be fun - try using
several taps with filters tuned to different frequencies in each one. Again,
you're asking for a blow-up if you're not careful with the resonance
settings, but you can make some nice noises on your way there :)
 When making this sort of patch, I tend to include a global 'clear' button
as a matter of course, which sends the 'clear' message to anything likely to
need it - this includes most filters and delays.
Iirc, to check if an object understands the 'clear'message, command-alt
clicking on an object should give you a list of the messages that the object
understands - I say 'should' because, bizarrely this has suddenly stopped
working here (but then alt clicking is not giving me a .help file either...)
cheers 
Roger

On 27/8/07 16:16, "Rodrigo Constanzo"  wrote:

> I was a little disheartened at first, since I figured 'taming' the
> loops down would make them cycle~ objects essentially.
>
> I did do some further testing, and putting "normalize~ 15." between
> tapout/tapin keeps things within reason. Peakamp~ was reporting values
> of 5000+ in my original patch!.
> I will probably crank the normalize up some more to see how far I can
> get it before crashing the audio.
>
> I also created an 'empty' sample that is running the whole time looped
> in the background very quietly. It stops the patch from running out of
> material to feedback.
>
> Would there be any benefit to using comp/limiter/clip inplace of the
> normalize here?(In the feedback loops, or the preoutput stage)
>
> I tested the patch with just a clip~ at the end and it still crashed
> after a bit, as per elt's suggestion.
>
> As far as saturation/treating the sound as it loops, any suggestions there?
>
> I haven't done much signal processing in max yet(still new to it), so
> I'm dealing more with 'broad strokes'.
>
> I plan on adding more routing(probably adding a matrix~ setup now), as
> well as more general fx(longer delay(more analogy), chorus, eq etc..).
>
> max v2;
> #N vpatcher 437 186 1460 1008;
> #P window setfont "Sans Serif" 9.;
> #P message 297 268 33 196617 clear;
> #P toggle 235 145 15 0;
> #P message 235 168 43 196617 loop $1;
> #P newex 286 143 41 196617 sig~ 1.;
> #P newex 286 167 65 196617 groove~ one;
> #P newex 317 556 88 196617 buffer~ one noise;
> #P message 93 132 79 196617 1.1 1.1 1.1 1.1;
> #P message 376 153 103 196617 150. 300. 450. 600.;
> #P message 94 153 79 196617 0.5 0.5 0.5 0.5;
> #P flonum 302 518 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 234 556 78 196617 normalize~ 0.2;
> #P newex 139 443 41 196617 *~ 0.5;
> #P newex 234 442 41 196617 *~ 0.5;
> #P newex 332 441 41 196617 *~ 0.5;
> #P newex 431 442 41 196617 *~ 0.5;
> #P flonum 98 488 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 98 467 75 196617 peakamp~ 125;
> #P flonum 193 487 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 193 466 75 196617 peakamp~ 125;
> #P flonum 290 486 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 290 465 75 196617 peakamp~ 125;
> #P flonum 390 486 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 390 465 75 196617 peakamp~ 125;
> #P newex 293 195 39 196617 noise~;
> #P user umenu 241 195 47 196647 1 64 211 1;
> #X add off;
> #X add adc;
> #X add noise;
> #X add sample;
> #P newex 293 218 41 196617 *~ 0.1;
> #P newex 241 245 62 196617 selector~ 3;
> #P newex 256 218 31 196617 adc~;
> #P newex 94 271 88 196617 unpack 0. 0. 0. 0.;
> #P user multiSlider 94 175 99 90 0. 1.1 4 2937 47 0 5 2 2 0 0;
> #M frgb 0 0 0;
> #M brgb 255 255 255;
> #M rgb2 127 127 127;
> #M rgb3 0 0 0;
> #M rgb4 37 52 91;
> #M rgb5 74 105 182;
> #M rgb6 112 158 18;
> #M rgb7 149 211 110;
> #M rgb8 187 9 201;
> #M rgb9 224 62 37;
> #M rgb10 7 114 128;
> #P newex 376 271 88 196617 unpack 0. 0. 0. 0.;
> #P user multiSlider 376 175 99 90 5. 1000. 4 2937 47 0 5 2 2 0 0;
> #M frgb 0 0 0;
> #M brgb 255 255 255;
> #M rgb2 127 127 127;
> #M rgb3 0 0 0;
> #M rgb4 37 52 91;
> #M rgb5 74 105 182;
> #M rgb6 112 158 18;
> #M rgb7 149 211 110;
> #M rgb8 187 9 201;
> #M rgb9 224 62 37;
> #M rgb10 7 114 128;
> #P newex 105 413 78 196617 normalize~ 15.;
> #P flonum 144 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 98 439 27 196617 *~;
> #P flonum 98 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 98 389 81 196617 tapout~ 5.;
> #P newex 98 365 81 196617 tapin~ 1000;
> #P newex 397 413 78 196617 normalize~ 15.;
> #P flonum 436 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 390 439 27 196617 *~;
> #P flonum 390 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 390 389 81 196617 tapout~ 5.;
> #P newex 390 365 81 196617 tapin~ 1000;
> #P newex 297 413 78 196617 normalize~ 15.;
> #P flonum 336 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 290 439 27 196617 *~;
> #P flonum 290 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 290 389 81 196617 tapout~ 5.;
> #P newex 290 365 81 196617 tapin~ 1000;
> #P newex 200 413 78 196617 normalize~ 15.;
> #P flonum 239 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 193 439 27 196617 *~;
> #P flonum 193 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 193 389 81 196617 tapout~ 5.;
> #P newex 193 365 81 196617 tapin~ 1000;
> #P toggle 235 586 15 0;
> #P newex 255 585 32 196617 dac~;
> #P connect 51 0 28 0;
> #P connect 49 0 28 0;
> #P connect 28 0 29 0;
> #P connect 27 0 22 0;
> #P fasten 25 0 20 0 110 433 182 433 182 361 103 361;
> #P connect 57 0 20 0;
> #P connect 31 0 20 0;
> #P connect 20 0 21 0;
> #P fasten 22 0 21 0 103 360 95 360 95 386 103 386;
> #P connect 21 0 23 0;
> #P connect 23 0 41 0;
> #P connect 41 0 42 0;
> #P fasten 23 0 25 0 103 460 94 460 94 410 110 410;
> #P fasten 24 0 23 1 149 359 185 359 185 436 120 436;
> #P fasten 23 0 46 0 103 460 131 460 131 439 144 439;
> #P connect 29 0 24 0;
> #P connect 27 1 4 0;
> #P fasten 7 0 2 0 205 433 277 433 277 361 198 361;
> #P connect 57 0 2 0;
> #P connect 31 0 2 0;
> #P fasten 4 0 3 0 198 360 190 360 190 386 198 386;
> #P connect 2 0 3 0;
> #P connect 3 0 5 0;
> #P connect 5 0 39 0;
> #P connect 39 0 40 0;
> #P fasten 5 0 7 0 198 460 189 460 189 410 205 410;
> #P fasten 6 0 5 1 244 359 280 359 280 436 215 436;
> #P fasten 5 0 45 0 198 461 226 461 226 439 239 439;
> #P fasten 43 0 47 0 436 462 471 462 471 550 239 550;
> #P fasten 44 0 47 0 337 462 369 462 369 550 239 550;
> #P fasten 45 0 47 0 239 461 272 461 272 550 239 550;
> #P fasten 46 0 47 0 144 463 182 463 182 550 239 550;
> #P connect 56 0 55 0;
> #P connect 29 1 6 0;
> #P connect 33 0 31 0;
> #P fasten 47 0 0 0 239 578 260 578;
> #P fasten 1 0 0 0 240 603 252 603 252 582 260 582;
> #P connect 30 0 31 1;
> #P connect 30 1 31 1;
> #P connect 32 0 31 2;
> #P fasten 47 0 0 1 239 578 282 578;
> #P fasten 55 0 53 0 240 187 283 187 283 162 291 162;
> #P connect 54 0 53 0;
> #P connect 27 2 10 0;
> #P fasten 13 0 8 0 302 433 374 433 374 361 295 361;
> #P connect 57 0 8 0;
> #P connect 31 0 8 0;
> #P connect 8 0 9 0;
> #P fasten 10 0 9 0 295 360 287 360 287 386 295 386;
> #P connect 9 0 11 0;
> #P connect 11 0 37 0;
> #P connect 37 0 38 0;
> #P fasten 53 0 31 3 291 189 339 189 339 241 297 241;
> #P connect 34 0 32 0;
> #P fasten 11 0 13 0 295 460 286 460 286 410 302 410;
> #P connect 48 0 47 1;
> #P fasten 12 0 11 1 341 359 377 359 377 436 312 436;
> #P fasten 11 0 44 0 295 460 324 460 324 439 337 439;
> #P connect 29 2 12 0;
> #P connect 50 0 26 0;
> #P connect 26 0 27 0;
> #P connect 27 3 16 0;
> #P fasten 19 0 14 0 402 433 474 433 474 361 395 361;
> #P connect 57 0 14 0;
> #P connect 31 0 14 0;
> #P fasten 16 0 15 0 395 360 387 360 387 386 395 386;
> #P connect 14 0 15 0;
> #P connect 15 0 17 0;
> #P connect 17 0 35 0;
> #P connect 35 0 36 0;
> #P fasten 17 0 19 0 395 460 386 460 386 410 402 410;
> #P fasten 18 0 17 1 441 359 477 359 477 436 412 436;
> #P fasten 17 0 43 0 395 460 423 460 423 439 436 439;
> #P connect 29 3 18 0;
> #P pop;
>
> On 8/27/07, Steven Miller  wrote:
>>
>> Runaway feedback will kill any system, analog or digital - the difference is
>> in how that manifests. I'd suggest you make sure in your patch that you have
>> some way to control (and monitor) feedback levels. Manual controls are good
>> (faders work well for this task), and compression/limiting can also be very
>> effective. Put some level meters on the feedback loop, and watch what
>> happens right before your audio cuts out - undoubtedly the levels are 'off
>> the meter' by then.
>>
>> On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:
>>
>>
>> So I'm trying to build a patch to recreate a "no-input mixer" type
>> setup using tapin/tapout with some feedback loops.
>>
>> ...
>>
>>
>> Has anyone had problems with max dying a silent death when running
>> feedback loops?
>>
>>
>>
>>
>> ----
>> Steven M. Miller
>> Professor, Contemporary Music Program
>> College of Santa Fe
>>
>> Home SFIFEM 
>> Atrium Sound Space 
>> OVOS 
>> CMP 
>>
>>
>>
>>

I ended up putting a limiter in the loops and its toned it down

nicely. So I've been building a monster of a patch around it. I havent

fully run all of it at the same time, but the fx portion chugs at a

solid 60-70% CPU usage listed in max. Hopefully I won't run into

Is there a general effeciency guide somewhere? Like how to squeeze the

most of max, and what objects are favorable to others. Like is scaling

midi to MSP data more effecient with "scale" or "expr" objects. Is

having several instances of the same bpathcer doing diff things

better/worse than duplicating the patchers to be bpatched etc..

Once the patch is done I'll post it up, as its my first major 'from

> Sticking a limi~ in the feedback path is definitely worth doing.

> Putting resonant filter(s) in the feedback path can be fun - try using

> several taps with filters tuned to different frequencies in each one. Again,

> you're asking for a blow-up if you're not careful with the resonance

> settings, but you can make some nice noises on your way there :)

> When making this sort of patch, I tend to include a global 'clear' button

> as a matter of course, which sends the 'clear' message to anything likely to

> need it - this includes most filters and delays.

> Iirc, to check if an object understands the 'clear'message, command-alt

> clicking on an object should give you a list of the messages that the object

> understands - I say 'should' because, bizarrely this has suddenly stopped

> working here (but then alt clicking is not giving me a .help file either...)

> On 27/8/07 16:16, "Rodrigo Constanzo" wrote:

> > I was a little disheartened at first, since I figured 'taming' the

> > loops down would make them cycle~ objects essentially.

> > I did do some further testing, and putting "normalize~ 15." between

> > tapout/tapin keeps things within reason. Peakamp~ was reporting values

> > I will probably crank the normalize up some more to see how far I can

> > I also created an 'empty' sample that is running the whole time looped

> > in the background very quietly. It stops the patch from running out of

> > Would there be any benefit to using comp/limiter/clip inplace of the

> > normalize here?(In the feedback loops, or the preoutput stage)

> > I tested the patch with just a clip~ at the end and it still crashed

> > after a bit, as per elt's suggestion.

> > As far as saturation/treating the sound as it loops, any suggestions there?

> > I haven't done much signal processing in max yet(still new to it), so

> > I'm dealing more with 'broad strokes'.

> > I plan on adding more routing(probably adding a matrix~ setup now), as

> > well as more general fx(longer delay(more analogy), chorus, eq etc..).

I ended up putting a limiter in the loops and its toned it down
nicely. So I've been building a monster of a patch around it. I havent
fully run all of it at the same time, but the fx portion chugs at a
solid 60-70% CPU usage listed in max. Hopefully I won't run into
problems.

Is there a general effeciency guide somewhere? Like how to squeeze the
most of max, and what objects are favorable to others. Like is scaling
midi to MSP data more effecient with "scale" or "expr" objects. Is
having several instances of the same bpathcer doing diff things
better/worse than duplicating the patchers to be bpatched etc..

Once the patch is done I'll post it up, as its my first major 'from
scratch' patch.

On 8/29/07, Roger Carruthers  wrote:
> Sticking a limi~ in the feedback path is definitely worth doing.
>  Putting resonant filter(s) in the feedback path can be fun - try using
> several taps with filters tuned to different frequencies in each one. Again,
> you're asking for a blow-up if you're not careful with the resonance
> settings, but you can make some nice noises on your way there :)
>  When making this sort of patch, I tend to include a global 'clear' button
> as a matter of course, which sends the 'clear' message to anything likely to
> need it - this includes most filters and delays.
> Iirc, to check if an object understands the 'clear'message, command-alt
> clicking on an object should give you a list of the messages that the object
> understands - I say 'should' because, bizarrely this has suddenly stopped
> working here (but then alt clicking is not giving me a .help file either...)
> cheers
> Roger
>
>
> On 27/8/07 16:16, "Rodrigo Constanzo"  wrote:
>
> > I was a little disheartened at first, since I figured 'taming' the
> > loops down would make them cycle~ objects essentially.
> >
> > I did do some further testing, and putting "normalize~ 15." between
> > tapout/tapin keeps things within reason. Peakamp~ was reporting values
> > of 5000+ in my original patch!.
> > I will probably crank the normalize up some more to see how far I can
> > get it before crashing the audio.
> >
> > I also created an 'empty' sample that is running the whole time looped
> > in the background very quietly. It stops the patch from running out of
> > material to feedback.
> >
> > Would there be any benefit to using comp/limiter/clip inplace of the
> > normalize here?(In the feedback loops, or the preoutput stage)
> >
> > I tested the patch with just a clip~ at the end and it still crashed
> > after a bit, as per elt's suggestion.
> >
> > As far as saturation/treating the sound as it loops, any suggestions there?
> >
> > I haven't done much signal processing in max yet(still new to it), so
> > I'm dealing more with 'broad strokes'.
> >
> > I plan on adding more routing(probably adding a matrix~ setup now), as
> > well as more general fx(longer delay(more analogy), chorus, eq etc..).
> >
> > max v2;
> > #N vpatcher 437 186 1460 1008;
> > #P window setfont "Sans Serif" 9.;
> > #P message 297 268 33 196617 clear;
> > #P toggle 235 145 15 0;
> > #P message 235 168 43 196617 loop $1;
> > #P newex 286 143 41 196617 sig~ 1.;
> > #P newex 286 167 65 196617 groove~ one;
> > #P newex 317 556 88 196617 buffer~ one noise;
> > #P message 93 132 79 196617 1.1 1.1 1.1 1.1;
> > #P message 376 153 103 196617 150. 300. 450. 600.;
> > #P message 94 153 79 196617 0.5 0.5 0.5 0.5;
> > #P flonum 302 518 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 234 556 78 196617 normalize~ 0.2;
> > #P newex 139 443 41 196617 *~ 0.5;
> > #P newex 234 442 41 196617 *~ 0.5;
> > #P newex 332 441 41 196617 *~ 0.5;
> > #P newex 431 442 41 196617 *~ 0.5;
> > #P flonum 98 488 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 98 467 75 196617 peakamp~ 125;
> > #P flonum 193 487 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 193 466 75 196617 peakamp~ 125;
> > #P flonum 290 486 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 290 465 75 196617 peakamp~ 125;
> > #P flonum 390 486 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 390 465 75 196617 peakamp~ 125;
> > #P newex 293 195 39 196617 noise~;
> > #P user umenu 241 195 47 196647 1 64 211 1;
> > #X add off;
> > #X add adc;
> > #X add noise;
> > #X add sample;
> > #P newex 293 218 41 196617 *~ 0.1;
> > #P newex 241 245 62 196617 selector~ 3;
> > #P newex 256 218 31 196617 adc~;
> > #P newex 94 271 88 196617 unpack 0. 0. 0. 0.;
> > #P user multiSlider 94 175 99 90 0. 1.1 4 2937 47 0 5 2 2 0 0;
> > #M frgb 0 0 0;
> > #M brgb 255 255 255;
> > #M rgb2 127 127 127;
> > #M rgb3 0 0 0;
> > #M rgb4 37 52 91;
> > #M rgb5 74 105 182;
> > #M rgb6 112 158 18;
> > #M rgb7 149 211 110;
> > #M rgb8 187 9 201;
> > #M rgb9 224 62 37;
> > #M rgb10 7 114 128;
> > #P newex 376 271 88 196617 unpack 0. 0. 0. 0.;
> > #P user multiSlider 376 175 99 90 5. 1000. 4 2937 47 0 5 2 2 0 0;
> > #M frgb 0 0 0;
> > #M brgb 255 255 255;
> > #M rgb2 127 127 127;
> > #M rgb3 0 0 0;
> > #M rgb4 37 52 91;
> > #M rgb5 74 105 182;
> > #M rgb6 112 158 18;
> > #M rgb7 149 211 110;
> > #M rgb8 187 9 201;
> > #M rgb9 224 62 37;
> > #M rgb10 7 114 128;
> > #P newex 105 413 78 196617 normalize~ 15.;
> > #P flonum 144 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 98 439 27 196617 *~;
> > #P flonum 98 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 98 389 81 196617 tapout~ 5.;
> > #P newex 98 365 81 196617 tapin~ 1000;
> > #P newex 397 413 78 196617 normalize~ 15.;
> > #P flonum 436 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 390 439 27 196617 *~;
> > #P flonum 390 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 390 389 81 196617 tapout~ 5.;
> > #P newex 390 365 81 196617 tapin~ 1000;
> > #P newex 297 413 78 196617 normalize~ 15.;
> > #P flonum 336 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 290 439 27 196617 *~;
> > #P flonum 290 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 290 389 81 196617 tapout~ 5.;
> > #P newex 290 365 81 196617 tapin~ 1000;
> > #P newex 200 413 78 196617 normalize~ 15.;
> > #P flonum 239 342 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 193 439 27 196617 *~;
> > #P flonum 193 342 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 193 389 81 196617 tapout~ 5.;
> > #P newex 193 365 81 196617 tapin~ 1000;
> > #P toggle 235 586 15 0;
> > #P newex 255 585 32 196617 dac~;
> > #P connect 51 0 28 0;
> > #P connect 49 0 28 0;
> > #P connect 28 0 29 0;
> > #P connect 27 0 22 0;
> > #P fasten 25 0 20 0 110 433 182 433 182 361 103 361;
> > #P connect 57 0 20 0;
> > #P connect 31 0 20 0;
> > #P connect 20 0 21 0;
> > #P fasten 22 0 21 0 103 360 95 360 95 386 103 386;
> > #P connect 21 0 23 0;
> > #P connect 23 0 41 0;
> > #P connect 41 0 42 0;
> > #P fasten 23 0 25 0 103 460 94 460 94 410 110 410;
> > #P fasten 24 0 23 1 149 359 185 359 185 436 120 436;
> > #P fasten 23 0 46 0 103 460 131 460 131 439 144 439;
> > #P connect 29 0 24 0;
> > #P connect 27 1 4 0;
> > #P fasten 7 0 2 0 205 433 277 433 277 361 198 361;
> > #P connect 57 0 2 0;
> > #P connect 31 0 2 0;
> > #P fasten 4 0 3 0 198 360 190 360 190 386 198 386;
> > #P connect 2 0 3 0;
> > #P connect 3 0 5 0;
> > #P connect 5 0 39 0;
> > #P connect 39 0 40 0;
> > #P fasten 5 0 7 0 198 460 189 460 189 410 205 410;
> > #P fasten 6 0 5 1 244 359 280 359 280 436 215 436;
> > #P fasten 5 0 45 0 198 461 226 461 226 439 239 439;
> > #P fasten 43 0 47 0 436 462 471 462 471 550 239 550;
> > #P fasten 44 0 47 0 337 462 369 462 369 550 239 550;
> > #P fasten 45 0 47 0 239 461 272 461 272 550 239 550;
> > #P fasten 46 0 47 0 144 463 182 463 182 550 239 550;
> > #P connect 56 0 55 0;
> > #P connect 29 1 6 0;
> > #P connect 33 0 31 0;
> > #P fasten 47 0 0 0 239 578 260 578;
> > #P fasten 1 0 0 0 240 603 252 603 252 582 260 582;
> > #P connect 30 0 31 1;
> > #P connect 30 1 31 1;
> > #P connect 32 0 31 2;
> > #P fasten 47 0 0 1 239 578 282 578;
> > #P fasten 55 0 53 0 240 187 283 187 283 162 291 162;
> > #P connect 54 0 53 0;
> > #P connect 27 2 10 0;
> > #P fasten 13 0 8 0 302 433 374 433 374 361 295 361;
> > #P connect 57 0 8 0;
> > #P connect 31 0 8 0;
> > #P connect 8 0 9 0;
> > #P fasten 10 0 9 0 295 360 287 360 287 386 295 386;
> > #P connect 9 0 11 0;
> > #P connect 11 0 37 0;
> > #P connect 37 0 38 0;
> > #P fasten 53 0 31 3 291 189 339 189 339 241 297 241;
> > #P connect 34 0 32 0;
> > #P fasten 11 0 13 0 295 460 286 460 286 410 302 410;
> > #P connect 48 0 47 1;
> > #P fasten 12 0 11 1 341 359 377 359 377 436 312 436;
> > #P fasten 11 0 44 0 295 460 324 460 324 439 337 439;
> > #P connect 29 2 12 0;
> > #P connect 50 0 26 0;
> > #P connect 26 0 27 0;
> > #P connect 27 3 16 0;
> > #P fasten 19 0 14 0 402 433 474 433 474 361 395 361;
> > #P connect 57 0 14 0;
> > #P connect 31 0 14 0;
> > #P fasten 16 0 15 0 395 360 387 360 387 386 395 386;
> > #P connect 14 0 15 0;
> > #P connect 15 0 17 0;
> > #P connect 17 0 35 0;
> > #P connect 35 0 36 0;
> > #P fasten 17 0 19 0 395 460 386 460 386 410 402 410;
> > #P fasten 18 0 17 1 441 359 477 359 477 436 412 436;
> > #P fasten 17 0 43 0 395 460 423 460 423 439 436 439;
> > #P connect 29 3 18 0;
> > #P pop;
> >
> > On 8/27/07, Steven Miller  wrote:
> >>
> >> Runaway feedback will kill any system, analog or digital - the difference is
> >> in how that manifests. I'd suggest you make sure in your patch that you have
> >> some way to control (and monitor) feedback levels. Manual controls are good
> >> (faders work well for this task), and compression/limiting can also be very
> >> effective. Put some level meters on the feedback loop, and watch what
> >> happens right before your audio cuts out - undoubtedly the levels are 'off
> >> the meter' by then.
> >>
> >> On Aug 26, 2007, at 8:13 PM, Rodrigo Constanzo wrote:
> >>
> >>
> >> So I'm trying to build a patch to recreate a "no-input mixer" type
> >> setup using tapin/tapout with some feedback loops.
> >>
> >> ...
> >>
> >>
> >> Has anyone had problems with max dying a silent death when running
> >> feedback loops?
> >>
> >>
> >>
> >>
> >> ----
> >> Steven M. Miller
> >> Professor, Contemporary Music Program
> >> College of Santa Fe
> >>
> >> Home SFIFEM 
> >> Atrium Sound Space 
> >> OVOS 
> >> CMP 
> >>
> >>
> >>
> >>
>
>
>


I had a similar problem recently with a patch not too different from 

yours. I have to add, that I never experienced it before for years. But 

this time I had an audio interface which would not cut out DC. Finally 

all I had to do is put a dcblock~ in the feedback. What made it blow up 

was a DC component... I bet thats your problem...

I would not use normalize for the same reasons Emmanuel already 

mentioned and it would not help with a DC problem...

Rodrigo Constanzo schrieb:
> I did do some further testing, and putting "normalize~ 15." between
> tapout/tapin keeps things within reason. Peakamp~ was reporting values
> of 5000+ in my original patch!.

I had a similar problem recently with a patch not too different from 
yours. I have to add, that I never experienced it before for years. But 
this time I had an audio interface which would not cut out DC. Finally 
all I had to do is put a dcblock~ in the feedback. What made it blow up 
was a DC component... I bet thats your problem...

I would not use normalize for the same reasons Emmanuel already 
mentioned and it would not help with a DC problem...

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


Feedback loop causing max crash?