geddonn

Hi guys, I'm having trouble with a patch I'm working on as part of a megapatch.

The basic idea is to generate a list of numbers for a coll to send through to some multisliders - I'm using the jit.nois + plur combination mentioned in this tutorial (

https://cycling74.com/tutorials/noise-tutorial-1-riding-tandem-with-the-random/)

The problem I'm encountering is that every time I send a bang manually from the top by clicking I get the right behaviour -- 30 lists in the coll to choose from.

Every time I get the patch to automatically bang itself the coll only seems to get 1 list to choose from.

The patch is bellow, I'd be very appreciative to anyone who can help/debug.

Hi guys, I'm having trouble with a patch I'm working on as part of a megapatch. 

The basic idea is to generate a list of numbers for a coll to send through to some multisliders - I'm using the jit.nois + plur combination mentioned in this tutorial (https://cycling74.com/tutorials/noise-tutorial-1-riding-tandem-with-the-random/)

The problem I'm encountering is that every time I send a bang manually from the top by clicking I get the right behaviour -- 30 lists in the coll to choose from.
Every time I get the patch to automatically bang itself the coll only seems to get 1 list to choose from. 

The patch is bellow, I'd be very appreciative to anyone who can help/debug. 

misbehaving-coll-patch-inside

I think a [deferlow] between the [r rejig] and the [t b b b b] in the upper left of your patch should get you there.

Aha! That fixed it. I wonder why that was necessary?

I was wondering that too. I manually did a bang into the [send rejig] just moments after the counter did it, and it worked, whereas coming from the counter...nope. Can't figure out why the two would be different...anyway, in cases like this, often a well-placed [deferlow] will help out, as mentioned.

One other idea, not that it's necessary per se, but you could also just use [jit.matrix] objects to hold your lists of generated data rather than [coll]. Then you can access by [jit.submatrix] or [jit.spill] to get the lists. Might be faster than writing to and and accessing [coll] objects, not sure.

I was wondering that too. I manually did a bang into the [send rejig] just moments after the counter did it, and it worked, whereas coming from the counter...nope. Can't figure out why the two would be different...anyway, in cases like this, often a well-placed [deferlow] will help out, as mentioned. 

One other idea, not that it's necessary per se, but you could also just use [jit.matrix] objects to hold your lists of generated data rather than [coll]. Then you can access by [jit.submatrix] or [jit.spill] to get the lists. Might be faster than writing to and and accessing [coll] objects, not sure.


The difference is that after the deferlow it is not driven from an interrupt. This fixes many problems of this sort. I could not tell you why it's needed here, though.

I just wonder why Max doesn't give a warning/error message if defer or deferlow is needed.

For example, SuperCollider does it. Why not Max?

I just wonder why Max doesn't give a warning/error message if defer or deferlow is needed.
For example, SuperCollider does it. Why not Max?


Misbehaving coll - patch inside