object that returns true when signal is not present
Jul 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
- Jul 11 2007 | 8:51 pmOn 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
- Jul 12 2007 | 9:46 amMyer 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...-- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
- Jul 12 2007 | 6:24 pmThanks 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
- Jul 12 2007 | 6:51 pmHi 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.
- Jul 12 2007 | 8:46 pmAndrew 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
- Jul 14 2007 | 1:36 pmMyer 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
- Jul 27 2007 | 4:32 pmTiedje, 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.
