Forums > MaxMSP

object that returns true when signal is not present

July 11, 2007 | 7:55 pm

Hi,
I need some way to gate input to zigzag~ based on zigzag~’s output, so it refuses oncoming signals during the execution of its envelope. My main problem is that [sig~ 0.] is different from {nothing}; when zigzag~ initializes, it doesn’t output *anything*, which means that [==~ 0.] returns false (0). Does anybody know of a signal object that returns true (1) when a signal is *not* present? A patch that illustrates the problem is below.

{I’m working on a grain envelope generator that uses a cycle~triggered zigzag~ inside poly~ to drive portions of 512-sample buffers using wave~.}

Thanks,
Myer

max v2;
#N vpatcher 22 141 240 377;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N vpatcher 249 141 1087 689;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 598 385 123 9109513 this doesn’t …;
#P window setfont "Sans Serif" 12.;
#P user number~ 564 412 603 430 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 391 419 430 437 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 169 329 208 347 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 153 218 136 9109513 second outlet is signal of index number , last outlet is bang on completion;
#P comment 301 138 77 9109513 store an envelope;
#P window setfont "Sans Serif" 12.;
#P user number~ 152 434 191 452 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 200 403 239 421 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 148 266 187 284 12 139 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 293 117 114 9109513 0 0 1 1000 2 1000 0 1000;
#P inlet 200 382 15 0;
#P newex 293 21 45 9109513 loadbang;
#P message 483 116 39 9109513 mode 1;
#P newex 96 226 53 9109513 zigzag~;
#P window linecount 0;
#P newex 155 404 31 9109513 gate~;
#P toggle 412 117 16 0;
#P newex 438 117 28 9109513 dac~;
#P comment 484 136 74 9109513 makes cycle~ period trigger zigzag~ envelope;
#P window setfont "Sans Serif" 14.;
#P comment 375 221 335 196622 I’m working on a granular patch that uses cycle~ [outside of poly~] to trigger zigzag~ [inside poly~]. I need some way to prevent cycle~ from retriggering a zigzag~ envelope while it’s executing ; unfortunately there’s no [mode 4] message to zigzag that prevents this. Is there an object that detects if a signal is NOT present???;
#P window setfont "Sans Serif" 9.;
#P newex 147 303 34 196617 ==~ 0.;
#P newex 389 371 36 196617 sig~ 0.;
#P newex 389 394 34 196617 ==~ 0.;
#P comment 434 387 123 196617 this returns true , but …;
#P newex 562 387 34 196617 ==~ 0.;
#P message 223 330 14 196617 1;
#P connect 10 0 11 0;
#P connect 15 0 11 0;
#P connect 12 0 11 0;
#P connect 11 1 5 0;
#P connect 11 1 16 0;
#P connect 10 0 18 0;
#P connect 5 0 10 0;
#P connect 0 0 10 0;
#P connect 5 0 21 0;
#P connect 14 0 10 1;
#P connect 14 0 17 0;
#P connect 11 3 0 0;
#P connect 13 0 15 0;
#P connect 4 0 3 0;
#P connect 3 0 22 0;
#P connect 13 0 9 0;
#P connect 9 0 8 0;
#P connect 13 0 12 0;
#P connect 1 0 23 0;
#P pop;
#P newobj 40 152 16 9109513 p;
#P newex 40 36 45 9109513 loadbang;
#P newex 40 82 41 9109513 pcontrol;
#P message 40 60 28 9109513 open;
#P newex 88 82 44 9109513 cycle~ 1;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 0 0 4 0;
#P pop;


July 11, 2007 | 8:51 pm

On 11 juil. 07, at 21:56, Myer wrote:

