[PD] [#store] grid index

[patko]

----- "Mathieu Bouchard" <matju at artengine.ca> a écrit :

> 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.


 I've just replaced [t b a] by [t b f] in my [list length] example
and it seem to work good, so simple in fact...

> 
> 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...
> 


 Gridflow has to reach a kind of complexity level that makes it very sensitive,
from what I understand. Wouldn't it be possible to make a PureData version
that is managing data correctly in regard of grids?

 Or just including an error message that shows
 a link to a doc where we can read about it might be usefull

> > hartelijk
> 
> hein ?
>

 c'est du néerlandais, c'est marrant comme language, je n'y vois rien qui ressemble au latin,
du coup chaque nouveau mot sonne comme un peu comme un nouveau mode d'éternuement je trouve.
>   _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

-- 
Patrice Colet