Hello everybody,
It took a while to set up, but we're now running a fund-raising campaign for GridFlow documentation efforts.
GridFlow is a multidimensional dataflow processing library intended for interactive video/sound art. You can use it within PureData (http://puredata.info , an Open Source alternative to Max/MSP) or Ruby itself, on Linux, OSX and Windows.
This fundraising campaign aims to enable Mathieu Bouchard, the creator of GridFlow, and associates if relevant, to write a workshop-style book and better documentation for GridFlow classes.
We believe GridFlow is extremely powerful, in that it allows a user to create a Puredata object without having to learn C, in a language designed for creative productivity.
Using GridFlow, it is possible to write a functional PD object in a couple of lines of clearly understandable Ruby, a programming language extremely well suited to beginners, but powerful enough for programming experts.
However, currently, the documentation is not thorough enough to help people get started as well as it could.
Imagine the power of your own Puredata objects without the C/C++ situps, and donate to help us achieve a textbook for newcomers to both puredata and interactive art programming!
Matthieu Bouchard does not currently have a way to handle online donations, so I will be managing donations through a secure PayPal account.
To learn more about GridFlow, why it is the bee's knees, and how to donate, see here:
http://www.davidcasal.com/gridflow.html
Thanks for reading,
David
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
I support all documentation efforts, of course, and GridFlow does sound
quite useful, but I have to say, you don't need C, C++, or GridFlow to
write your own Pd objects. You can write Pd objects in Pd itself.
Looking forward to those docs, so we can sway more Jitter users to the
open-source side of Max.
.hc
On Sep 29, 2005, at 5:34 PM, David Plans Casal wrote:
Hello everybody,
It took a while to set up, but we're now running a fund-raising
campaign for GridFlow documentation efforts.GridFlow is a multidimensional dataflow processing library intended
for interactive video/sound art. You can use it within PureData
(http://puredata.info , an Open Source alternative to Max/MSP) or Ruby
itself, on Linux, OSX and Windows.This fundraising campaign aims to enable Mathieu Bouchard, the creator
of GridFlow, and associates if relevant, to write a workshop-style
book and better documentation for GridFlow classes.We believe GridFlow is extremely powerful, in that it allows a user to
create a Puredata object without having to learn C, in a language
designed for creative productivity.Using GridFlow, it is possible to write a functional PD object in a
couple of lines of clearly understandable Ruby, a programming language
extremely well suited to beginners, but powerful enough for
programming experts.However, currently, the documentation is not thorough enough to help
people get started as well as it could.Imagine the power of your own Puredata objects without the C/C++
situps, and donate to help us achieve a textbook for newcomers to both
puredata and interactive art programming!Matthieu Bouchard does not currently have a way to handle online
donations, so I will be managing donations through a secure PayPal
account.To learn more about GridFlow, why it is the bee's knees, and how to
donate, see here:http://www.davidcasal.com/gridflow.html
Thanks for reading,
David
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
On Sun, 2 Oct 2005, Hans-Christoph Steiner wrote:
I support all documentation efforts, of course, and GridFlow does sound quite useful, but I have to say, you don't need C, C++, or GridFlow to write your own Pd objects. You can write Pd objects in Pd itself.
But languages are not created equal and that's (one of the reasons) why there are so many of them.
If PureData was really easy to use all of the time I wouldn't have been tempted to code so much of GridFlow in Ruby instead of PureData.
I'd like to tell people to code their object-classes in PureData itself
(i.e. as abstractions) all of the time, but I wouldn't feel that honest.
I'll be happier with PureData once the abstractions have access to the
same abilities as externals. Currently, abstractions are second-class
citizens in the PureData world.
Looking forward to those docs, so we can sway more Jitter users to the open-source side of Max.
David is talking about the Ruby side of GridFlow, which has no equivalent in Jitter.
Jitter is more like the rest of GridFlow coupled with something like GEM-Geos or 3DP.
Recent versions of MAX can handle Java and JavaScript externals straight out of the box. You can also get C++ and Python support using Flext and Pyext. It would be possible to adapt gridflow/bridge/puredata.c so that it also compiles as a MAX external (though I dunno who would do that, as I can't even get someone to work on the OSX port of GF)
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hey,
On 2 Oct 2005, at 21:50, Hans-Christoph Steiner wrote:
I support all documentation efforts, of course, and GridFlow does sound quite useful, but I have to say, you don't need C, C++, or GridFlow to write your own Pd objects. You can write Pd objects in Pd itself.
Quite true of course; what I should have said is that writing in Ruby is easier than C, for objects that would be difficult/impossible to write in PD itself, such as those using external libraries, etc.
It is also a uniquely accessible way to teach OO design with regards to Puredata externals, even if just to prototype (and then redo in PD itself, or a C external for speed, whatever). The point is, if we can explain the function of an external by writing it, such as:
#this object is a flow object subclassed from GridFlow's FObject, it will be called random_choice, and will have 1 inlet and 1 outlet GridFlow::FObject.subclass("random_choice",1,1) { # we take whatever comes in, and choose either 0 or 1 def _0_bang send_out 0, [0,1][rand.round] end }
Being able to write that in a user's home directory's .gridflow_startup, load from ruby console on a running instance of PD, and call the object with [random_choice] does a great deal to get an 'Oh!' moment...
Looking forward to those docs, so we can sway more Jitter users to the open-source side of Max.
Hey, same here! We're going to fundraise locally through DJ/VJ events to raise awareness of alternatives to Jitter and Max, and hopefully we'll end up with at the very least, more approachable docs for newcomers.
Cheers,
David
Hey all,
I just caught this thread now.
In terms of grid-flow docs how does the aim of this project relate to the early efforts of:
PDDP Workshop/Tutorial Standard
(both have wiki pages on puredata.info)
Also the work of Darsha and Stef @ artengine on gridflow tutorials...
Just checking for a "fork" or more collaboration...
b.
David Plans Casal wrote:
Hey,
On 2 Oct 2005, at 21:50, Hans-Christoph Steiner wrote:
I support all documentation efforts, of course, and GridFlow does sound quite useful, but I have to say, you don't need C, C++, or GridFlow to write your own Pd objects. You can write Pd objects in Pd itself.
Quite true of course; what I should have said is that writing in Ruby is easier than C, for objects that would be difficult/impossible to write in PD itself, such as those using external libraries, etc.
It is also a uniquely accessible way to teach OO design with regards to Puredata externals, even if just to prototype (and then redo in PD itself, or a C external for speed, whatever). The point is, if we can explain the function of an external by writing it, such as:
#this object is a flow object subclassed from GridFlow's FObject, it will be called random_choice, and will have 1 inlet and 1 outlet GridFlow::FObject.subclass("random_choice",1,1) { # we take whatever comes in, and choose either 0 or 1 def _0_bang send_out 0, [0,1][rand.round] end }
Being able to write that in a user's home directory's .gridflow_startup, load from ruby console on a running instance of PD, and call the object with [random_choice] does a great deal to get an 'Oh!' moment...
Looking forward to those docs, so we can sway more Jitter users to the open-source side of Max.
Hey, same here! We're going to fundraise locally through DJ/VJ events to raise awareness of alternatives to Jitter and Max, and hopefully we'll end up with at the very least, more approachable docs for newcomers.
Cheers,
David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 10 Oct 2005, B. Bogart wrote:
In terms of grid-flow docs how does the aim of this project relate to the early efforts of: PDDP Workshop/Tutorial Standard
They don't. Any standard on how to make *.pd helpfiles and tutorials fails to provide any clue on how to make documentation on how to write externals for PureData. What David requests is documentation on how to write externals in Ruby.
Also the work of Darsha and Stef @ artengine on gridflow tutorials...
Darsha and Stéphanie never ever used Ruby and so are not qualified to write documentation about writing externals in Ruby.
Also, AFAIK, their contracts have expired several months ago.
Just checking for a "fork" or more collaboration...
I've explained the forking of PureData on pd-dev@iem.at. It doesn't have anything to do with GridFlow. What makes you believe so?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Ah!
I misunderstood the purpose of the documentation.
This is an interesting idea as I have been thinking about a workshop @ interaccess on the development of PD/Max externals... Please keep me posted on how this develops. Who is the intended audience?
Mathieu, I'm not talking about PD forking, but the isolation of documentation efforts. your off the hook! ;)
.b.
Mathieu Bouchard wrote:
On Mon, 10 Oct 2005, B. Bogart wrote:
In terms of grid-flow docs how does the aim of this project relate to the early efforts of: PDDP Workshop/Tutorial Standard
They don't. Any standard on how to make *.pd helpfiles and tutorials fails to provide any clue on how to make documentation on how to write externals for PureData. What David requests is documentation on how to write externals in Ruby.
Also the work of Darsha and Stef @ artengine on gridflow tutorials...
Darsha and Stéphanie never ever used Ruby and so are not qualified to write documentation about writing externals in Ruby.
Also, AFAIK, their contracts have expired several months ago.
Just checking for a "fork" or more collaboration...
I've explained the forking of PureData on pd-dev@iem.at. It doesn't have anything to do with GridFlow. What makes you believe so?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On 10 Oct 2005, at 17:12, B. Bogart wrote:
I misunderstood the purpose of the documentation.
No worries!
This is an interesting idea as I have been thinking about a workshop @ interaccess on the development of PD/Max externals... Please keep me posted on how this develops. Who is the intended audience?
Intended audience where I live : postgraduate (and under, if I can help it) digital practices students.
However. I would -really- like to find funding (looking at local government funding here for it) to expand this to general Ruby/Programming/Puredata set of lectures, in practical workshop style but with a loose, well-documented curriculum. I'd like this because it could apply to more than just 1, technorati audience, namely FE, art colleges, 1rst year music students, whatever.
Mathieu, I'm not talking about PD forking, but the isolation of documentation efforts. your off the hook! ;)
Heh. Can't blame people for get itchy around the word fork, huh.
Ben, get in touch and let's talk further about uniting efforts for this? I'd love to collaborate on your workshop @ interaccess.
Cheers,
David
On 10 Oct 2005, at 17:28, Mathieu Bouchard wrote:
externals for PureData. What David requests is documentation on how to write externals in Ruby.
That's correct, essentially, although I would love to see enough momentum to get GridFlow at large better documented.
My aim is to be able to provide students (everywhere, not just my little corner) with a well-documented way to script externals for PD in Ruby.
Why? Well, while scheme(guile) and python (though the -amazing- py/pyext) are there, Ruby is a really fun, creative language through which to learn programming. Teaching it is also immense fun.
So, I was hoping people out there would agree (or wish to see the potential behind it), and help in terms of creating a small pot of money to finance the effort and Matthieu's time, not just to document, but to foster a stable platform behind it, like a good OSX port, for example.
Just checking for a "fork" or more collaboration...
I've explained the forking of PureData on pd-dev@iem.at. It doesn't have anything to do with GridFlow. What makes you believe so?
As explained, this has to do with pedagogic efforts and writing externals in Ruby, through GridFlow.
The are 0 associations with GridFlow/DesireData and anything fork-like happening in dev.
Cheers,
David
-
B. Bogart -
David Plans Casal -
Hans-Christoph Steiner -
Mathieu Bouchard