Feedback loop issue. When the input of an msp object is directly or indirectly dependent on its output an impossible situation is created (that in which you need the output in order to calculate the output) and maxmsp will not run that part of the chain.

This isn't possible with normal patch cords. You can use send~ and receive~ to make connections, but you will encounter latency. IF that is an issue you could also do something like replicate the objects in two different patches (reversing the order) and host within a poly to allow you to turn each one on and off, or connect two poly~s in series and dynamically load the patches in the order which you require them to be in.

HTH

Alex

Thanx so much Alex, I was also thinking about the poly~ solution.. what I don't understand: you wrote 'When the input of an msp object is directly or indirectly dependent on its output'....where does this problem occur in my drawing?

Thanx again. Peer

The "gate~s do not create different different signal chains, nor do they have an awareness of the settings of any other gate~.

So - in your diagram the sound mod patch is dependent on the output of the lower gate~, which is dependent (indirectly) on the output of the sound mod patch - there's your loop..... IT doesn't matter what the settings of the gate~s are.

a pdf of a handdrawn maxmsp patch ... that deserves a special prize for creativity.

@ Alex : oké - things become clear...thank u so much @ Roman: the real patcher is 1MB and 6 months of work, so it's a bit difficult to attach everything no? And it's good to keep being creative in your head - some people loose this ability

[QUOTE]it's good to keep being creative in your head - some people loose this ability[/QUOTE]

I've lost it.........can't wait to finish uni, have a holiday and attempt to get myself back!!

(why can we not do quotes and other such things on this forum like most others?........it would be most useful!)

you must be very creative to find out how to quote or make lists or bold fonts in here. i have given it up the other day. ^^

i'm not at this point yet - as u can recoginze with my attempt for a picasso-like-max-patcher-drawing ;-)

anyway, bottom line for me: i don't understand why the [gate~] object doesn't create different signal chains - cause if I put a [number~] object at output 1 or 2 they show me a signal flow at outlet 1 if outlet 1 is opened and a signal flow at outlet 2 if outlet 2 is opened....of course I know that the signal is not interrupted (for that I should use poly~) but in my head the [gate~] object was like 2 doors and u can decide if u (the signal) want to enter thru the first or the second door ---- but maybe I was too creative again ;-))

Your model is fine for thinking about what the gate~ can be used *for*, but unfortunately it doesn't reflect the underlying programming model.

When you turn the dac~ on in MaxMSP the graphical connections between objects are translated into a dsp chain. This does a few things, but most importantly it decides which order each object will process in when calculating order. Each object appears once only in a list of which order to call the calculation (perform) functions. This order is static. In this system the output of an object is dependent on *all* inputs, regardless of whether or not they are used to calculate the output.

Inside the gate what actually happens is that samples are copied from the relevant to the output.

The confusion here is between the dsp chain (this static ordering) and the signal flow you are using in your model (which is virtual).

Hope this helps clarify things.

It helped a lot Alex...Thank u for your patience. I did some experiments today and as usual [poly~] is your friend and solved all problems. So if u really want to cut a signal chain the use of [poly~] is the best solution cause -like I learned now ;-)) - [gate~] doesn't cut the dsp chain.

Long way, some smoking brains, but I think I've got it now :-)