hi all
Lately I have done a lot of work on some abstractions, so I thought it would be good idea to share it with the list to see if there is any feedback about them.
The main purpose is to allow manipulation of video and audio in real time with PD making its use as easy as possible. It is mainly developed for students to use in ~two day long PD workshops, but i guess it can be used by anyone. I find myself using some of them all the time, specially when prototyping or doing fast sketches, but then again I guess some of them are fairly trivial. Students in these workshops don't usually have the time (or/and background) to go for a full on introduction to PD. Hence this patches are just ready-made solutions to be used with very general knowledge of operating with PD.
So there are abstractions to manipulate video/webcams/pictures with GEM, some sound utilities, and some general utilities. There are also some abstractions to control Arduino from PD (just wraps/rewrites pduino example by Gerda Strobl and Georg Holtzmann into a set of separated abstractions and adds some small functionalities here and there).
They have been thought to be used in two different scenarios. On the one hand a "live coding" situation, this is why the abstractions include GUI controls (exposed via graph on parent) that allow to control its internal state. On the other hand, they are thought to be used in a installation situation, where the interface is not used. So each Gui control corresponds to one inlet. They have been developed to be used with PD-extended, few objects from externals included in that distro are used.
It is also possible that some might already exist in other abstraction collections or externals, i dont know all abstractions/externals in PD so if anyone sees anything repeated please let me know. It would be good to hear feedback about it, I know there are similar projects being developed at the moment. I think it would be nice to end up with a set of ready made objects that can be used by that type of users. It is always nice to start with something that works and then slowly go in depth into the programming.
this is the link to download the latest version http://ixi-audio.net/content/download/ehu_abstractions.zip
There is a readme.txt in the documentation folder that explains all abstractions included and how to use, there is also a set of examples in the examples folder and each abstractions has its help patch included, so once it is copied into extra folder the help system should work fine.
if anyone has questions please just mail me. thanks for any feedback
enrike
hi enrike,
i'm not sure exactly which versions, if any of pd-extended come with the xsample library set up to run after the basic installation, but my version here on ubuntu linux didn't and i spoke to a windows user also who couldn't create the [xgroove~] [xrecord~] family of objects that are used in these abstractions.
I really like the idea of making easy to use, high level objects in
Pd. I think it would be great to have something like Reaktor in Pd.
Then people could start out quickly, and then move into full Pd
programming if they wanted to.
Windows and Mac version of 0.39.3 did come with xsample, but none of
the 0.40.3 releases did.
.hc
On Dec 9, 2008, at 9:45 AM, hard off wrote:
hi enrike,
i'm not sure exactly which versions, if any of pd-extended come
with the xsample library set up to run after the basic
installation, but my version here on ubuntu linux didn't and i
spoke to a windows user also who couldn't create the [xgroove~]
[xrecord~] family of objects that are used in these abstractions.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
/me is wondering
i compiled xsample (linux - 32bits): http://www.11h11.com/temp/xsample.pd_linux
anyone can try to pd -lib xsample.pd_linux? is it working?
patrick(e)k dio:
/me is wondering
i compiled xsample (linux - 32bits): http://www.11h11.com/temp/xsample.pd_linux
anyone can try to pd -lib xsample.pd_linux? is it working?
same problem i got with my build. PD starts up and gets frozen when loading the externals. I "solved" it by comenting out OFLAGS=-O3 from the config-lnx-pd-gcc.txt configuration file. If your file works in your machine this is something to do with my computer, same problem happened in my both machines.
Hi, could you give me some infos about your OS and compiler version? Does it work if you set OFLAGS=-O2 instead? gr~~~
Am 09.12.2008 um 23:39 schrieb altern:
patrick(e)k dio:
/me is wondering
i compiled xsample (linux - 32bits): http://www.11h11.com/temp/xsample.pd_linux
anyone can try to pd -lib xsample.pd_linux? is it working?
same problem i got with my build. PD starts up and gets frozen when loading the externals. I "solved" it by comenting out OFLAGS=-O3 from the config-lnx-pd-gcc.txt configuration file. If your file works in
your machine this is something to do with my computer, same problem
happened in my both machines.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I really like the idea of making easy to use, high level objects in Pd. I think it would be great to have something like Reaktor in Pd. Then people could start out quickly, and then move into full Pd programming if they wanted to.
yes i guess different people have been talking about this, it would be great.
Windows and Mac version of 0.39.3 did come with xsample, but none of the 0.40.3 releases did.
i just double checked and xsample.dll is there in 0.40.3 extended windows version, i also believe it is in the OSX version, but i havent double checked there.
.hc
On Dec 9, 2008, at 9:45 AM, hard off wrote:
hi enrike,
i'm not sure exactly which versions, if any of pd-extended come with the xsample library set up to run after the basic installation, but my version here on ubuntu linux didn't and i spoke to a windows user also who couldn't create the [xgroove~] [xrecord~] family of objects that are used in these abstractions.
Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
hard off(e)k dio:
hi enrike,
i'm not sure exactly which versions, if any of pd-extended come with the xsample library set up to run after the basic installation, but my version here on ubuntu linux didn't and i spoke to a windows user also who couldn't create the [xgroove~] [xrecord~] family of objects that are used in these abstractions.
yeah, i know that... i think it is the only external I use that is missing in the current version of PD extended and only the Linux version. I had to compile it myself which included compiling flext, if you need a hand i think i still have it fresh, i did it two weeks ago.
enrike
Hi,
altern wrote: [snip]
They have been developed to be used with PD-extended, few objects from externals included in that distro are used.
[snip]
this is the link to download the latest version http://ixi-audio.net/content/download/ehu_abstractions.zip
[snip]
if anyone has questions please just mail me. thanks for any feedback
Note: I haven't had time to try them yet, but I've just been checking to see what I might be missing... Quick list of dependencies that I extracted using some scripts:
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy
Wondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
enrike
Thanks,
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Wondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
Yep, I'd avoid these as they are pretty ambiguous. [prepend] probably is the one in cyclone, which could be replaced with prepent.pd from list-abs, if that's in use anyway. [counter] and [gate] are too ambiguous to even guess where they come from.
Ciao
Frank
Claude Heiland-Allen(e)k dio:
Hi,
altern wrote: [snip]
They have been developed to be used with PD-extended, few objects from externals included in that distro are used.
[snip]
this is the link to download the latest version http://ixi-audio.net/content/download/ehu_abstractions.zip
[snip]
if anyone has questions please just mail me. thanks for any feedback
Note: I haven't had time to try them yet, but I've just been checking to see what I might be missing... Quick list of dependencies that I extracted using some scripts:
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy
Wondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
gate and counter are from cyclone, prepend from iemabs. So the complete list of dependencies should be :
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy counter prepend gate
many thanks, i will include this in the documentation.
as i said the abstractions have been developed to be used within PD-extended which currently includes, as far as i know, all of them but arduino and xsample (this last one only missing under linux i think).
I went for PD-extended after couple of bad experinces where i wasted days trying to write code in pd only to find that there were externals included in pd extended doing the job better, more complete and far more efficient than my spaghetti code.
enrike
sorry i meant :
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy cyclone iemabs
gate and counter are from cyclone, prepend from iemabs. So the complete list of dependencies should be :
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy counter prepend gate
On Dec 9, 2008, at 12:08 PM, altern wrote:
Claude Heiland-Allen(e)k dio:
Hi,
altern wrote: [snip]
They have been developed to be used with PD-extended, few objects from externals included in that
distro are used.[snip]
this is the link to download the latest version http://ixi-audio.net/content/download/ehu_abstractions.zip
[snip]
if anyone has questions please just mail me. thanks for any feedback
Note: I haven't had time to try them yet, but I've just been
checking to see what I might be missing... Quick list of dependencies that I extracted using some scripts:arduino freeverb~ Gem ggee import list-abs mapping unauthorized
xsample zexyWondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
gate and counter are from cyclone, prepend from iemabs. So the
complete list of dependencies should be :arduino freeverb~ Gem ggee import list-abs mapping unauthorized
xsample zexy counter prepend gatemany thanks, i will include this in the documentation.
as i said the abstractions have been developed to be used within PD-extended which currently includes, as far as i know, all of them
but arduino and xsample (this last one only missing under linux i think).I went for PD-extended after couple of bad experinces where i wasted days trying to write code in pd only to find that there were externals included in pd extended doing the job better, more complete and far
more efficient than my spaghetti code.
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
.hc
enrike
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner(e)k dio:
On Dec 9, 2008, at 12:08 PM, altern wrote:
Claude Heiland-Allen(e)k dio:
Hi,
altern wrote: [snip]
They have been developed to be used with PD-extended, few objects from externals included in that distro are used.
[snip]
this is the link to download the latest version http://ixi-audio.net/content/download/ehu_abstractions.zip
[snip]
if anyone has questions please just mail me. thanks for any feedback
Note: I haven't had time to try them yet, but I've just been checking to see what I might be missing... Quick list of dependencies that I extracted using some scripts:
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy
Wondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
gate and counter are from cyclone, prepend from iemabs. So the complete list of dependencies should be :
arduino freeverb~ Gem ggee import list-abs mapping unauthorized xsample zexy counter prepend gate
many thanks, i will include this in the documentation.
as i said the abstractions have been developed to be used within PD-extended which currently includes, as far as i know, all of them but arduino and xsample (this last one only missing under linux i think).
I went for PD-extended after couple of bad experinces where i wasted days trying to write code in pd only to find that there were externals included in pd extended doing the job better, more complete and far more efficient than my spaghetti code.
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue. btw, the prepend was in code i borrowed from the arduino help file. thanks
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built-ins, so no need for strange prefixes.
mfgasdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built-ins, so no need for strange prefixes.
Which are unusable with (some) libraries when compiled as multiobject libraries anyway. [import x] then is the better solution IMO.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built- ins, so no need for strange prefixes.
Except [list prepend], which I consider a stranger prefix. :) I
still prefer [cyclone/prepend] since you don't need to add [list
trim] to keep things in the same format they came in as (at least for
the things I seem to do regularly.)
.hc
mfgasdr IOhannes
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
On Dec 11, 2008, at 4:27 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Except [list prepend], which I consider a stranger prefix. :) I
hmm, i vaguely remember turning down my suggestion to rename
internals [list trim] to [list/trim]...should be somewhere on the
sf-tracker
Yeah, not because of the idea, but because it would add a new library
format for that one situation. I think instead there should be a
single library format for all libraries.
.hc
mfrad IOhannes
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Thu, Dec 11, 2008 at 01:33:41PM -0500, Hans-Christoph Steiner wrote:
On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built- ins, so no need for strange prefixes.
Except [list prepend], which I consider a stranger prefix. :) I
still prefer [cyclone/prepend] since you don't need to add [list
trim] to keep things in the same format they came in as (at least for
the things I seem to do regularly.)
Thereby rendering even the simplest of your patches completely useless to me, or anyone else who is a Pd-vanilla fan. I can understand using externals when they are neccessary, such as doing something with weird hardware, or some algorithm that is slow in pure Pd, but I really can't understand using an external in a situation like this.
Your choice though, I guess. Myself, I prefer to make my patches as portable as possible to the widest range of Pd users (pd-extenders included).
Sorry if I sound grumpy; not getting too much sleep here in Berlin. :)
Chris.
On Dec 14, 2008, at 6:38 AM, Chris McCormick wrote:
On Thu, Dec 11, 2008 at 01:33:41PM -0500, Hans-Christoph Steiner
wrote:On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built- ins, so no need for strange prefixes.
Except [list prepend], which I consider a stranger prefix. :) I still prefer [cyclone/prepend] since you don't need to add [list trim] to keep things in the same format they came in as (at least for the things I seem to do regularly.)
Thereby rendering even the simplest of your patches completely useless to me, or anyone else who is a Pd-vanilla fan. I can understand using externals when they are neccessary, such as doing something with weird hardware, or some algorithm that is slow in pure Pd, but I really
can't understand using an external in a situation like this.Your choice though, I guess. Myself, I prefer to make my patches as portable as possible to the widest range of Pd users (pd-extenders included).
Sorry if I sound grumpy; not getting too much sleep here in Berlin. :)
If you compile cyclone as a libdir and stick it in 'extra', then
using [cyclone/prepend] is fully compatible with Pd-vanilla.
Any objectclass that is not included in Pd-vanilla is an external,
whether it is written in C, Pd, etc. For example, even if s-
abtractions or list-abs use only pd-vanilla object, when someone uses
them, they then have an external dependencies.
My aim is to make my code as compatible as possible, while taking
advantage of all the good code that other people have written, like s-
abstractions and list-abs. But there is no standard way to set up
externals when using pd-vanilla, so it is not really possible to
support. Read the archives to see all of the problems running other
people's patches. That's why Pd-extended was started, to have a
standard platform.
.hc
Chris.
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On Sun, Dec 14, 2008 at 12:15:26PM -0500, Hans-Christoph Steiner wrote:
On Dec 14, 2008, at 6:38 AM, Chris McCormick wrote:
On Thu, Dec 11, 2008 at 01:33:41PM -0500, Hans-Christoph Steiner
wrote:On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio:
You can force the version by using the namespace prefix:
[cyclone/counter] [cyclone/prepend] [iemlib/gate]
this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built- ins, so no need for strange prefixes.
Except [list prepend], which I consider a stranger prefix. :) I still prefer [cyclone/prepend] since you don't need to add [list trim] to keep things in the same format they came in as (at least for the things I seem to do regularly.)
Thereby rendering even the simplest of your patches completely useless to me, or anyone else who is a Pd-vanilla fan. I can understand using externals when they are neccessary, such as doing something with weird hardware, or some algorithm that is slow in pure Pd, but I really
can't understand using an external in a situation like this.Your choice though, I guess. Myself, I prefer to make my patches as portable as possible to the widest range of Pd users (pd-extenders included).
Sorry if I sound grumpy; not getting too much sleep here in Berlin. :)
If you compile cyclone as a libdir and stick it in 'extra', then
using [cyclone/prepend] is fully compatible with Pd-vanilla.
Great.
Any objectclass that is not included in Pd-vanilla is an external,
whether it is written in C, Pd, etc. For example, even if s- abtractions or list-abs use only pd-vanilla object, when someone uses
them, they then have an external dependencies.
Yes, for sure, but are a couple of big difference between using s-abstractions or list-abs in your composition and spreading [cyclone/prepend] willy-nilly throughout your patches.
First, using abstractions is a simple matter of copying a folder, whilst cyclone requires compilation and linking of bloating 3rd party software into my sleek, pristine Pd binary, or using pd-extended, which I choose not to do. It also means that if I use your patches in my own work, I am straight away demanding that my users install pd-extended, or go through the painful compilation exercise. They probably don't even have a compiler installed. This issue escalates rapidly if every Pd user follows the advice you are giving out. Soon we have all kind of people using all kinds of crap, and forcing everyone else who wants to use their patches to do the same. It's a bad way to make software.
Second, and a much more important reason, is that a perfectly good prepend exists in vanilla. As soon as you start using cyclone/prepend for the very dubious advantage of having to make one less [list trim] object, you instantly alienate me and others like me.
My aim is to make my code as compatible as possible, while taking
advantage of all the good code that other people have written, like s- abstractions and list-abs. But there is no standard way to set up
externals when using pd-vanilla, so it is not really possible to
support. Read the archives to see all of the problems running other
people's patches. That's why Pd-extended was started, to have a
standard platform.
Pd-extended is great. It's excellent to have that standared platform. All I am advocating is preferring the 'lowest common denominator' as far as possible. I am saying that you should follow Occam's Razor when making patches, and make them as simple and widely portable as possible. I am definately not saying that you shouldn't use externals, libdirs, other libraries or whatever when you need to. I understand completely the need for externals in many situations, but I also think that it's bad practice to use an external when a builtin will do. I am actually just putting forward a very common computer science precept; reuse. Spare a thought for us poor chumps in vanilla land. :)
Best,
Chris.
On Dec 15, 2008, at 11:14 AM, Chris McCormick wrote:
On Sun, Dec 14, 2008 at 12:15:26PM -0500, Hans-Christoph Steiner
wrote:On Dec 14, 2008, at 6:38 AM, Chris McCormick wrote:
On Thu, Dec 11, 2008 at 01:33:41PM -0500, Hans-Christoph Steiner wrote:
On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
altern wrote:
Hans-Christoph Steiner(e)k dio: > > You can force the version by using the namespace prefix: > > [cyclone/counter] > [cyclone/prepend] > [iemlib/gate] this is what i am doing. i think that solves the issue.
i think even better would be to use built-in objects. in the case of [gate] and [prepend] this maps to one (or 2) built- ins, so no need for strange prefixes.
Except [list prepend], which I consider a stranger prefix. :) I still prefer [cyclone/prepend] since you don't need to add [list trim] to keep things in the same format they came in as (at
least for the things I seem to do regularly.)Thereby rendering even the simplest of your patches completely
useless to me, or anyone else who is a Pd-vanilla fan. I can understand
using externals when they are neccessary, such as doing something with
weird hardware, or some algorithm that is slow in pure Pd, but I really can't understand using an external in a situation like this.Your choice though, I guess. Myself, I prefer to make my patches as portable as possible to the widest range of Pd users (pd-extenders included).
Sorry if I sound grumpy; not getting too much sleep here in
Berlin. :)If you compile cyclone as a libdir and stick it in 'extra', then using [cyclone/prepend] is fully compatible with Pd-vanilla.
Great.
Any objectclass that is not included in Pd-vanilla is an external, whether it is written in C, Pd, etc. For example, even if s- abtractions or list-abs use only pd-vanilla object, when someone uses them, they then have an external dependencies.
Yes, for sure, but are a couple of big difference between using s-abstractions or list-abs in your composition and spreading [cyclone/prepend] willy-nilly throughout your patches.
First, using abstractions is a simple matter of copying a folder,
whilst cyclone requires compilation and linking of bloating 3rd party
software into my sleek, pristine Pd binary, or using pd-extended, which I
choose not to do. It also means that if I use your patches in my own work,
I am straight away demanding that my users install pd-extended, or go
through the painful compilation exercise. They probably don't even have a compiler installed. This issue escalates rapidly if every Pd user follows the advice you are giving out. Soon we have all kind of people using all kinds of crap, and forcing everyone else who wants to use their patches to do the same. It's a bad way to make software.Second, and a much more important reason, is that a perfectly good prepend exists in vanilla. As soon as you start using cyclone/prepend for the very dubious advantage of having to make one less [list trim] object, you instantly alienate me and others like me.
There is a third option: people can release libraries like 'cyclone'
as libdirs. Then you could just download the right one and drop it
into place to install it.
This reminds me of a similar discussion that happens in Java-land.
Lots of people still swear by Java 1.0. Sure, you can do what you
need, but newer versions of Java are widespread and have more
shoulders of giants included to stand on.
.hc
My aim is to make my code as compatible as possible, while taking advantage of all the good code that other people have written,
like s- abstractions and list-abs. But there is no standard way to set up externals when using pd-vanilla, so it is not really possible to support. Read the archives to see all of the problems running other people's patches. That's why Pd-extended was started, to have a standard platform.Pd-extended is great. It's excellent to have that standared platform. All I am advocating is preferring the 'lowest common denominator'
as far as possible. I am saying that you should follow Occam's Razor when making patches, and make them as simple and widely portable as
possible. I am definately not saying that you shouldn't use externals, libdirs, other libraries or whatever when you need to. I understand completely the need for externals in many situations, but I also think that it's bad practice to use an external when a builtin will do. I am actually just putting forward a very common computer science precept; reuse. Spare a thought for us poor chumps in vanilla land. :)Best,
Chris.
If you are not part of the solution, you are part of the problem.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This reminds me of a similar discussion that happens in Java-land.
Lots of people still swear by Java 1.0. Sure, you can do what you
need, but newer versions of Java are widespread and have more
shoulders of giants included to stand on.
Then why ignore that Pd now includes a fully working (and IMO even smarter) replacement for the old incarnations of [prepend] in iemlib, cxc and Cyclone? The latter three versions simply are obsolete within a current Pd and instead of recommending to use them they should be deprecated.
Ciao
Frank
On Dec 17, 2008, at 2:30 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This reminds me of a similar discussion that happens in Java-land. Lots of people still swear by Java 1.0. Sure, you can do what you need, but newer versions of Java are widespread and have more shoulders of giants included to stand on.
Then why ignore that Pd now includes a fully working (and IMO even smarter) replacement for the old incarnations of [prepend] in iemlib, cxc and Cyclone? The latter three versions simply are obsolete
within a current Pd and instead of recommending to use them they should be deprecated.
I agree with you here probably almost all of the time, but there are
some objects out there, like cyclone/prepend, which I find cause me
much less groans and gotchas than other versions. So yes, I agree we
should strive to make things as compatible as possible, but I also
think that we should use good code with it is available.
I have found that when I strived to make everything compatible for
everyone, I ended up with much less useful code. Now that I strive
to make almost everything compatible for most people, I can generate
a lot more useful code, and those who are left out are usually the
ones who can handle small incompatibilities without much struggle.
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
I agree with you here probably almost all of the time, but there are
some objects out there, like cyclone/prepend, which I find cause me
much less groans and gotchas than other versions.
Hallo.
Sorry if I miss the obvious here but why does [cyclone/prepend] cause you "much less groans and gotchas" than [list prepend] ?
Cheers. _y
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I agree with you here probably almost all of the time, but there are
some objects out there, like cyclone/prepend, which I find cause me
much less groans and gotchas than other versions.
Hehe, seems we're turning around in circles here. ;)
You know this, so the following is for other readers: [list prepend]->[list trim] is almost exactly the same as [cyclone/prepend], only that you can also prepend things to messages starting with "set" and you have to do so through the right inlet of [list prepend].
Ciao
Frank
On Wed, 2008-12-17 at 12:28 -0500, Hans-Christoph Steiner wrote:
On Dec 17, 2008, at 2:30 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This reminds me of a similar discussion that happens in Java-land. Lots of people still swear by Java 1.0. Sure, you can do what you need, but newer versions of Java are widespread and have more shoulders of giants included to stand on.
Then why ignore that Pd now includes a fully working (and IMO even smarter) replacement for the old incarnations of [prepend] in iemlib, cxc and Cyclone? The latter three versions simply are obsolete
within a current Pd and instead of recommending to use them they should be deprecated.I agree with you here probably almost all of the time, but there are
some objects out there, like cyclone/prepend, which I find cause me
much less groans and gotchas than other versions. So yes, I agree we
should strive to make things as compatible as possible, but I also
think that we should use good code with it is available.I have found that when I strived to make everything compatible for
everyone, I ended up with much less useful code. Now that I strive
to make almost everything compatible for most people, I can generate
a lot more useful code, and those who are left out are usually the
ones who can handle small incompatibilities without much struggle.
this is not true, at least for me. i spend a lot of time with finding out the differences between a pd-vanilla+libs installation and a pd-extended installation, in order to know, what is cross-distro compatible and what not. i don't say, that it is not worth the time and i think that pd-extended is getting better and better. but under any circumstances i wouldn't recommend to use [cyclone/prepend] before [list prepend]. since i don't use cyclone, your patch using [cyclone/prepend] would force me to find out the differences between [cyclone/prepend] and [list prepend], then i would need to either install cyclone or adapt your patch. this definitely requires time. i see myself a lot adapting patches, such as the arduino-help-patch, to work on my system. ok, it's not quite 'struggling', but at least time consuming.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Yo,
On Tue, Dec 16, 2008 at 06:43:07PM -0500, Hans-Christoph Steiner wrote:
There is a third option: people can release libraries like 'cyclone'
as libdirs. Then you could just download the right one and drop it
into place to install it.
Cool, I will check out libdirs and see if I can package my s-abstractions stuff like that. That said, I wouldn't be dropping a binary version of [cyclone/prepend] into my system any time soon. Libdirs don't solve what is a fundementally bad idea - using [cyclone/prepend] in place of [list prepend].
This reminds me of a similar discussion that happens in Java-land.
Lots of people still swear by Java 1.0. Sure, you can do what you
need, but newer versions of Java are widespread and have more
shoulders of giants included to stand on.
I like to think that I'm not a luddite, and that I embrace progress as much as any technophile, but to cast pd-extended in the role of "next best thing to happen to Pd" is arguable. I for one definately don't see pd-extended as the "newest version of Pd". I see it as an alternative distribution which provides lots of extra functionality.
I am a big fan of Python's "batteries included" philosophy, which I think is what you are advocating with pd-extended, but it should be noted that the Python maintainers draw the line somewhere. They don't compile every single possible library out there into a giant monolithic release.
Since you mention Java let me frame my argument in terms of that language. If I was writing some code in Java I would always prefer using classes from the core of Java, over using 3rd party libraries, wherever possible. I would do this because if I want to port my Java program to a webserver, or embedded system, or mobile phone, I am much more likely to be able to easily port it if I use the core Java language. Additionally, if I release my source code, others will be able to use it far more easily if its only dependency is the core of Java. The less dependencies there are, the more robust my library becomes in terms of places where it can be ported. To me this is the identical situation to what we've been talking about. If users start using [cyclone/prepend] in their patches instead of Pd's built-in [list prepend], then they immediately make their patches less portable to other Pds. That is all I am saying: favour Pd builtin's wherever possible so that your patches will be as widely distributable as possible.
Sorry to bang on about this, but I am still arguing this point because I want to make sure that your bad advice doesn't influence other Pd users into making bad decisions and making everyone's life more difficult. I am not trying to be harsh here, but rather I am trying to be honest about my motivation for persisting with this thread.
Thanks again for all your hard work with pd-extended, though! Definately appreciated (even though I don't use it, just like you don't use RedHat).
Best,
Chris.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Except [list prepend], which I consider a stranger prefix. :) I
still prefer [cyclone/prepend] since you don't need to add [list
trim] to keep things in the same format they came in as (at least for
the things I seem to do regularly.)
As main author of [list]-abs I'm pretty biased but to me [list prepend] is way superior and easier to understand than using Max/Cyclone's [prepend]. The main reason is that [list] objects convert everything to a proper list-message and after that conversion you can basically completely forget and ignore the difference between meta-messages and list-messages in Pd - because you're left with list-messages *only*. (As we all know, this difference is a source for confusion to many beginning Pd users.)
Coding the [list]-abs with just the Max'ish prepend would be horrible and you'd need to insert lots of [list] objects just to convert meta-messages ino list-space. With the list-family it's really easy: Just use [list], work in a space of proper list-messages, and in the end maybe throw in a "list trim" if you really need a meta-message.
Ciao
Frank
Wondering about these though, are they from iemlib? mixed? something else? Thinking they should probably be replaced by native vanilla abstractions/subpatches if/wherever possible.
counter prepend gate
sorry i think i did not understand you at first, i thought you where talking about all externals used, but obviously you were talking about the three above. I am trying to find where do i use prepend. Some code is pretty old, and i dont remember. Is there a way to find this apart from opening the patches and searching visually or running ctrl+F ?
Hallo, altern hat gesagt: // altern wrote:
sorry i think i did not understand you at first, i thought you where talking about all externals used, but obviously you were talking about the three above. I am trying to find where do i use prepend. Some code is pretty old, and i dont remember. Is there a way to find this apart from opening the patches and searching visually or running ctrl+F ?
If you have a command line with soome Unix tools installed, you could do a:
$ grep -l prepend *.pd
to list every patch that has a prepend. You could replace that with a [prepent] and include prepent.pd using one of the solutions on the tips and tricks page: http://puredata.info/docs/tutorials/TipsAndTricks/
Ciao
Frank
Frank Barknecht(e)k dio:
Hallo, altern hat gesagt: // altern wrote:
sorry i think i did not understand you at first, i thought you where talking about all externals used, but obviously you were talking about the three above. I am trying to find where do i use prepend. Some code is pretty old, and i dont remember. Is there a way to find this apart from opening the patches and searching visually or running ctrl+F ?
If you have a command line with soome Unix tools installed, you could do a:
$ grep -l prepend *.pd
doh! of course ... lesson 1: pd patches are just text files... thanks for reminding me.
to list every patch that has a prepend. You could replace that with a [prepent] and include prepent.pd using one of the solutions on the tips and tricks page: http://puredata.info/docs/tutorials/TipsAndTricks/
thank you for the tips!
enrike
-
altern -
Chris McCormick -
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
patrick -
Roman Haefeli -
Thomas Grill -
y