[Gridflow-dev] feature requests: @fold1, @foldr, @foldr1, @scan1. @scanr, @scanr1, unary ignore

Tom Schouten doelie at zzz.kotnet.org
Fri Sep 17 04:10:52 EDT 2004

On Fri, Sep 17, 2004 at 03:42:28AM -0400, Mathieu Bouchard wrote:
> On Thu, 9 Sep 2004, Tom Schouten wrote:
> > > You just need to add a Feature.new {} block in ./configure. Maybe
> > > I should make a directory called optional/ for modules like this,
> > > because that doesn't belong in base/ for sure, and it doesn't belong
> > > in format/ because that dir is for [#in]/[#out] plugins.
> > yeah, by all means no hard dependencies. i'm not done breaking everything yet :)
> > maybe it's best i look at the list import/export objects as an example?
> Actually the import objects maybe aren't so good at it because in the last
> two years the grid inlet interface has been able to accept 'float' and
> 'list' messages and convert them on the fly, including lists that contain
> dimension and numbertype specifiers. So most of the conversion meat has
> been shifted to grid.c (and maybe main.c).
> And then this all occurs on the Ruby side of the world, so
> bridge/puredata.c does another bunch of conversions, which is slower, and
> then you can't call Pd functions directly from gridflow.so (which is
> everything except bridge/puredata.c) because gridflow.so is not supposed
> to depend on Pd.

i'm not sure passing stuff to gridflow through a pd list is such a good
idea, if this is what you mean..

let's switch to "shut up and implement" mode.

if i give you a couple of C functions to call from libpdp. what would
you need? just give me the C prototypes and i will write the code.

More information about the Gridflow-dev mailing list