Trying to fully fathom [clone]...

I am working on a granulator patch which uses many [clone]s, and four possible samples to choose from/mix between (ie, 25% chance of grain A, 75% chance of grain B ). I think Carl Stone might already do something like this, but he uses Max, so, totally different.

Anyway. I'm using a [t b b b b...] to, first, a [next newName $1( to choose the sample, then a bunch of [this rate $1(, where the "THIS" messages are attributes (rate, filter, whatever).

When I'm mixing my grains (ie, anything other than 100% of grain A), the "THIS" attributes sometimes get applied to the wrong sample. That is, if I know grain A should be slow and heavily filtered, and grain B is fast and bright, I hear some A's fast and bright.

I thought using a [t b b b b] would ensure that the the same sample chosen by [next( would receive all of the appropriate [this( but... no?

@Load074 Yes, [t b b] should ensure that messages are sent in the correct order.... the right-most bang first. And the "next" message would then have to be completed to the end of the chain of the selected cloned abstraction before the "this" message would be sent.
If you could post enough of the patch to demonstrate the problem that would be useful.
David.

not to get all High School Yearbook, but... "sorry so sloppy."

The cloned part is "changeGrain." My front-end patch has four of the "quadSamp," each one of them relating to a specific sample. They get triggered quickly (as fast as 5 ms), so there can be a time where four different samples are triggered within 5ms of each other.

quadSamp is also where I can set, ie, the rate or the filter to be different for Sample A than for Sample B.
quadSamp:

quadSamp.pd

And so the problem is that, for instance, Sample A is Duran Duran's "Fame" but filtered and slowed down - no problem - but when I occasionally trigger Sample B (David Bowie's "Fame") I hear bits of Sample A at normal speed and unfiltered (following Bowie's parameters).

changeGrain (that which is cloned):

changeGrain~.pd
This might not make sense, and my patches might be too personal/messy for anyone to want to take a look...

@Load074 That might be why I have never used "this" and "next" for clone messaging.

It's probably a good time to connect [print] to the outlet of quadSamp.pd and [print $1] to the inlet of changeGrain.pd ...... to see in the console what the messages are, where the messages are actually arriving (which clone), and in what order.

But you only have one [next.....( message so it should be good.
But is the [next newName $1 $2( message correct....... you do not have a [t f f f] on the "fileDur" inlet of quadSamp.pd.
Or is the [t b b b b b] being double triggered (or more) on its inlet?
David.

wait wait wait... are you telling me I don't have to use [this( and [next( !?!?! How else does one do it? Oh... can I keep a counter in my main patch, and send messages to successive [clone] 's? So then I'd know I was on #47, and I'd send all my details to #47... is that how that works?

Brilliant.

Hold on, I'll be back in a few hours....