So here is the starting function to a greater project. First an aside, should [uzi] work better than [metro] of 1? I am not into the grotesque nature of [uzi] any way.

About the patch: Think of it as 3 vertical groupings (left to right), the test/abstract, the actual function, and the stop control. The goal of the starting function is to produce integers with specific timing between each output, (I was using [metro] to give the delay but then it became more logical to base the delays off of actual feedback of the rest of the patch. Specifically off of a [line]'s output). I have made some cleaning edits and that seems to have improved the functionality of this but by no means is working correctly (as well as cleaning wasnt supposed to improve anything besides the removal of visual clutter).

The current problem that I see is metro is not remaining on. I see no reason why the initial bang should bang everything else. It seems like I should only be giving [counter] 1x bang and thus only step through one number and the stop [metro] function should not take place. Is select a horrific object that in principle is great but otherwise fails? 

So here is the starting function to a greater project. First an aside, should [uzi] work better than [metro] of 1?  I am not into the grotesque nature of [uzi] any way.

About the patch:  Think of it as 3 vertical groupings (left to right), the test/abstract, the actual function, and the stop control.  The goal of the starting function is to produce integers with specific timing between each output, (I was using [metro] to give the delay but then it became more logical to base the delays off of actual feedback of the rest of the patch. Specifically off of a [line]'s output).  I have made some cleaning edits and that seems to have improved the functionality of this but by no means is working correctly (as well as cleaning wasnt supposed to improve anything besides the removal of visual clutter).

The current problem that I see is metro is not remaining on. I see no reason why the initial bang should bang everything else. It seems like I should only be giving [counter] 1x bang and thus only step through one number and the stop [metro] function should not take place. Is select a horrific object that in principle is great but otherwise fails? 


metro-to-sel-not-working-so-well

The logic of this patch is too convoluted for me to trace right now, but in general select works fine. Some general advice:

Although I'm a little unclear about the goals behind using metro or uzi in your patch, I would generally stick with metro until you know why you would want to use uzi (although a 1ms metro value is faster than practical.) Metro is not staying on because you hit it with a stop message from your "a feature to stop initial bangs" section. As an aside, you may want to learn the onebang object.

Your reliance on send and receive reduces reliability, because order of s/r are not well controlled. It also reduces readability for people unfamiliar with your patch. Send & receive also have a (very slight) performance penalty over using patch cords. Sending redundant messages (e.g. global_cancel_ZERO and global_cancel_BANG) strikes me as bad style. I would send one bang message, global_cancel, and turn it into whatever was needed at the receiving end.

Although I'm a little unclear about the goals behind using metro or uzi in your patch, I would generally stick with metro until you know why you would want to use uzi  (although a 1ms metro value is faster than practical.) Metro is not staying on because you hit it with a stop message from your "a feature to stop initial bangs" section. As an aside, you may want to learn the onebang object.

Your reliance on send and receive reduces reliability, because order of s/r are not well controlled. It also reduces readability for people unfamiliar with your patch. Send & receive also have a (very slight) performance penalty over using patch cords. Sending redundant messages (e.g. global_cancel_ZERO and global_cancel_BANG) strikes me as bad style. I would send one bang message, global_cancel, and turn it into whatever was needed at the receiving end.


ok. I will explore [onebang] more. I was starting to suspect the s/r were not organized too well. As is, I can have one patch open with the same s/r as another and cause problems.

I do very much enjoy giving primitive within the name or what should be passing through the s/r. Thus I dont connect and send something incorrectly. At any rate, at a human's speed of analyzing s/r, they seem lovely. Shame they are actually bloody useless en masses. Is there a suggested max?

Lastly, if you follow the logic, the stop message should not hit the metro until the counter is at 5.

ok. I will explore [onebang] more.  I was starting to suspect the s/r were not organized too well. As is, I can have one patch open with the same s/r as another and cause problems. 

I do very much enjoy giving primitive within the name or what should be passing through the s/r.  Thus I dont connect and send something incorrectly. At any rate, at a human's speed of analyzing s/r, they seem lovely. Shame they are actually bloody useless en masses.  Is there a suggested max?

If you use #0 as the prefix to any name, it will allocate a number unique to that patcher instance, for example #0_myName might resolve to 1234_myName.

Send & Receive are useful in their place, but you have to keep in mind that the order through them is not defined. In a large patch you have to be careful of this.

You're correct that the counter is counting to 5 very quickly before it stops. I should have hung a print object on the output before I commented. Could you re-state what you think the problem is?

I found [gate] (basically like onebang) to reduce this and I was trying to basically selecting a float again (located else where in the patch). The problems have been resolved!

I think most of my logic is trying to force a greater continuum (with the assumption that [t b b] will really give enough time for the first bang to take effect before the 2nd bang goes off). I know it is risky but I try to test often to see that it is holding true. Mostly I am trying to keep track of my primitives in order because s/r do not care what is traveling through them (but I do!).

I will explore # in more depth. Thanks again for the direction!

I found [gate] (basically like onebang) to reduce this and I was trying to basically selecting a float again (located else where in the patch).  The problems have been resolved!

I think most of my logic is trying to force a greater continuum (with the assumption that [t b b] will really give enough time for the first bang to take effect before the 2nd bang goes off).  I know it is risky but I try to test often to see that it is holding true.  Mostly I am trying to keep track of my primitives in order because s/r do not care what is traveling through them (but I do!).

I will explore # in more depth.  Thanks again for the direction!


[metro] to [sel] not working so well