> I need some way to gate input to zigzag~ based on zigzag~’s output,
> so it refuses oncoming signals during the execution of its
> envelope. My main problem is that [sig~ 0.] is different from
> {nothing}; when zigzag~ initializes, it doesn’t output *anything*,
> which means that [==~ 0.] returns false (0). Does anybody know of
> a signal object that returns true (1) when a signal is *not*
> present? A patch that illustrates the problem is below.
>
> {I’m working on a grain envelope generator that uses a
> cycle~triggered zigzag~ inside poly~ to drive portions of 512-
> sample buffers using wave~.

Hi,

I didn’t look really closely, but your problem is that you’re trying
to make a feedback loop with signal, and this is never gonna work
unless you introduce one signal vector delay (tapin~/tapout~ or send~/
receive). You may have to use other technics, sah~ is usually used in
this kinda problem.

ej


July 12, 2007 | 9:46 am

Myer schrieb:
> Does anybody know of a signal object that returns true (1) when a
> signal is *not* present? A patch that illustrates the problem is
> below.

A signal is always present, unless you forgot to turn on audio…

#P user ezdac~ 183 129 227 162 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 312 101 123 196617 this does as well…;
#P window setfont "Sans Serif" 12.;
#P user number~ 269 129 308 148 12 3 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P user number~ 100 132 139 151 12 3 3 2 0. 0. 0 0. 70 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P window setfont "Sans Serif" 9.;
#P newex 98 84 36 196617 sig~ 0.;
#P newex 98 107 41 196617 ==~ 0.;
#P comment 143 100 123 196617 this returns true , but …;
#P newex 269 101 40 196617 ==~ 0.;
#P connect 3 0 2 0;
#P connect 2 0 4 0;
#P connect 0 0 5 0;
#P window clipboard copycount 8;


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


July 12, 2007 | 6:24 pm

Thanks Tiedje,
Yeah, my bad! As soon as I posted, I realized that the dac~ wasn’t on when I set up that part of the example. Sorry!

Thanks also, Emmanuel, for cluing me in to the feedback loop. I don’t understand how it is a feedback loop, but clearly MSP thinks it is, and is preemptively disabling it; if I delete the signal cable between zigzag~ and [==~ 0.], everything works as expected again. The only way I can see to produce a problem situation would be to program zigzag~ to traverse each of its indecies in zero time, and to jack cycle~’s frequency up too. That, even, wouldn’t be an infinite loop. I’ve read through the feedback MSP tutorials, but can’t seem to find anything about what MSP preemptively considers feedback. Can anyone point me in the direction of some documentation? I’ve read through a few posts [1 and 2 below].

What I really want is to be able to route signals to specific poly~ instantiations based on busy status. Has anyone heard of someone doing this? Is there a "getter" for the [thispoly~] busy status? In the MSP documentation, all I see is a "setter".

It seems a little bit heavy-handed to use tapin~ and tapout~ inside poly~ for granular stuff, so for now I’m going to resort to using midinote messages to trigger zigzag~ envelopes, until a signal based solution becomes apparent.

Again, thanks,
Myer

1.) http://www.cycling74.com/forums/index.php?t=msg&goto=105060&rid=5366&S=70b9736148b7c1056ceafcdb4c016a8a&srch=feedback+msp#msg_105060
2.)

http://www.cycling74.com/forums/index.php?t=msg&goto=106664&rid=5366&S=70b9736148b7c1056ceafcdb4c016a8a&srch=feedback+msp#msg_106664


July 12, 2007 | 6:51 pm

Hi Myer,
Attached is a sketch that I threw together at one point for doing signal-based granular playback using standard max objects. There might be some stuff in there that helps you out.

hth,

Andrew B.


July 12, 2007 | 8:46 pm

Andrew B.,
This helps quite a bit. I never even thought of using the patch instantiation number itself as a factor; what a clever solution! The makeshift "&&~" out of [< ~],[>~],and [*~] at the top of polpus works quite well. It took me a bit to figure out what was going on in your patch, since your solution fits better inside the "object-orientedness" of the max paradigm than my procedural thinking does.
Thanks a lot!
Myer


July 14, 2007 | 1:36 pm

Myer schrieb:
> What I really want is to be able to route signals to specific poly~
> instantiations based on busy status. Has anyone heard of someone
> doing this?

This is too funny, because everybody who is using poly~ will do it, its
the core of th whole idea, that the voicallocation is built in and you
don’t need to deal with it. You achieve that with the note message. It
will send the message to the next non busy voice…

> Is there a "getter" for the [thispoly~] busy status? In
> the MSP documentation, all I see is a "setter".

The "getter" is called "busymap". Abd there is also "mutemap" for the
mute status…

Inside the poly~ you should be able to know which voice is busy, you
have to set it yourself anyway, if you put in a send object you can
listen to the busy state of every poly~ object.

Stefan


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


July 27, 2007 | 4:32 pm

Tiedje,
Thanks for the heads up. I guess I hadn’t known about both mutemap AND busymap.

>Myer schrieb:
>> What I really want is to be able to route signals to specific poly~
>> instantiations based on busy status. Has anyone heard of someone
>> doing this?

>This is too funny, because everybody who is using poly~ will do it, its the core of the whole idea, that the voicallocation is built in and you don’t need to deal with it. You achieve that with the note message. It will send the message to the next non busy voice…

Haha, yes, but cf. in my post:

> …for now I’m going to resort to using midinote messages to trigger zigzag~ envelopes, until a signal based solution becomes apparent.

This in the end is what I ended up doing, but I really wanted signal-level accuracy – using zigzag~ to shape individual grains and then generate clouds based on input signal.


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