[Gridflow-dev] yesterday's questions

[Mathieu Bouchard]

Sorry for not answering questions yesterday on the chat. I was first at a
job and when I came back it was time for a family supper that ended after
midnight, so...

On the #dataflow chat, Alexandre Castonguay and Stéphanie Brodeur and
Normand Fisher said:

<alx1> les screenshots, je suggere de les faire une fois les exemples
ajustes pour 0.7.8

If we're talking pd_examples/*.pd, I haven't adjusted them, for two
reasons:

  1. GridFlow 0.7.8 is supposed to be backwards-compatible, and I wanted
     something to test that feature against.

  2. GridFlow 0.7.8 is supposed to include an automatic converter, akin
     to the jmax2pd converter that has been bundled for a while. I haven't
     written it yet.

<alx1> matju: your text about pd as a language and its object model should
be featured as part of the introduction to the docs? 

I wrote it only for the workshop, so I haven't considered this idea. Do
you think any changes should be made in it? Do you think it really belongs
in introduction.xml, or architecture.xml (which is the current followup of
the introduction), or should an additional chapter be added in that manual
between those two?

<alx1> matju: I can remove references to BFObject since it that part was
there for c++/jmax compatibility?

As you figured out later, BFObject is common to all bridges, including
Ruby-for-Pd (aka gridflow.pd-linux). When you create any GF object in Pd,
a BFObject is created (which is a true pd object) and it is then linked to
a FObject on the Ruby side.

<alx1> matju: I am editing internals.html

Please don't. My last serious work on GF was to change a lot of internals
and my plan for the next weeks is to get through the rest of that work. I
will have to basically completely rewrite internals.*ml myself, which
anyways never was really written... (i mean it currently doesn't have much
useful contents)

<steph_2> je ne sais pas si je devrais mettre le "#" devant chaque nom
d'icons qui contient un #
<normand> Je pense que oui.  Je crois que le # agit un peu comme le ~ de
pure-data pour le signal vidéo.
<normand> ou si non, il sert à identifier qu'il s'agit d'un objet gf

Exactly. Some subsystems of Pd use a suffix, and some a prefix, to
indicate their own specific category of externals. Most seem to prefer
prefixes; the tilde for dsp is an exception.

In GF, @ is the old grid prefix, # is the new grid prefix, and some
classes don't have any prefixes because although bundled with GF, they're
not dealing with grids at all (for example, [fps]). What is changing is
that the @ prefix should disappear eventually.

<steph_2> t'as raison, mais je me demandais seulement pour le nom quand je
sauvegarde l'objet

I heard of a problem with using # in URLs. I have not looked at it yet. I
completely forgot to consider that fact when thinking about switching to
that prefix. A solution may involve "%23", the URL notation for inserting
an otherwise-special character. %23 is the # sign, and you may have
already seen %2f (slash) and %3f (questionmark) in URL's in the past.

In UNIX commands, # is also a reserved character sometimes. If a problem
occurs, putting a backslash in front of it tells that the # should be
considered non-special. You may have seen that, in the shell, the tab key
inserts backslashes before any special chars including @ and #.

<steph_2> normand: merci, je suis en train de renommer les objets

Just a quick note: some #-objects don't work like the same-named
@-objects. For example,

  [@convolve * + 0 (something)]

is now just (for simplicity)

  [#convolve (something)]

and that may have to be kept in mind while making the changes to the docs.

<steph_2> matju: est-ce que je devrais placer les nouveaux icons "flow
objects" pour le cvs dans ...doc/images ou est-ce que je devrais creer un
nouveau dossier?
<steph_2> matju: "flow classes" je m'excuse

je crois qu'Alex a dit qu'il aimait mieux un nouveau dossier. Vu que
presque tous les noms de fichiers changent, je crois qu'on peut aussi bien
faire un dossier avec, mais je ne saurais pas quel nom donner... dans un
certain sens, ça m'est égal... ça pourrait être flow_classes/, mais les
autres libs de PureData n'ont pas de tel sous-dossier.

(en passant, Bonne Année!)

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju