[Gridflow-dev] [PD] [#store] grid index

[Mathieu Bouchard]

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