----- "Mathieu Bouchard" matju@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
On Sat, 26 Jun 2010, patko wrote:
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?
We will have to rediscuss this, here or on the #dataflow channel, to make sure I know what you are thinking about. I'm not super sure because you wrote that just below the paragraph about the GRID_FLOW {} sections, instead of above it...
About float vs list, well, it isn't that terrible, we don't need a separate version of PureData, I simply think that if anyone wants to do anything whatsoever about it, first PureData should be fixed related to itself, as you can get "no method for 'float" or "no method for 'list'", whichever it was, by using [t f] or [t l] on right inlets of absolutely ordinary objects of vanilla, and AFAIR, it's not documented anywhere.
I'm much more interested in fixing the hole of GRID_FLOW, making [#t] as irrelevant as possible. It's an annoyance, and even more important, a shame, as it's hard to explain the problem and especially hard to justify its existence, and it's really GridFlow's problem and no-one else's.
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.
Ouais, mais... "hartelijk" = "chaud", alors que l'italien "ciao" qui s'écrit "tschau" en allemand s'est retrouvé prononcé comme "t'chaud" par certains français qui l'ont lu et savaient pas le prononcer, et c'est semble-t-il resté. alors, je me demande, y a-t-il un lien ? ;-))))
t'chaud !
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Mathieu Bouchard -
patko