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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
