On Fri, 25 Jun 2010, patko wrote:
I'd like to use also this thread to expose another problem, it's about to get how [#for 1 3 1] works, it often outputs this message: dimension mismatch: from:Dim[] to:Dim[1] step:Dim[]
This is because GridFlow distinguishes a float (or int) from a list (or vector), and it's not only a jMax legacy thing, it's also part of the logical progression from scalar to vector and vector to matrix and so on to higher dimensions. PureData's habit of not distinguishing "float $1" and "list $1" works against GridFlow here.
[#for] has a scalar behaviour as [#for 1 3 1], and a vector behaviour as [#for (1) (3) (1)], but it's really the same class, the same inlets, and it doesn't auto-cast from scalars to 1-element vectors nor vice versa. So you may have to introduce messageboxes saying "list $1" or "float $1" sometimes... or [#redim] for content already in grid form.
1-element vectors exist so that there is something that is to 2-element vectors as 2-elements are to 3-element vectors. It's a matter of logical progression (induction over natural numbers). No matter how weird it may be, it's less weird than if it weren't like that, really.
The object works good when I try manually, but when it's done with triggers,
That's one case where you have to pick [t f] vs [t l] or [t a]. It's in part because [t] converts a float-message whether you like it or not, and GridFlow is sensitive to it.
You also have an execution-order problem as there is a fanout instead of a [t l l] on the left.
I do understand that there is a GRID_FLOW time as it's explained in [#finished] help file but the lack of pratical examples really slows the understanding of a "good use" of gridflow class objects.
You problem here has nothing to do with the GRID_FLOW transmission phases. It happens when you try to use a same source grid in what becomes eventually two inlets of the same object. For example, if you want to divide a grid by its own sum to normalise it, you have to use [#t] to buffer the left-grid while you are still computing the sum of it to feed in the right-inlet of the division.
You never need [#t] for the simple case of [#dim] because [#dim] is done with its job before the input grid contents are even sent. It's also like that with [#type].
The "GRID_FLOW time" would deserve more writing. Too much hesitation between documenting it and "fixing it", I suppose. This has to do with the fixes either introducing new problems of their own, or removing occasionally useful features that are exclusive to GridFlow...
hartelijk
hein ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801