One area that patcher languages really do well in is rapid prototyping.
With Pd you can whip out a working prototype really quickly, but they
generally it'll be really whack and hard to follow or modify. One
thing patcher languages are not so good at is managing complexity.
Large programs seem to get crazy and unmanagable relatively easily.
This leads me to an interesting paradox about programming that has
stuck with me since 1993 when I was taking Computer Science in college.
Some famous computer scientist (I forget exactly who) said "you have
to write the program in order to know how to write the program."
I have found that this actually makes a lot of sense, so when programming with Pd, first I try to whip out a working prototype, then start again from scratch and build it the way it should be done, with things nicely modularized into objects (abstractions generally).
It would be great if we could gather this info into a common page.
There are a massive amount of books about programming techniques for
procedural and object oriented languages, but there is basically
nothing about programming techniques for patcher languages, even though
they have been around for 20+ years and are decently widespread in use.
.hc
On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:
This leads me to an interesting paradox about programming that has stuck with me since 1993 when I was taking Computer Science in college. Some famous computer scientist (I forget exactly who) said "you have to write the program in order to know how to write the program." I have found that this actually makes a lot of sense, so when programming with Pd, first I try to whip out a working prototype, then start again from scratch and build it the way it should be done, with things nicely modularized into objects (abstractions generally).
In the "Extreme Programming" (X.P.) methodology, this is considered perfectly normal, and is called a "spike". Then you have the choice of rewriting it or modifying it. In X.P. there is an emphasis on modifying code. It is common sense that doing things that way leads to spaghetti code. However, X.P. is advocating aggressive redesign as part of the process of modification of code, and is encouraging use of automated test systems as a protection net (you see, reluctancy to do aggressive redesign is usually motivated by avoidance of new bugs).
There are a massive amount of books about programming techniques for procedural and object oriented languages, but there is basically nothing about programming techniques for patcher languages, even though they have been around for 20+ years and are decently widespread in use.
Among other things, I think it may be because patcher languages (aka visual dataflow languages) are different enough from each other that techniques that may apply to Max/Pd aren't reusable elsewhere, and so on. Also, it's normally a subsegment of the programmer population that seems the most concerned/experienced with complexity management, but most users of those programming environments are nonprogrammers.
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:
There are a massive amount of books about programming techniques for procedural and object oriented languages, but there is basically nothing about programming techniques for patcher languages, even though they have been around for 20+ years and are decently widespread in use.
Among other things, I think it may be because patcher languages (aka visual dataflow languages) are different enough from each other that techniques that may apply to Max/Pd aren't reusable elsewhere, and so on. Also, it's normally a subsegment of the programmer population that seems the most concerned/experienced with complexity management, but most users of those programming environments are nonprogrammers.
Recently I came to think of another way to find "good practices", and that is, to compare how users of different experience levels would solve a problem. If I look at my very early patches like the PDX7 (a mess!) and then at some of my recent stuff like the rradical thingies, there could be a lot to learn in regard to, what the years of Pd usage in between have told me. The differences probably are, what makes up good practice.
Like in my newer patches, there still are messy things, but those are in "unimportant" areas. Generally my stuff now is much more organized and modularized, while the early stuff now is very hard to even understand ("What did this number box do, and where does this send lead to?")
ciao
Frank Barknecht _ ______footils.org__
On Sunday 21 March 2004 16:35, Frank Barknecht wrote:
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:
There are a massive amount of books about programming techniques for procedural and object oriented languages, but there is basically nothing about programming techniques for patcher languages, even though they have been around for 20+ years and are decently widespread in use.
Guys, I've been following this interesting discussion off and on, and forgive
me if this point has already been brought up or you disagree: Graphical
programing languages don't scale well to large projects. They're strength is
in getting highly customized things done quickly and interactively. From what
I've seen however, they are generally not the right tool for creating large,
general purpose, modularized applications.
Years ago, my company needed to develop an PC spectrum analyzer application for the cable extrusion industry (if their are preriodic dimensional fluctuations in coax cable, the reinforced reflections will create a marked attenuation at a certain frequency). Rather than doing this in C, we contracted a Labview consultant to do the whole thing in Labview. Now, this was a small to medium size general purpose application for which we provided a set of detailed specifcations.
The result, although it worked great, was a big mess, and hard to maintain and modify. Looking at the Labview "patches", it became clear to us that we were trying to stretch a graphical language far beyond its purpose. The next iteration of the product used Labview's C library instead, and was by far easier to maintain.
I think that graphical "programming languages" are great tools for the end user, and not the general purpose application developer.
Well, I just wanted to share that story, and I do realize that it is somewhat tangential.
Larry Troxler
On Sunday, Mar 21, 2004, at 17:08 America/New_York, Larry Troxler wrote:
On Sunday 21 March 2004 16:35, Frank Barknecht wrote:
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:
There are a massive amount of books about programming techniques for procedural and object oriented languages, but there is basically nothing about programming techniques for patcher languages, even though they have been around for 20+ years and are decently widespread in use.
Guys, I've been following this interesting discussion off and on, and forgive me if this point has already been brought up or you disagree: Graphical programing languages don't scale well to large projects. They're strength is in getting highly customized things done quickly and interactively. From what I've seen however, they are generally not the right tool for creating large, general purpose, modularized applications.
Years ago, my company needed to develop an PC spectrum analyzer application for the cable extrusion industry (if their are preriodic dimensional fluctuations in coax cable, the reinforced reflections will create a marked attenuation at a certain frequency). Rather than doing this in C, we contracted a Labview consultant to do the whole thing in Labview. Now, this was a small to medium size general purpose application for which we provided a set of detailed specifcations.
The result, although it worked great, was a big mess, and hard to maintain and modify. Looking at the Labview "patches", it became clear to us that we were trying to stretch a graphical language far beyond its purpose. The next iteration of the product used Labview's C library instead, and was by far easier to maintain.
I think that graphical "programming languages" are great tools for the end user, and not the general purpose application developer.
Well, I just wanted to share that story, and I do realize that it is somewhat tangential.
I agree that current practice with patcher programming languages makes
it difficult to maintain larger scale apps, but I not ready to give up
and say that its an inherent problem with patcher languages.
Procedural programming was established at least 20 years before patcher
languages, and there has been many orders of magnitude more work done
on figuring out how to make manageable, large-scale software projects
in C than in Max/Pd. So there exists a huge body of knowledge about
how to make C programs manageable.
So I think that with efforts such as this one, we can begin to figure out how to manage large scale patcher projects. I concede that patcher languages will probably not be as good as procedural or object-oriented languages at large scale projects, but I think things can get a lot better.
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So I think that with efforts such as this one, we can begin to figure out how to manage large scale patcher projects. I concede that patcher languages will probably not be as good as procedural or object-oriented languages at large scale projects, but I think things can get a lot better.
Let me add, that patcher systems make very good "glue" environments Take something like VASP: It's a huge, C++ library, which in the end is glued together by Pd. So Pd lets developers more or less ignore GUI stuff or DAC/ADC interfacing, because that's what Pd does for them.
This makes Pd similar to scripting languages - although Larry will insist that Guile is better at this for sure. ;)
ciao
Frank Barknecht _ ______footils.org__
Let me add, that patcher systems make very good "glue" environments Take something like VASP: It's a huge, C++ library, which in the end is glued together by Pd. So Pd lets developers more or less ignore GUI stuff or DAC/ADC interfacing, because that's what Pd does for them.
Well, i have done a number of projects using VASP lately and i have come to the conclusion that the patcher-oriented programming is rather a pain for these kind of things. In fact, the next generation of VASP will be a C++ library alternatively steered by scripting (Python or Ruby) and external objects.
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Well, i have done a number of projects using VASP lately and i have come to the conclusion that the patcher-oriented programming is rather a pain for these kind of things. In fact, the next generation of VASP will be a C++ library alternatively steered by scripting (Python or Ruby) and external objects.
I agree, that patcher can be a PITA, and especially a pain in the mouse controlling hand. Still building a GUI is generally easier to do in Pd than in a programming language, and it especially is so for users who don't know traditional programming languages in the first place.
ciao
Frank Barknecht _ ______footils.org__
Well, i have done a number of projects using VASP lately and i have come to the conclusion that the patcher-oriented programming is rather a pain for these kind of things.
well, I've not used VASP very much but I may be it's a bit more procedural, it 's like some openGL bindings (gem, dips). it ends up as a series of steps ...
... gerard
Hi all:
Has anyone here tried running Pure Data on the VIA processors, as found on the Mini-ITX or Nano-ITX motherboards? The size of these motherboards is very appealing (the Nano-ITX is only 12x12 cm), but I have read some pretty underwhelming reports of performance on these processors.
Not sure how Linux support stands, and I am also not sure if there are ALSA drivers for the built-in soundchips. It would also remain to be seen if the small cache size is a problem - it seems like cache size is critical to performance with MAX/MSP.
Anyway, if anyone has tried PD on a VIA system, it would be interesting to hear your results. An x86 computer that fits in a large stompbox would be pretty cool. Even if the performance isn't stellar, it might be useable as a programmable effects unit that far surpasses any commercial unit in a similar price range, but with more durability than your average laptop.
Sean Costello
Hello Sean, We used some mini-ITX VIA mother board : you could here some audio stream here : http://apo33.org/radio/ It uses a proc of 1Ghz 512Mo, it works quite well under linux mandrake and we use PD on this streams... So you couldn't run patch asking a lot of cpu but you could work at the end! Also on the last generation of mini-ITX you don't have anymore this problem of cache size, Epia resolved it. In the other way the onboard sound card works but it's better to put a pci or usb card (like we used some sound blaster live or M-audio quattro), sound quality will be better!! you could find also some of our home computer with this motherboard : http://cybersapiens.org/article.php3?id_article=28 http://cybersapiens.org/article.php3?id_article=13 http://cybersapiens.org/IMG/jpg/metalatrous.jpg http://cybersapiens.org/article.php3?id_article=24 http://cybersapiens.org/article.php3?id_article=23
Also to save some cpu under linux, we use PWM which is an X desktop really light! the nano one's is not available at the moment, maybe soon...
best
juto
Has anyone here tried running Pure Data on the VIA processors, as found on the Mini-ITX or Nano-ITX motherboards? The size of these motherboards is very appealing (the Nano-ITX is only 12x12 cm), but I have read some pretty underwhelming reports of performance on these processors.
Not sure how Linux support stands, and I am also not sure if there are ALSA drivers for the built-in soundchips. It would also remain to be seen if the small cache size is a problem - it seems like cache size is critical to performance with MAX/MSP.
Anyway, if anyone has tried PD on a VIA system, it would be interesting to hear your results. An x86 computer that fits in a large stompbox would be pretty cool. Even if the performance isn't stellar, it might be useable as a programmable effects unit that far surpasses any commercial unit in a similar price range, but with more durability than your average laptop.
Sean Costello
Nice pictures! I like the red box the best...
Do you have any feel for the performance of the VIA processors versus any of the standard x86 processors (Athlon, Pentium)? Are you running the Nehemiah core, or an older C3 variant?
Thanks,
Sean Costello
----- Original Message ----- From: "juto aviten" periclite@free.fr To: pd-list@iem.at Sent: Tuesday, March 23, 2004 9:18 AM Subject: Re: [PD] Anyone running PD on VIA processors?
Hello Sean, We used some mini-ITX VIA mother board : you could here some audio stream here : http://apo33.org/radio/ It uses a proc of 1Ghz 512Mo, it works quite well under linux mandrake and we use PD on this streams... So you couldn't run patch asking a lot of cpu but you could work at the end! Also on the last generation of mini-ITX you don't have anymore this problem of cache size, Epia resolved it. In the other way the onboard sound card works but it's better to put a pci or usb card (like we used some sound blaster live or M-audio quattro), sound quality will be better!! you could find also some of our home computer with this motherboard : http://cybersapiens.org/article.php3?id_article=28 http://cybersapiens.org/article.php3?id_article=13 http://cybersapiens.org/IMG/jpg/metalatrous.jpg http://cybersapiens.org/article.php3?id_article=24 http://cybersapiens.org/article.php3?id_article=23
Also to save some cpu under linux, we use PWM which is an X desktop really light! the nano one's is not available at the moment, maybe soon...
best
juto
Has anyone here tried running Pure Data on the VIA processors, as found
on
the Mini-ITX or Nano-ITX motherboards? The size of these motherboards is very appealing (the Nano-ITX is only 12x12 cm), but I have read some
pretty
underwhelming reports of performance on these processors.
Not sure how Linux support stands, and I am also not sure if there are
ALSA
drivers for the built-in soundchips. It would also remain to be seen if
the
small cache size is a problem - it seems like cache size is critical to performance with MAX/MSP.
Anyway, if anyone has tried PD on a VIA system, it would be interesting
to
hear your results. An x86 computer that fits in a large stompbox would be pretty cool. Even if the performance isn't stellar, it might be useable
as a
programmable effects unit that far surpasses any commercial unit in a similar price range, but with more durability than your average laptop.
Sean Costello
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hello,
Has anyone here tried running Pure Data on the VIA processors, as found on the Mini-ITX or Nano-ITX motherboards? The size of these motherboards is very appealing (the Nano-ITX is only 12x12 cm), but I have read some pretty underwhelming reports of performance on these processors.
We have made a soundserver with an epia board (without moving parts, usb-key as harddisk) see:
http://iem.kug.ac.at/projekte/composition/linux-Soundserver
Not sure how Linux support stands, and I am also not sure if there are ALSA drivers for the built-in soundchips. It would also remain to be seen if the
they works, but bad. Its good for noisy TVs but not for speakers.
small cache size is a problem - it seems like cache size is critical to performance with MAX/MSP.
performance is half of a athlon with same cpu speed, but haveing an 667Mhz via is like an 400MHz pentiumIII which is quite enough for most installation.
mfg winfired
Thanks for the info. Is this running the Eden or C3 processor? I am having trouble finding the info today, but do all of the Edens run the FPU at half speed? I remember the older Via processors did this. If this is the case, the C3 Nehemiah core might be a better bet for PD, as long as fan noise and moving parts are not an issue.
At some point, I'd like to make a nice, solid, floor-mounted box, that would run PD (and maybe the Linux port of Supercollider) as a multieffects device. Ideally, the programs would run without GUI, and receive messages from a MIDI controller.
Sean Costello
----- Original Message ----- From: "Winfried Ritsch" ritsch@iem.at To: pd-list@iem.at Sent: Thursday, March 25, 2004 1:11 AM Subject: Re: [PD] Anyone running PD on VIA processors?
Hello,
Has anyone here tried running Pure Data on the VIA processors, as found
on
the Mini-ITX or Nano-ITX motherboards? The size of these motherboards is very appealing (the Nano-ITX is only 12x12 cm), but I have read some
pretty
underwhelming reports of performance on these processors.
We have made a soundserver with an epia board (without moving parts,
usb-key
as harddisk) see:
http://iem.kug.ac.at/projekte/composition/linux-Soundserver
Not sure how Linux support stands, and I am also not sure if there are
ALSA
drivers for the built-in soundchips. It would also remain to be seen if
the
they works, but bad. Its good for noisy TVs but not for speakers.
small cache size is a problem - it seems like cache size is critical to performance with MAX/MSP.
performance is half of a athlon with same cpu speed, but haveing an 667Mhz
via
is like an 400MHz pentiumIII which is quite enough for most installation.
mfg winfired
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
0001 -
Frank Barknecht -
Hans-Christoph Steiner -
juto aviten -
Larry Troxler -
Mathieu Bouchard -
Sean Costello -
Thomas Grill -
Winfried Ritsch