To whom it may concern,
Some time ago I was explained the issues of why FTGL libs was not
included GEM for the extended OSX release of PD. The answer did not
make me any wiser. The conclusion was "Compile it yourself". Its a
shame that such a great tool (as GEM could be) is falling into the
shade by elitist attitude.
Bugger, time to switch.
T.
Luckily there is a hell of a lot more to Pd than the extended distro. Try one of those options?
On 6/5/07, timon timon@botezco.com wrote:
To whom it may concern,
Some time ago I was explained the issues of why FTGL libs was not included GEM for the extended OSX release of PD. The answer did not make me any wiser. The conclusion was "Compile it yourself". Its a shame that such a great tool (as GEM could be) is falling into the shade by elitist attitude. Bugger, time to switch.
T.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, timon hat gesagt: // timon wrote:
Some time ago I was explained the issues of why FTGL libs was not
included GEM for the extended OSX release of PD. The answer did not
make me any wiser. The conclusion was "Compile it yourself". Its a
shame that such a great tool (as GEM could be) is falling into the
shade by elitist attitude. Bugger, time to switch.
To Linux, for example?
Sorry, couldn't resist. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, Jun 05, 2007 at 03:40:51PM +0100, timon wrote:
Some time ago I was explained the issues of why FTGL libs was not
included GEM for the extended OSX release of PD. The answer did not
make me any wiser. The conclusion was "Compile it yourself". Its a
shame that such a great tool (as GEM could be) is falling into the
shade by elitist attitude.
Sometimes I think what can be perceived as 'elitism' is actually just a lack of time. Remember that the people working on this aren't being paid; they are hobbyists producing code in their spare time. They may simply not have the resources to solve your particular problem and hence they ask you to try and solve it yourself.
Bugger, time to switch.
If Pd/GEM can't solve your problem, then there is nothing wrong with trying out different software. If you're unsatisfied, maybe try another Free Software tool that does a similar job?
Best,
Chris.
On Tue, Jun 05, 2007 at 03:40:51PM +0100, timon wrote:
Some time ago I was explained the issues of why FTGL libs was not
included GEM for the extended OSX release of PD. The answer did not
make me any wiser. The conclusion was "Compile it yourself". Its a
shame that such a great tool (as GEM could be) is falling into the
shade by elitist attitude.
Sometimes I think what can be perceived as 'elitism' is actually just a lack of time. Remember that the people working on this aren't being paid; they are hobbyists producing code in their spare time. They may simply not have the resources to solve your particular problem and
hence
they ask you to try and solve it yourself.
All of the work done (out of love, not money) by the pd community should be applauded. With that said, there is a sense of elitism. I'm not talking only about the PD community here, though. Take the users of the 'industry standard' software, such as Logic and ProTools. It's no secret that many of these users look down their nose at those musicians who use software like Ableton Live, FL Studio, Orion Pro and the like. Then you have the users of more 'academic' software (PD, Max\MSP, Csound, etc.) who often seem to have a sense of superiority; I've seen Csound users look down on Max/MSP users.
I remember a couple of weeks ago, someone on this list posted a piece that used PD as the sound generation source, but he then arranged and mixed the piece in Live. Then someone commented with an elitist tone as to why he used Live at all. Further, I've seen coders look down on those who use anything that isn't purely programming. Everyone loves their tools, and there will always be a sense of pride in those tools. But, my god, its friggin software! No need to be rude.
Then again, a lot of my opinion is based upon interaction with other users over the internet. This, in of itself, may be the cause for this sense of elitism. While talking on forums and lists, I often find that people have very short fuses and are often argumentative or simply look down on 'newbies'. I think that some people are comfortable being rude or unhelpful because there aren't any repercussions from acting in such a way; they don't have to face the person they're communicating with. I'd like to think that a lot of the people who act rude or elite on lists and forums wouldn't act that way if you were to talk to them face to face.
While I'm ranting :-)....In my academic experience, it's often frowned upon to use other's patches in your own compositions because it seems that the patches themselves are the work of art; and it's almost as if this is considered plagiarism. And while I agree that designing patches/programs/instruments IS an art-form, I don't understand why it isn't encouraged for composers to use other people's patches/instruments. Can you imagine if Chopin had to build every piano that he ever played? Thank goodness Hendrix was a guitar player, not a guitar builder.
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers. There is still a rigid line that separates the composer and the programmer. Most Music curriculums are still classically based. Most Music Technology curriculums are programming based. What about today's composers who are interested in classical compositional techniques and forms, but who are, at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
[steps down from his soap box]
:-)
Jared
get back on that soap box!
i wanna throw some tomatoes!
i love this!
On 6/7/07, jared microcosm11@msn.com wrote:
On Tue, Jun 05, 2007 at 03:40:51PM +0100, timon wrote:
Some time ago I was explained the issues of why FTGL libs was not included GEM for the extended OSX release of PD. The answer did not make me any wiser. The conclusion was "Compile it yourself". Its a shame that such a great tool (as GEM could be) is falling into the shade by elitist attitude.
Sometimes I think what can be perceived as 'elitism' is actually just a lack of time. Remember that the people working on this aren't being paid; they are hobbyists producing code in their spare time. They may simply not have the resources to solve your particular problem and
hence
they ask you to try and solve it yourself.
All of the work done (out of love, not money) by the pd community should be applauded. With that said, there is a sense of elitism. I'm not talking only about the PD community here, though. Take the users of the 'industry standard' software, such as Logic and ProTools. It's no secret that many of these users look down their nose at those musicians who use software like Ableton Live, FL Studio, Orion Pro and the like. Then you have the users of more 'academic' software (PD, Max\MSP, Csound, etc.) who often seem to have a sense of superiority; I've seen Csound users look down on Max/MSP users.
I remember a couple of weeks ago, someone on this list posted a piece that used PD as the sound generation source, but he then arranged and mixed the piece in Live. Then someone commented with an elitist tone as to why he used Live at all. Further, I've seen coders look down on those who use anything that isn't purely programming. Everyone loves their tools, and there will always be a sense of pride in those tools. But, my god, its friggin software! No need to be rude.
Then again, a lot of my opinion is based upon interaction with other users over the internet. This, in of itself, may be the cause for this sense of elitism. While talking on forums and lists, I often find that people have very short fuses and are often argumentative or simply look down on 'newbies'. I think that some people are comfortable being rude or unhelpful because there aren't any repercussions from acting in such a way; they don't have to face the person they're communicating with. I'd like to think that a lot of the people who act rude or elite on lists and forums wouldn't act that way if you were to talk to them face to face.
While I'm ranting :-)....In my academic experience, it's often frowned upon to use other's patches in your own compositions because it seems that the patches themselves are the work of art; and it's almost as if this is considered plagiarism. And while I agree that designing patches/programs/instruments IS an art-form, I don't understand why it isn't encouraged for composers to use other people's patches/instruments. Can you imagine if Chopin had to build every piano that he ever played? Thank goodness Hendrix was a guitar player, not a guitar builder.
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers. There is still a rigid line that separates the composer and the programmer. Most Music curriculums are still classically based. Most Music Technology curriculums are programming based. What about today's composers who are interested in classical compositional techniques and forms, but who are, at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
[steps down from his soap box]
:-)
Jared
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi
On 6/7/07, jared microcosm11@msn.com wrote:
All of the work done (out of love, not money) by the pd community should be applauded. With that said, there is a sense of elitism.
how does this perceived elitism affect your ability to make music? to learn about digitial synthesis? is it an excuse to avoid the work required?
i've seen lots of beginner questions answered here- sometimes with sarcasm, but mostly with patience [and sometimes with both].
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers.
this seems like an arbitrary line you are drawing. are you talking about people who use presets as opposed to people who can generate their own 'presets'?
and why is academia some kind of measuring stick? in my experience, academia is not the ivory tower you seem to be implying- it is filled with people, some more creative, some less creative, some as greedy as any industrialist you could find in the private sector.
There is still a rigid line that separates the composer and the programmer.
the rigidity is mostly in your mind. composing is very much like programming. instead of working in perl, beethoven worked with staff paper [think punch cards]. how is a repeat sign in a score different than a 'while' loop? how is a fugal theme different than a variable that gets subjected to a certain kind of treatment?
What about today's composers who are interested in classical compositional techniques and forms, but who are, at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
they are out of luck.
what about someone who wants to perform bach's wtc and has no interest in learning the piano?
also, as an aside, forget about classical forms: what do *you* have to say? [although if you want make a career out of being an anachronism, maybe the academies of the world will support you]
:-)
:-P
Hello, are there any project where we can see almost all externals in action, at least all externals that doesn't require particular hardware, and that could be run with a 'one clic' or 'one command' pd installation like pd-extended for example ? I mean by this kind of project, a workstation where we could meet all the different externals and some comments with navigating through patches. ( net-pd is one kind of this project obviously but I've found it misses documentation for having a real idea on how it is functionning, maybe I didn't go deeply enough through the available files...) By this way, any new user of pd would be able to use pd tools, without having any knowledge of the functionning of the patches, and with the comments on how object are used, the new user would also learn a lot faster. I believe that the 'elitist' point of view would be seriously dammaged by this kind of enterprise. It was my 0.5 cent question. Patko.
john saylor a écrit :
hi
On 6/7/07, jared microcosm11@msn.com wrote:
All of the work done (out of love, not money) by the pd community should be applauded. With that said, there is a sense of elitism.
how does this perceived elitism affect your ability to make music? to learn about digitial synthesis? is it an excuse to avoid the work required?
i've seen lots of beginner questions answered here- sometimes with sarcasm, but mostly with patience [and sometimes with both].
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers.
this seems like an arbitrary line you are drawing. are you talking about people who use presets as opposed to people who can generate their own 'presets'?
and why is academia some kind of measuring stick? in my experience, academia is not the ivory tower you seem to be implying- it is filled with people, some more creative, some less creative, some as greedy as any industrialist you could find in the private sector.
There is still a rigid line that separates the composer and the programmer.
the rigidity is mostly in your mind. composing is very much like programming. instead of working in perl, beethoven worked with staff paper [think punch cards]. how is a repeat sign in a score different than a 'while' loop? how is a fugal theme different than a variable that gets subjected to a certain kind of treatment?
What about today's composers who are interested in classical compositional techniques and forms, but who are, at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
they are out of luck.
what about someone who wants to perform bach's wtc and has no interest in learning the piano?
also, as an aside, forget about classical forms: what do *you* have to say? [although if you want make a career out of being an anachronism, maybe the academies of the world will support you]
:-)
:-P
Some of my favorites along this line are the pmpd examples. In the
Help Browser, check out examples->pmpd. Watch out, they can use a
lot of CPU time, so it's best to check on "defeat real-time
scheduling" in the Startup preferences when playing with those.
.hc
On Jun 7, 2007, at 11:30 AM, Patco wrote:
Hello, are there any project where we can see almost all externals in action, at least all externals that doesn't require particular hardware, and that could be run with a 'one clic' or 'one command' pd installation like pd-extended for example ? I mean by this kind of project, a workstation where we could meet all the different externals and some comments with navigating through
patches. ( net-pd is one kind of this project obviously but I've found it
misses documentation for having a real idea on how it is functionning,
maybe I didn't go deeply enough through the available files...) By this way, any new user of pd would be able to use pd tools,
without having any knowledge of the functionning of the patches, and with the comments on how object are used, the new user would also learn a
lot faster. I believe that the 'elitist' point of view would be seriously
dammaged by this kind of enterprise. It was my 0.5 cent question. Patko.john saylor a écrit :
hi
On 6/7/07, jared microcosm11@msn.com wrote:
All of the work done (out of love, not money) by the pd community
should be applauded. With that said, there is a sense of elitism.how does this perceived elitism affect your ability to make music? to learn about digitial synthesis? is it an excuse to avoid the work required?
i've seen lots of beginner questions answered here- sometimes with sarcasm, but mostly with patience [and sometimes with both].
I think academia needs to recognize that there are many composers
who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers.this seems like an arbitrary line you are drawing. are you talking about people who use presets as opposed to people who can generate their own 'presets'?
and why is academia some kind of measuring stick? in my experience, academia is not the ivory tower you seem to be implying- it is filled with people, some more creative, some less creative, some as
greedy as any industrialist you could find in the private sector.There is still a rigid line that separates the composer and the programmer.
the rigidity is mostly in your mind. composing is very much like programming. instead of working in perl, beethoven worked with staff paper [think punch cards]. how is a repeat sign in a score different than a 'while' loop? how is a fugal theme different than a variable that gets subjected to a certain kind of treatment?
What about today's composers who are interested in classical compositional techniques and forms, but
who are, at heart, electronic music composers and want to apply these
classical techniques and forms to their electronic compositions with the
AID of technology, yet have no interest in programming?they are out of luck.
what about someone who wants to perform bach's wtc and has no
interest in learning the piano?also, as an aside, forget about classical forms: what do *you*
have to say? [although if you want make a career out of being an anachronism, maybe the academies of the world will support you]:-)
:-P
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Thu, 2007-06-07 at 17:30 +0200, Patco wrote:
( net-pd is one kind of this project obviously but I've found it misses documentation for having a real idea on how it is functionning, maybe I didn't go deeply enough through the available files...)
what are you missing? i know that netpd lacks a lot of documentation, but i'd like to know, what other people are missing.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Le vendredi 08 juin 2007 à 18:44 +0200, Roman Haefeli a écrit :
On Thu, 2007-06-07 at 17:30 +0200, Patco wrote:
( net-pd is one kind of this project obviously but I've found it misses documentation for having a real idea on how it is functionning, maybe I didn't go deeply enough through the available files...)
what are you missing? i know that netpd lacks a lot of documentation, but i'd like to know, what other people are missing.
roman
Hi roman, thanks for paying attention; Maybe I'm asking too much but it would be nice if each patch was documented with comments that helps for understanding any process that makes functionning net-pd in every detail. And obviously, the same thing would be necessary for any eventual 'add-on', or abstraction made by a net-pd user. I think that some dogmas would be necessary for avoiding to enter into an anarchic project *sarcasm* where all patches has been made by the freewill of belzebut *end sarcasm* An example of well documented project is how almost all list-abs.
Net-pd is for me the ONLY project where we could have a chance one day for having ALL externals, abstractions, extensions and even the hardware dependant externals in action, without having passing hours about configuring pd, understanding how the object works, etc ... This is certainly because a growing bunch of people uses to build net-pd patches for jamming with others all around the world...
Well I'm always thinking about future developpements (maybe too much), and found out that the net-pd project is the best candidate for having a functionnal bundle of all pd candies. So, if all the stuff inside this neat project is also documented by comments, it would not only become more efficient than any manual, stage, physical meetings ..., for both learning how to use pd and having fun with it, but it would also decrease the amount of time for developping some add-ons, or optimizing the functionning.
I don't particulary have fun with opening, testing, closing the hundreds patches grabbed from cvs, pd-extended, pd-list, etc... if all those patches were documented under a single project that is already functionnal, a new user would come to the pd world without the fear of not having the possibility of understanding how the hell this stuff works.
Patko.
Hallo!
Net-pd is for me the ONLY project where we could have a chance one day for having ALL externals, abstractions, extensions and even the hardware dependant externals in action, without having passing hours about configuring pd, understanding how the object works, etc ...
[...]
and found out that the net-pd project is the best candidate for having a functionnal bundle of all pd candies.
that's what pd extended tries to achieve ...
So, if all the stuff inside this neat project is also documented by comments, it would not only become more efficient than any manual, stage, physical meetings ..., for both learning how to use pd and having fun with it, but it would also decrease the amount of time for developping some add-ons, or optimizing the functionning.
that's what pd extended tries to achieve ...
I don't particulary have fun with opening, testing, closing the hundreds patches grabbed from cvs, pd-extended, pd-list, etc... if all those patches were documented under a single project that is already functionnal, a new user would come to the pd world without the fear of not having the possibility of understanding how the hell this stuff works.
again, pd extended ... However, of course not all patches are working out of the box with pd extended (I think not many will work), but if everyone builds his own distribution system (like netpd in your description) then it will never work ...
LG Georg
Hello Georg,
Le vendredi 08 juin 2007 à 20:28 +0200, Georg Holzmann a écrit :
Hallo!
Net-pd is for me the ONLY project where we could have a chance one day for having ALL externals, abstractions, extensions and even the hardware dependant externals in action, without having passing hours about configuring pd, understanding how the object works, etc ...
[...]
and found out that the net-pd project is the best candidate for having a functionnal bundle of all pd candies.
that's what pd extended tries to achieve ...
Nice try but not functionnal... pd-extended provides a maximum of functionning externals, gives a lot of examples, but it doesn't provide a fully fonctionning set of objects like net-pd does
So, if all the stuff inside this neat project is also documented by comments, it would not only become more efficient than any manual, stage, physical meetings ..., for both learning how to use pd and having fun with it, but it would also decrease the amount of time for developping some add-ons, or optimizing the functionning.
that's what pd extended tries to achieve ...
Well, I was talking about net-pd's documentation, maybe I wasn't clear enough; pd-extended seems to be THE framework of pure data where every dev can test their abstrations externals together etc..., so indeed for optimizing the developping time of pd objects, it's an appropriate achievement. But for playing with all those objects, and learn about almost all available processes, pd-extended can become very fast a source of deep annoyement, because it's not fully functionnal, and I doubt it will ever become fully functionnal, just because pd-extended is made of almost only 'unstable' releases of pd stuff.
I don't particulary have fun with opening, testing, closing the hundreds patches grabbed from cvs, pd-extended, pd-list, etc... if all those patches were documented under a single project that is already functionnal, a new user would come to the pd world without the fear of not having the possibility of understanding how the hell this stuff works.
again, pd extended ...
Well, pd-extended is certainly the best package to get, indeed ,for having an updated documentation of the objects, and abstractions, a good database where we can pick the help file or the example for having a clue about "what the hell is one object, what's happening inside, and it have to be taken as a reference, I've no problem with that. But, :D it's far more entertaining to just see one patch, one gop, one extra in action through a FULLY FUNCTIONNAL PROJECT and 'right click-->help', than having to browse dozens of patches for finding something that might be interesting.
However, of course not all patches are working out of the box with pd extended (I think not many will work), but if everyone builds his own distribution system (like netpd in your description) then it will never work ...
net-pd works very good, and can be installed in a minute. it's not really one distribution like everyone would make, in my eyes, but one distribution that everyone would use, a kind of stable funny release of the pd stuff.
Many patches won't work out of the box almost always because it will miss an external, or an abstraction, here we come again on the fact that the patches misses some comments,
*ultra high sarcastic mode, sensible mind don't read*
if there is not room enough to put the name of the dependances, like in almost all example patches, or original abstractions, why not replacing the name of the autor with something more usefull...
*end of ultra sarcastic mode*
Let's compare pd system with linux operating system (sorry if it's too much disgressive), there are so many distributions, each distribution has it's particularity, some are rather better than others for different stuffes, different computers, and linux works pretty well.
LG Georg
Thanks for letting me advocating my point of view, Patko.
Hallo!
Nice try but not functionnal... pd-extended provides a maximum of functionning externals, gives a lot of examples, but it doesn't provide a fully fonctionning set of objects like net-pd does
Yes I know that it does not work yet, but thats the goal of pd-extended ...
if there is not room enough to put the name of the dependances, like in almost all example patches, or original abstractions, why not replacing the name of the autor with something more usefull...
[import] in pd extended ... ;) ... so you have the documentation and the loading of the external/abstractions !
However, I only wanted to say that the goal of pd-extended is exactly what you described - of course it does not work yet and I don't know if it will work in future ... And you are invited to help - cleaning up some patches, adding comments, include out-of-the-box examples, ... everything you described is really useful and appreciated.
LG Georg
Le vendredi 08 juin 2007 à 21:35 +0200, Georg Holzmann a écrit :
Hallo!
However, I only wanted to say that the goal of pd-extended is exactly what you described -
So I have to conclude that pd-extended seriously need a kind of interface that would help going directly to the stuff we need. Not really a browser, a 'workstation' set of abstraction would be more versatile, I believe; memento could be the preset manager part of this workstation, for giving a little clue, and gridflow would be the cherry at the topside of the cake (maybe I went too far again).
Excuse-me for being so redondant, for example in net-pd, if we want to use a synth, we just have to open a synth, a mixtable, and a master clock, and voila, we can play with the synth without scratching head for finding the good button to push, if we want drum boxes, we open drumboxes, a sequencer, and we can beat the rythm all in sync with the synths, just with several mouse clicks. This example shows how things might be handled from some part of pd-extended, a kind of modular interface that could be able to make functionning all the stuff inside.
of course it does not work yet and I don't know if it will work in future ...
What about trying first to build a 'lower' version of pd-extended where all the inefficient stuff and their depending things would be simply supressed? It would make a kind of stable release, for starting on a clean environment. Also the actual version of pd-extended would continue it's road, fighting against bugs, swallowing each new technology, but with the awareness of being an 'unstable release'.
And you are invited to help - cleaning up some patches, adding comments, include out-of-the-box examples,
Where would I submit corrected files?
... everything you described is really useful and appreciated.
Nice to read!
LG Georg
Patko.
hi patko
net-pd works very good, and can be installed in a minute. it's not really one distribution like everyone would make, in my eyes, but one distribution that everyone would use, a kind of stable funny release of the pd stuff.
Many patches won't work out of the box almost always because it will miss an external, or an abstraction, here we come again on the fact that the patches misses some comments,
if you miss an abstraction there is something wrong with your setup. i think i can say _every_ netpd-patch that uses abstractions has a subpatch [pd abslist] with a list of msgs containing all used abstractions.
when one netloads a patch, _creator.pd will read the abslist and tells all the users that it is going to upload a patch with the specific abstractions and version number.
i.e. of sumsum.pd ( [r netpd-broadcast]-[print] )
print: cr.postloadrequest 4 print: cr.filecheck abs/jamx.pd a 0.1.26 4 print: cr.filecheck abs/pad.pd a 0.2.12 4 print: cr.filecheck abs/i2mx~.pd a 0.6.28 4 print: cr.filecheck abs/mx_manager.pd a 0.6.16 4 print: cr.filecheck abs/if4.pd a 0.0.0 4 print: cr.filecheck abs/mx_manager.pd a 0.6.16 4 print: cr.filecheck /Users/pd/netpd/patches/sumsum.pd p 0.3.5 4 print: sumsum.dumpreqreqreq 4
since creator v1.4.3 it is even possible to have an abslist in an abstraction itself and because i didn't updated sumsum.pd it checks mx_manager.pd twice. mx_manager.pd is an abstraction of i2mx~.pd therefore i could/should remove it from the sumsum.pd abslist.
externals:
atm netpd needs maxlib and zexy. which are included in the pd-netpd packages. if you want to use all the instruments made so far (they are not included in basic netpd and u don't have to use them), you have to add iemlibs and iemmatrix (included in pd-netpd).
iemlibs was added when syntax the nerd joined netpd and ported some of his bag of tricks. at the time i wrote jamx i still had zexy1.3 with an included matrix. but matrix has moved to iemmatrix in zexy2.1. many netpd patches use jamx as mono-note-sequencer and so they all need iemmatrix.
one patch uses creb's blosc~ and resofilt~ but that never worked for me on osx and so i have never heard this synth :-( .
*ultra high sarcastic mode, sensible mind don't read*
no problem
if there is not room enough to put the name of the dependances, like in almost all example patches, or original abstractions, why not replacing the name of the autor with something more usefull...
the only useful about the name is that you can blame the person who wrote the patch ;-)
*end of ultra sarcastic mode*
... seriously: at least you can talk to the author and ask him about the patch. so far i tried to put info into the netpd.org wiki . have you ever have a look there ? i.e. http://www.netpd.org/Sumsum all the sites are here: http://www.netpd.org/NetpdPatches/contents#Sumsum
i was thinking about removing my name from the patches and make it more welcome for changes (see kyle's movie about os)... so far we were cautious in changing others patches. usually we change the name ultrahardcoresynth-eni.pd and do changes and suggest it to the original author... but many authors are not active.. hmm that's an other topic.
what information would you like to see in the patches ?
- dependencies...
what do you mean with "original abstractions" ?
Thanks for letting me advocating my point of view, Patko.
regards eni
On Sat, 2007-06-09 at 11:26 +0200, Enrique Erne wrote:
Many patches won't work out of the box almost always because it will miss an external, or an abstraction, here we come again on the fact that the patches misses some comments,
defining a way to specify the externals a certain netpd-patch uses, is really needed here.
abstractions shouldn't be missed. if so, i'd contact the author of the patch. my patches usually come as a tar.gz archive with all necessary abstractions inside.
if a patch is loaded over netpd and it is missing an abstraction on your machine, then it is definitely a bug of the patch.
many netpd-patches are documented in the wiki and have their own page. usually it is:
http://www.netpd.org/<patchname>
of course, i cannot guarantee, that there will be a page for every available netpd-patch (beside my owns).
again, if you miss come specific documentation, contact me (for netpd-related stuff) or the author (for netpd-patch related stuff).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Fri, 2007-06-08 at 20:28 +0200, Georg Holzmann wrote:
Hallo!
Net-pd is for me the ONLY project where we could have a chance one day for having ALL externals, abstractions, extensions and even the hardware dependant externals in action, without having passing hours about configuring pd, understanding how the object works, etc ...
[...]
and found out that the net-pd project is the best candidate for having a functionnal bundle of all pd candies.
that's what pd extended tries to achieve ...
So, if all the stuff inside this neat project is also documented by comments, it would not only become more efficient than any manual, stage, physical meetings ..., for both learning how to use pd and having fun with it, but it would also decrease the amount of time for developping some add-ons, or optimizing the functionning.
that's what pd extended tries to achieve ...
I don't particulary have fun with opening, testing, closing the hundreds patches grabbed from cvs, pd-extended, pd-list, etc... if all those patches were documented under a single project that is already functionnal, a new user would come to the pd world without the fear of not having the possibility of understanding how the hell this stuff works.
again, pd extended ... However, of course not all patches are working out of the box with pd extended (I think not many will work), but if everyone builds his own distribution system (like netpd in your description) then it will never work ...
a more detailed answer to patco's suggestions might follow. just a few important notes from my side:
netpd's policy (actually my policy) is to use as less externals as possible. all my own netpd-patches depend only on netpd's dependencies (zexy and maxlib) and my plans on the long run are to kick even zexy out, because it was just used, because at that time there was no way in plain pd to do certain list operations. maxlib is basically only there because of [netserver] and [netclient]. in short: netpd officially doesn't support any externals (besides zexy and maxlib). of course, anyone can do with netpd what he/she might want to do and use some fancy externals, but it is very unlikely then that the patch will work on remote computers. the goal of netpd is sharing patches and abstractions, which happens automatically, whereas there is no way to share externals automatically. my opinion is that a 'good' netpd-patch in the sense of netpd, is one, that just works out of the box without having to install additional externals. externals are neither the goal nor the idea of netpd.
also shouldn't the pd-netpd packages considered as a separated pd distribution. they have been added to give some non-pd users a userfriendly start into netpd (since there are many netpd-users, that never do pd themselves). for pd users i'd recommend to install pd-vanilla and the necessary externals or pd-extended. for a pd-user it shouldn't be a big problem to install netpd. as you said, georg, collecting externals is the goal of pd-extended. it was never intended to compete against pd-extended.
my two rappen
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
All of the work done (out of love, not money) by the pd community
should
be applauded. With that said, there is a sense of elitism.
how does this perceived elitism affect your ability to make music? to learn about digitial synthesis?
None. I'm not saying that it affects productivity. I'm just
saying that it exists.
is it an excuse to avoid the work required?
No. Not at all. That's why I'm here. I'm plugging away with
PD.
i've seen lots of beginner questions answered here- sometimes with sarcasm, but mostly with patience [and sometimes with both].
I completely agree. Remember, I'm not singling out the PD
community, which I am a part of. My comment encompassed the whole of the 'audio software' community.
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers.
this seems like an arbitrary line you are drawing. are you talking about people who use presets as opposed to people who can generate their own 'presets'?
I'm not talking about 'presets' at all. I didn't once mention
'presets'. I'm just saying that there is a difference between composers who are also programmers, and composers who aren't programmers yet want to learn to use the technology as an aid to the compositional process. When I say technology here, I'm talking about Logic, Sibelius, Melodyne and shared PD/Csound etc. instruments. I'm talking about composers learning how to USE NOT BUILD shared PD/Csound etc instruments to achieve the sound they want. I'm talking about a more compositional approach to music technology.
and why is academia some kind of measuring stick? in my experience, academia is not the ivory tower you seem to be implying- it is filled with people, some more creative, some less creative, some as greedy as any industrialist you could find in the private sector.
Academia shouldn't be the measuring stick. God knows that in
the 'free thinking' academic atmosphere, dogma runs rampant. [Cue violin here] The reason I mentioned it is because it is relevant to my current situation, as I am looking for a curriculum that fits my needs. And I don't want to dig myself into debt for a program that I don't think I'll get the most out of.
There is still a rigid line that separates the composer and the programmer.
the rigidity is mostly in your mind. composing is very much like programming. instead of working in perl, beethoven worked with staff paper [think punch cards]. how is a repeat sign in a score different than a 'while' loop? how is a fugal theme different than a variable that gets subjected to a certain kind of treatment?
I think the difference is that a composer, in the classical
sense, can simply write down a rest on the staff. He doesn't need to debug or recompile. He doesn't need to connect any outs. He just writes the the music.
What about today's composers who are interested in classical compositional techniques and forms, but who
are,
at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
they are out of luck.
That is my point :-)
what about someone who wants to perform bach's wtc and has no interest in learning the piano?
That is not my point :-) Learning to play? Or learning to
build?
also, as an aside, forget about classical forms: what do *you* have to say? [although if you want make a career out of being an anachronism, maybe the academies of the world will support you]
I admitted that it was a personal rant. I've made not absolute
statements here. Only personal opinion. My point was to step away from the black and white of it all. If I were a beauty pageant contestant my wish would be to rid the world of anachronism or elitism......
:-)
Beautifully written.
One addition:
The elitist attitude may also have something to do with the inverse relationship between spending time programming and spending time socializing. If all one doing in your days is programming a computer, i.e. telling it what to do, one needn't to utilize the more mamallian soft-logic that goes behind social interactions. So one will start to become a bit dull in those areas, and consequently will start to offend people out of being in 'logic mode.'
I'm sure Mr. Spock had to deal with this all the time and I sure as hell know that many people in my undergrad math department did!
~Kyle
On 6/7/07, jared microcosm11@msn.com wrote:
On Tue, Jun 05, 2007 at 03:40:51PM +0100, timon wrote:
Some time ago I was explained the issues of why FTGL libs was not included GEM for the extended OSX release of PD. The answer did not make me any wiser. The conclusion was "Compile it yourself". Its a shame that such a great tool (as GEM could be) is falling into the shade by elitist attitude.
Sometimes I think what can be perceived as 'elitism' is actually just a lack of time. Remember that the people working on this aren't being paid; they are hobbyists producing code in their spare time. They may simply not have the resources to solve your particular problem and
hence
they ask you to try and solve it yourself.
All of the work done (out of love, not money) by the pd community should be applauded. With that said, there is a sense of elitism. I'm not talking only about the PD community here, though. Take the users of the 'industry standard' software, such as Logic and ProTools. It's no secret that many of these users look down their nose at those musicians who use software like Ableton Live, FL Studio, Orion Pro and the like. Then you have the users of more 'academic' software (PD, Max\MSP, Csound, etc.) who often seem to have a sense of superiority; I've seen Csound users look down on Max/MSP users.
I remember a couple of weeks ago, someone on this list posted a piece that used PD as the sound generation source, but he then arranged and mixed the piece in Live. Then someone commented with an elitist tone as to why he used Live at all. Further, I've seen coders look down on those who use anything that isn't purely programming. Everyone loves their tools, and there will always be a sense of pride in those tools. But, my god, its friggin software! No need to be rude.
Then again, a lot of my opinion is based upon interaction with other users over the internet. This, in of itself, may be the cause for this sense of elitism. While talking on forums and lists, I often find that people have very short fuses and are often argumentative or simply look down on 'newbies'. I think that some people are comfortable being rude or unhelpful because there aren't any repercussions from acting in such a way; they don't have to face the person they're communicating with. I'd like to think that a lot of the people who act rude or elite on lists and forums wouldn't act that way if you were to talk to them face to face.
While I'm ranting :-)....In my academic experience, it's often frowned upon to use other's patches in your own compositions because it seems that the patches themselves are the work of art; and it's almost as if this is considered plagiarism. And while I agree that designing patches/programs/instruments IS an art-form, I don't understand why it isn't encouraged for composers to use other people's patches/instruments. Can you imagine if Chopin had to build every piano that he ever played? Thank goodness Hendrix was a guitar player, not a guitar builder.
I think academia needs to recognize that there are many composers who use computers as a means to an end; who make music with the AID of computers; not to make music WITH computers. There is still a rigid line that separates the composer and the programmer. Most Music curriculums are still classically based. Most Music Technology curriculums are programming based. What about today's composers who are interested in classical compositional techniques and forms, but who are, at heart, electronic music composers and want to apply these classical techniques and forms to their electronic compositions with the AID of technology, yet have no interest in programming?
[steps down from his soap box]
:-)
Jared
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm sure Mr. Spock had to deal with this all the time and I sure as hell know that many people in my undergrad math department did!
~Kyle
my turn [steps up on the soap box] Everyone should learn at least calculus and differential equations. Elementary concepts of signal processing (not necessarily DSP) are grounded in diff eq. It makes a good jumping off point for looking at Fourier Transforms, convolution, filters (of course, these are just ordinary 2nd order diff eq with a forcing function (the input)), and the list goes on and on. 'Elitism' is something to be applied to individuals, not whole communities(online or academic or where ever they may reside). Hey, that goes for me too. If you think all musicians should learn at least differential equations... you might be an elitist. [steps down]
Chuck
Well, by the same token, everyone should:
- Know how to conduct an orchestra and jazz big band
- Know how to arrange for orchestra and jazz big band
- Know how to play piano
- Know how to play one wind or string instrument
- Know how to play at least one percussion instrument
- Understand classical and jazz harmonic progressions, +
modern/postmodern ways of dealing with harmony and pitch sets 7. Know how to market one's own music, organize a band, and other applicable business skills
Because those are the kinds of things one learns in composition school. I also did learn to use an analog moog, and had one acoustics class where we learned some of the applicable physics.
People need to understand that in most cases DSP and music are rather separate domains, it's only a few small cases where they come together.
I certainly can't do differential equations, even though at one point I learned dif them. I forgot it all long before it was useful to me... I had no idea that it would ever have a MUSICAL application, it was learned in general university math class. Nobody was even doing serious DSP in 1994 except at certain academic research places, and I don't think the means to do it were available to the average person... I mean, all I'd ever heard of was FM, sampling, and using a computer to sequence at that point. I know it existed out there, but to someone at a state school in the US, midwest, that wasn't cutting edge, it wasn't taught and nobody knew about it (neither faculty or students).
Anyway, my point is, I've never found that my lack of training back then in DSP in any way prevented me from being a successful musician and composer. If I think of my own musical heroes (Mozart, Berg, Mahler, John Cage, Morton Feldman, John Coltrane, Charles Mingus, Cecil Taylor, Duke Ellington) I would be highly surprised if any of them ever knew or needed to know differential equations...
I really think it's just absurd to force all musicians into a model that may only make sense from the software engineering / DSP side of things. I usually am arguing more on the pro-technology side of things, but in this case I think I must remind people : you don't need a computer to make music.
~David
On 6/7/07, Charles Henry czhenry@gmail.com wrote:
my turn [steps up on the soap box] Everyone should learn at least calculus and differential equations. Elementary concepts of signal processing (not necessarily DSP) are grounded in diff eq. It makes a good jumping off point for looking at Fourier Transforms, convolution, filters (of course, these are just ordinary 2nd order diff eq with a forcing function (the input)), and the list goes on and on. 'Elitism' is something to be applied to individuals, not whole communities(online or academic or where ever they may reside). Hey, that goes for me too. If you think all musicians should learn at least differential equations... you might be an elitist. [steps down]
Chuck
hi
On 6/7/07, David Powers cyborgk@gmail.com wrote:
I really think it's just absurd to force all musicians into a model that may only make sense from the software engineering / DSP side of things. I usually am arguing more on the pro-technology side of things, but in this case I think I must remind people : you don't need a computer to make music.
of course that is true. all you really need is your voice [or 'love' if you're a beatle wannabe] ...
but if you want to do electronic music, with any degree of sophistication, you need to learn the tools. i guess i get a bit irritated when people think that computer music should be immediately accessible to them- then get upset when they find out they need to understand something about how computers work with audio in order to get what they want out of them. they think they can just press a button and ...
if you just sit down at a piano and don't know anything about it, you might get some nice stuff out- but it's more a matter of serendipity than anything. you practice to get better.
computers use math to do audio [dsp, convolution, ...]. so you need to study math [not really that much for most applications, but it does help]. and learning a programming language in some way will help too. musicians have been doing math for a long time [at least since pythagorean tunings, if not before]. and i don't even know about chinese or indian or arab or X traditions. [using algebra in a sentence there]
also the jump from composition to programming is really not that great. it's all about flow control ...
On 6/7/07, john saylor js0000@gmail.com wrote:
hi
On 6/7/07, David Powers cyborgk@gmail.com wrote:
I really think it's just absurd to force all musicians into a model that may only make sense from the software engineering / DSP side of things. I usually am arguing more on the pro-technology side of things, but in this case I think I must remind people : you don't need a computer to make music.
of course that is true. all you really need is your voice [or 'love' if you're a beatle wannabe] ...
but if you want to do electronic music, with any degree of sophistication, you need to learn the tools. i guess i get a bit irritated when people think that computer music should be immediately accessible to them- then get upset when they find out they need to understand something about how computers work with audio in order to get what they want out of them. they think they can just press a button and ...
if you just sit down at a piano and don't know anything about it, you might get some nice stuff out- but it's more a matter of serendipity than anything. you practice to get better.
computers use math to do audio [dsp, convolution, ...]. so you need to study math [not really that much for most applications, but it does help]. and learning a programming language in some way will help too. musicians have been doing math for a long time [at least since pythagorean tunings, if not before]. and i don't even know about chinese or indian or arab or X traditions. [using algebra in a sentence there]
also the jump from composition to programming is really not that great. it's all about flow control ...
-- \js [ http://or8.net/~johns/ ]
I can agree with most of the above... But the only other note I'd make is, there are a lot of uses for computers in music, that don't require DSP. Sometimes I feel the DSP people forget about the area of "computer aided composition" - which in many cases involves algorithms but no DSP at all (and often requires the much maligned MIDI standard, because that's the simplest way to get the output into a professional notation program like Finale, for rendering into a score that actual musicians can play). Computer aided composition is simply different than DSP, and while set theory and related maths might be helpful, computer aided composition does not use the same kinds of math that DSP typically requires.
Programming, on the other hand, is quite helpful for computer aided composition - and I'm probably not the only one around that can program without knowing any difficult DSP stuff. But only algorithmic type thinking is really needed for computer aided composition, not programming per se.
Also don't forget, there are some good reasons for a division of labor, abstraction, encapsulation, and black boxes. Sometimes it's nice to have a little black box that works, without worrying about the guts. Without that, we'd be reinventing the wheel every day, over and over!
~David
john saylor wrote:
computers use math to do audio [dsp, convolution, ...]. so you need to study math [not really that much for most applications, but it does help].
I don't think that is true. you definitely don't need to study math to make music. you don't need programming skills to use a computer. pd is a programming language. a pd-patch is a part of an instrument. if you "only" want to use the instrument just start playing.
marius.
One addition:
The elitist attitude may also have something to do with the inverse relationship between spending time programming and spending time socializing. If all one doing in your days is programming a computer, i.e. telling it what to do, one needn't to utilize the more mamallian soft-logic that goes behind social interactions. So one will start to become a bit dull in those areas, and consequently will start to offend people out of being in 'logic mode.'
I'm sure Mr. Spock had to deal with this all the time and I sure as hell know that many people in my undergrad math department did!
~Kyle
That's a great point!
I made a Fink package for FTGL, so you can now "fink install ftgl".
If you want to build Gem like it is in Pd-extended, you should use
this bear of a ./configure line:
cd $(gem_src)/src && ./configure --without-x --without-ImageMagick
--without-tiff --without-jpeg --without-mpeg --without-mpeg3
--without-ieee1394 --without-aviplay --without-avifile --without-
ffmpeg
--with-ftgl-includes=/sw/include --with-ftgl-libs=/sw/lib
--with-pd=/path/to/pd
Or check out the whole source code tree and do this:
cd pure-data/packages make gem cp ../Gem/src/Gem.pd_darwin /Applications/Pd.app/Contents/Resources/ extra
.hc
On Jun 5, 2007, at 10:40 AM, timon wrote:
To whom it may concern,
Some time ago I was explained the issues of why FTGL libs was not included GEM for the extended OSX release of PD. The answer did not make me any wiser. The conclusion was "Compile it yourself". Its a shame that such a great tool (as GEM could be) is falling into the shade by elitist attitude. Bugger, time to switch.
T.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
-
Charles Henry -
chris clepper -
Chris McCormick -
David Powers -
Enrique Erne -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
hard off -
jared -
john saylor -
Kyle Klipowicz -
marius schebella -
Nikola Jeremic -
Patco -
patrice colet
-
Roman Haefeli -
timon