Hi, Adam Lindsay schrieb:

Frank Barknecht said this at Wed, 12 Feb 2003 17:59:39 +0100:

...

how you open a tar.gz archive with Pd patches.

Waitaminute... How *do* you open a tar.gz archive with Pd patches?

I meant "tar.gz including Pd patches", but actually I could open them with Pd and ggee's "shell" object ;)

But I'm sorry if I sounded a bit harsh. It's just, that I would love to try some Max-patches in Pd but most Apple-Users pack in stuffit format, which I didn't manage to open on Linux (I did install the Basilisk Mac emulator, but somehow even that wouldn't work...)

ciao

Frank Barknecht

Hi, Adam Lindsay wrote:

So the freeware expander available at: http://www.stuffit.com/stuffit/linux/index.html didn't work? (Ignore the rest of the software they seem to want you "evaluate"... the rest of us do.)

The Linux version isn't freeware, it seems to stop working after some time. I did have a version, but it doesn't work anymore. And now, being a headstrong fundamentalist ;), I refuse to download a 1.9 MB expander again to unpack 0.1 MB of patches. This Expander would only "expand" my download time.

But I'm getting DSL in 3-4 weeks. I think, I'll download Stuffit again then.

Regards,

Frank Barknecht

Hallo, dmotd hat gesagt: // dmotd wrote:

the macutils package handles some mac compression, but perhaps not the newest forms (last updated in 1992!), that said i have used macutils/macunpack to unstuff files in the past..

Unfourtunatly macunpack doesn't work with current .sit files anymore. I tried.

Greetings,

Frank Barknecht _ ______footils.org__

Lets face it.. people who can afford macs can afford max......(snigger) No but seriously, I use and have both, but i dont find pd more difficult than max to follow/use.. In many ways I prefer the simpler nature of patch appearance especially when i am trying to explain a process to someone.. (its harder to hide stuff)

But I can see how some users are alienated by aspects of the software. However I feel this occurs more in the installation/configuration area rather than the GUI. I was thrown slightly by the commandline options in dos when i first started using pd.. And if it wasn't for Adams great OSx packages I would still be struggling with my setuid and -rt stuff. (MacOS/unix is a real brush it under the carpet job).

From my point of view most barriers to PD usage have been admin/install

things like. "We can't support that" and "Users can't be using console commands!" and "Wheres the diskimage" and "Users don't like config scripts" and "why aren't the docs/application visible in the finder" Anyway.. i think i've given my 2 penny.. so I'll shut up now..

Also.. how can you still charge £800 for a DSP training session when the program is free Expensive/stylish apps (and computers) seem to connote higher quality programming/creativity to most punters. (But thats when people try to buy creativity.. not learn it) Hopefully OSx will break that barrier down a bit..

no.. i really will shut up now :)

Tom http://www.nullpointer.co.uk

...

You know what? He's right! PureData's GUI sucks compared to MAX's! Moreover, jMax's GUI sucks compared to MAX's, and PureData's GUI sucks compared to jMax's (except for speed)!

i don't want bloated GUIs, PD's perfect // low-tech // what we like

( anyway, that boring conversation already happened, focusing on __TASTE__ rather than on __USABILITY__/__IMPROVEMENT__ )

• programmers are not assigned to particular projects, except out of their own interest, or because of a friend wanting a bug fix, or because of paid contracts (usually about specific additions);

i hope we'll never speak of contract workers here )) shit...

• programmers are attracted to software that already meet certain criteria of usefulness and adequacy;

why keeping that distinction over and over between users and programmers ??? it's just apple/microsoft/corporate point of view !!

i was born a user...

So they want me to sell them a candy software they can chew on until the next software realease, or they want me to help them use a candy software, which I don't want too. They are totally integrated in the market economy, I'm not. Culture clash.

))))

i can't see why you'd want to install PD for these people, maybe you should make clickable standalones ??? ( we can with pd as is really )

i also meant : the programmers often think users are dumb and can't manage to compile a program, that's what's it's all about, i think they should learn, otherwise, they'll be addicted to big gurus out there.

cheers,

sevy/yves

the real thing that annoys me is that PD __HAS__ to compared with MAX, but MAX has really unhandy features.

sending symbols with gui objects ( sliders, radios, ... ) is something much more elegant and powerful than making segmented patch chords !!!

so, it's a different way of doing things that i find much more convenient than any other patcher.

PD doesn't have to imitate MAX in any way, people coming from MAX have to adapt ( and to learn how to compile )

cheers,

sevy/yves

PD is just perfect as it is. It'll run on any machine, it's open-ended and in constant development and it's free. What more could you ask for? Say, um... How's cycling74 doing on that MacOSX port? Oh, sorry to hear it. What about that Windows port they've been talking about for who knows how long? A couple of years ago I participated in an exhibition in Denmark with some Max stuff on 5 computers, they had to go to Sweden to find rental Macs. Wish I had known about PD then (actually it was a guy at that show that told me about PD).

If someone doesn't think PD is suitable for whatever they're trying to do, they're probably just trying to do the wrong thing, hahaha. If they'd rather shell out a pile of money for a copy of Max so that they can reboot their Mac out of sweet sweet OS X and into dull defunct OS 9, let 'em.

Pall

On Mi›vikudagur, febrúar 12, 2003, at 08:35 , Marc Lavallée wrote:

Le mer 12/02/2003 à 15:23, Yves Degoyon a écrit :

...

i can't see why you'd want to install PD for these people, maybe you should make clickable standalones ??? ( we can with pd as is really )

That's an idea. Painful but very useful.

...

i also meant : the programmers often think users are dumb and can't manage to compile a program, that's what's it's all about, i think they should learn, otherwise, they'll be addicted to big gurus out there.

And I meant: the users like to think they are dumb. The only thing we can do is to confort them in their belief and slowly make them realize they're not so dumb after all. PD needs a marketing strategy, something like "Think <whatever>". What about a clickable installer, integration of many externals, good documentation and tutorials? Thats's what users are expecting, nothing less. No need for big gurus for this to happen.

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

Pall Thayer myndlistamaður/kennari artist/teacher Fjölbrautaskólanum við Ármúla (www.fa.is) http://www.this.is/pallit _____________________________________

Le jeu 13/02/2003 à 16:36, delire a écrit :

what do you mean PD needs a "marketing strategy"? what's wrong with the PD user base growing at the speed it already is?

PD is not (yet) considered good enough to be teached, at least not on my side of this world, because it does not appeal to non-technical people. I was not expecting it could be a problem, but actually it is becoming one for me. I'm not saying everybody should care about my situation, but I have good reasons to think PD still need a bigger user base, althought it's not of major importance.

do you know what a "market" is? what is this "market" you speak of. it's free man, no not "free market", _really free_ there is no hype, no alpha, and nothing to sell..

Do you know what "free" means? "Free" is very marketable, and there's nothing wrong with money if we don't use it against our liberty. A poet from Québec wrote: "La liberté n'est pas une marque de yogourt" which translates as "Liberty is not a yogurt trademark"; yes, we do have a yogurt named "Liberté"... Read http://gnu.org/

Marketing PD is not necessarly about doing commercials on TV, it's about spreading something we thing is good. If PD is not good for its target audience, we can try to reduce the gap, by making PD easier to install and use, and by teaching about PD. No bad capitalism involved. It's already an ongoing process, so maybe I was too impatient.

-- Marc

I believe Thomas Grill said this around Wed, 12 Feb 2003:

Well, to me that sounds a bit too much like "on a mission". Why does "the word" PD have to be spreaded to a larger audience?

It doesn't. But I think of it as good karma. "Here, I found something I like," I say, "maybe you will like it too."

Also/as a result... more users (to a certain point) means more feedback and refinement. Is Pd the same system now compared to what Miller might have come up with without community feedback, without users?

Isn't it rather the wish for a perfect system for one's own needs, be it this or that one?

But I would agree more with your earlier statement:

For me, the main reason to trust in PD is the fact that i'm silly enough to waste my time with developing basics (and neglecting art) and hoping that something really powerful can come out in the end if more people are thinking in the same way.

The tool is its own art... that's more interesting to me than a single instantiation using it (sometimes sadly so).

I'm also my conviction that a really good performance system can't be designed by a developer doing it for the "user" - it can only be done by someone who is using it on a daily basis.

I think it takes a very special user/developer/designer to simultaneously design and use a system to the point of maturity. Yes, it could be a very interesting, idiosyncratic system. But I think one way of thinking taken too far creates hidden constraints in a system. (Constraints in themselves aren't bad, but when one is blind to them, it can be a detriment.)

This has turned into an interesting thread. Cool.

adam

----- Original Message ----- From: "Marc Lavallée" odradek@videotron.ca To: "pd-list" pd-list@iem.kug.ac.at Sent: Wednesday, February 12, 2003 9:01 PM Subject: Re: [PD] PD usability

...

Le mer 12/02/2003 à 14:12, Yves Degoyon a écrit :

...

why keeping that distinction over and over between users and programmers ???

Because that's what users wants, and because sometimes we must deal with them. I'd really like to simply ignore them, but that's not always possible. They don't want help, they want fancy products, that's how they've been raised. They see me as a programmer (which I'm not) because I can install, configure, use, integrate and modify many types of softwares on different machines. So they want me to sell them a candy software they can chew on until the next software realease, or they want me to help them use a candy software, which I don't want too. They are totally integrated in the market economy, I'm not. Culture clash.

...

i was born a user...

We all did, but you evolved as a programmer. 99.9% of the population won't. So either we keep PD only as a research or hobbyist tool, or we try to put some sugar on it to please all those "users" out there. At some point they'll hopefully agree why PD (or jMax) are better tools for reasons they don't want to understand now. We could even make commercial products based on PD, if its license allows it, because that's the only language most users really understand now. It's being done with many other free softwares, so why not PD? The MSP plugin for Max is PD, so that should be possible to sell a "better" PD. I don't care if they copy and use the commercial version (they would for sure), because the goal would be to made them switch to the free version. It would bring PD to a larger audience while keeping it free. The market is certainly not too small. It would give university students access to softwares they usually can't afford or are reluctent to even try. The advent of the OSX platform is giving us an opportunity we should consider. Maybe I simply don't understand what the market economy is all about...

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

--

Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Le mer 12/02/2003 à 15:36, Thomas Grill a écrit :

Well, to me that sounds a bit too much like "on a mission".

If I'm alone thinking this mission is worth it, I won't do it.

Why does "the word" PD have to be spreaded to a larger audience?

It doesn't have to: I was the first against the idea of advertising PD on Freshmeat, because of all those lazy users. But if we wait a couple of years it'll be late to convince new Max users that PD is good enough. We won't feel too sorry because we'll be happy using PD. But still, those "users" are everywhere now, like borgs, and I feel even more alone than when I first discovered the beta version of Max, 13 years ago. A big chunk of my computer culture is like a Max patch, but now I use PD. So I hope those interested to build a viable community of PD users (not only hackers) will understand my concerns.

One idea would be to distribute PD with as much stuff as possible, making sure all files (externals, help patches, documentation, etc) are packaged in a consistant way. It really is difficult for beginners to use and enjoy PD in the first place, and that should not be the case.

Yves Degoyon wrote:

the real thing that annoys me is that PD __HAS__ to compared with MAX, but MAX has really unhandy features.

Imagine the opposite: Max users "forced" to compare Max to PD... :-)

sending symbols with gui objects ( sliders, radios, ... ) is something much more elegant and powerful than making segmented patch chords !!!

I agree. Totally !!!

PD doesn't have to imitate MAX in any way, people coming from MAX have to adapt ( and to learn how to compile )

We also need to adapt to Max users. Then maybe some of them will learn how to compile, but I don't care; PD was not designed as a compiling exercice...

Adam Lindsay wrote:

The tool is its own art...

Most artists would not agree, because they refuse to deeply understand their tools; this is part of our occidental culture, and we must accept it. We can decide that they are full of <>, but the enonomical reality is that technical people are serving artists because we are enjoying their art (well, sometimes). In Bali, "art" means "life", but I'm not balinese...

Ok, Time out.

-- Marc

I'll put my day job hat on here (Chief Technical Architect for a software house).

IF we want PD to be used outside of the hobbiest community then it does need serious work on things like installing,look and feel, documentation and configuration (midi,soundports etc). For most casual users these things are not easy or perhaps present to high an entry cost.

However for all of us these things are not a problem (otherwise we wouldn't be here).

So the question is - Do we want a wider audience? Judging by the responses to this discussion I would say the answer is no - no one here is prepared to do the (lets face it fairly dull) work of making this a proper product.

If *you* (whoever you are) want it to be a proper product you will have to do the work yourself or convince someone else to do so. The rest of us have

a tool which meets our needs.

Sorry to be blunt about this but I did say I had my day job hat on. :-)

cheers

mark

If it where me that wanted to make PD more "producty" (technical term that :-) - and its not - I already have enough joy with this at work with users/support/testing/load testing/a development team/a dept. head/etc. - Then I would try to establish a small group of volunteers to do the work. I am sure the rest of the community would support such an effort if it didn't mean much work on their part.

The key areas I see as being vital are;

installer - not always an easy job 'cos of the platform thing (and the quality of the tools). As a guide I have had a team member put in about 6 man months over the last two years on our installer.

Config - midi/audio selection would have to be a preferences dialog for the more casual user. I guess this would have implications on how PD starts up too.

GUI - you can argue its fine until you are blue in the face - people are used to and expect pretty interfaces - if you want minimalist/functional then it needs to be *designer* minimalist functional (think Peter Saville/factory records). Its just the way it goes.

Docs - there needs to be a reference manual. Again you can argue about it all you like - not having one means that the beginner has to do a lot more work to get into the product.

Support - who is going to provide support to people. What happens when the mailing list is full of people going - "it does't work on my pc..why?" or "I NEED feature X..why can't you make it do that"

Don't get me wrong - PD is just great as it is as far as I am concerned

• what

I am talking about is making it accessible to a wider audience. It will grow larger as time goes by and by having a high level of knowledge needed for entry we make life easier for ourselves.

Again - not trying to pour water on ideas but if you want to make PD accessible to a wider audience you need to consider what is involved

cheers

mark

-----Original Message----- From: pd-list-admin@iem.kug.ac.at [mailto:pd-list-admin@iem.kug.ac.at] On Behalf Of Marc Lavallée Sent: 12 February 2003 22:37 To: 'pd-list' Subject: RE: [PD] PD usability

Le mer 12/02/2003 à 16:59, mark a écrit :

...

Sorry to be blunt about this but I did say I had my day job hat on. :-)

I actually resigned from a well paid job in a university center because I was unable to bring artists to use free software and be more responsible. I had to manage a bunch of projects, buy computers and softwares, and program "art". It was a stupid and impossible mandate, because artists (especially students) must do their own stuff, not always rely on programmers to hold the mouse for them. Of course, most artists were asking for Macs/Max/MSP/Jitter, leaving little money for anything else, including humain brain juice.

So for me, a "better" PD would have been cool. I won't accept such a job unless artists agrees to change their tools and their attitude toward technology. But we need to help them a little bit, or I might never work with them again.

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at

http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

Indeed - this is something annoying me to. I want a reference manual. I'm working on two new externals and then I am going to look into this. There must be a way to autogenerate either the patches or reference pages. My ideal would be to take the patches and autocompile them into a PDF.

I will be reopening this debate in a week or two when I am ready to do something about it.

cheers

mark

-----Original Message----- From: pd-list-admin@iem.kug.ac.at [mailto:pd-list-admin@iem.kug.ac.at] On Behalf Of Matthew Nish-Lapidus Sent: 12 February 2003 23:13 To: 'pd-list' Subject: Re: [PD] PD usability

i would have to say the biggest issue that i have with PD is docs. MAX's help files are amazing.. if PD had help files like that there would be a lot less difference between PD and MAX in the learning phase.

matt.

----- Original Message ----- From: "mark" mark@junklight.com To: "'Marc Lavallée'" odradek@videotron.ca; "'pd-list'" pd-list@iem.kug.ac.at Sent: Wednesday, February 12, 2003 5:59 PM Subject: RE: [PD] PD usability

If it where me that wanted to make PD more "producty" (technical term that :-) - and its not - I already have enough joy with this at work with users/support/testing/load testing/a development team/a dept. head/etc. - Then I would try to establish a small group of volunteers to do the work. I am sure the rest of the community would support such an effort if it didn't mean much work on their part.

The key areas I see as being vital are;

installer - not always an easy job 'cos of the platform thing (and the quality of the tools). As a guide I have had a team member put in about 6 man months over the last two years on our installer.

Config - midi/audio selection would have to be a preferences dialog for the more casual user. I guess this would have implications on how PD starts up too.

GUI - you can argue its fine until you are blue in the face - people are used to and expect pretty interfaces - if you want minimalist/functional then it needs to be *designer* minimalist functional (think Peter Saville/factory records). Its just the way it goes.

Docs - there needs to be a reference manual. Again you can argue about it all you like - not having one means that the beginner has to do a lot more work to get into the product.

Support - who is going to provide support to people. What happens when the mailing list is full of people going - "it does't work on my pc..why?" or "I NEED feature X..why can't you make it do that"

Don't get me wrong - PD is just great as it is as far as I am concerned

• what

I am talking about is making it accessible to a wider audience. It will grow larger as time goes by and by having a high level of knowledge needed for entry we make life easier for ourselves.

Again - not trying to pour water on ideas but if you want to make PD accessible to a wider audience you need to consider what is involved

cheers

mark

...

-----Original Message----- From: pd-list-admin@iem.kug.ac.at

[mailto:pd-list-admin@iem.kug.ac.at]

On Behalf Of Marc Lavallée Sent: 12 February 2003 22:37 To: 'pd-list' Subject: RE: [PD] PD usability

Le mer 12/02/2003 à 16:59, mark a écrit :

...

Sorry to be blunt about this but I did say I had my day job hat on. :-)

I actually resigned from a well paid job in a university center because I was unable to bring artists to use free software and be more

responsible. I had to manage a bunch of projects, buy computers and softwares, and program "art". It was a stupid and impossible mandate, because artists (especially students) must do their own stuff, not always rely on programmers to hold the mouse for them. Of course, most artists were asking for Macs/Max/MSP/Jitter, leaving little money for anything else, including humain brain juice.

So for me, a "better" PD would have been cool. I won't accept such a job unless artists agrees to change their tools and their attitude toward technology. But we need to help them a little bit, or I might never work with them again.

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at

http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

I don't want to get rid of the patches. What I want is a reference book I can browse through looking for ideas etc. *as well*. So basically assuming that authors will write help patches then it needs to be generated from those. PDF will look the same (but won't work but could be printed for example).

cheers

mark

-----Original Message----- From: Matthew Nish-Lapidus [mailto:mattn-l@rogers.com] Sent: 12 February 2003 23:24 To: mark; 'pd-list' Subject: Re: [PD] PD usability

i don't know if PDF is the best solution.. the best thing about good doc patches is that they're usable patches.. you can just copy parts of them to save time.

matt.

----- Original Message ----- From: "mark" mark@junklight.com To: "'Matthew Nish-Lapidus'" mattn-l@rogers.com; "'pd-list'" pd-list@iem.kug.ac.at Sent: Wednesday, February 12, 2003 6:21 PM Subject: RE: [PD] PD usability

Indeed - this is something annoying me to. I want a reference manual. I'm working on two new externals and then I am going to look into this. There must be a way to autogenerate either the patches or reference pages. My ideal would be to take the patches and autocompile them into a PDF.

I will be reopening this debate in a week or two when I am ready to do something about it.

cheers

mark

...

-----Original Message----- From: pd-list-admin@iem.kug.ac.at

[mailto:pd-list-admin@iem.kug.ac.at]

...

On Behalf Of Matthew Nish-Lapidus Sent: 12 February 2003 23:13 To: 'pd-list' Subject: Re: [PD] PD usability

i would have to say the biggest issue that i have with PD is docs.
MAX's help files are amazing.. if PD had help files like that there would be a lot less difference between PD and MAX in the learning phase.

matt.

----- Original Message ----- From: "mark" mark@junklight.com To: "'Marc Lavallée'" odradek@videotron.ca; "'pd-list'" pd-list@iem.kug.ac.at Sent: Wednesday, February 12, 2003 5:59 PM Subject: RE: [PD] PD usability

If it where me that wanted to make PD more "producty"

(technical term

...

that :-) - and its not - I already have enough joy with

this at work

...

with users/support/testing/load testing/a development team/a dept. head/etc. - Then I would try to establish a small group of

volunteers

...

to do the work. I am sure the rest of the community would

support such

...

an effort if it didn't mean much work on their part.

The key areas I see as being vital are;

installer - not always an easy job 'cos of the platform

thing (and the

...

quality of the tools). As a guide I have had a team member put in about 6 man months over the last two years on our installer.

Config - midi/audio selection would have to be a preferences dialog for the more casual user. I guess this would have

implications on how

...

PD starts up too.

GUI - you can argue its fine until you are blue in the face

• people

...

are used to and expect pretty interfaces - if you want minimalist/functional then it needs to be *designer* minimalist functional (think Peter Saville/factory records). Its just

the way it

...

goes.

Docs - there needs to be a reference manual. Again you can

argue about

...

it all you like - not having one means that the beginner

has to do a

...

lot more work to get into the product.

Support - who is going to provide support to people. What

happens when

...

the mailing list is full of people going - "it does't work on my pc..why?" or "I NEED feature X..why can't you make it do that"

Don't get me wrong - PD is just great as it is as far as I am concerned

• what

I am talking about is making it accessible to a wider audience. It will grow larger as time goes by and by having a high level of knowledge needed for entry we make life easier for ourselves.

Again - not trying to pour water on ideas but if you want

to make PD

...

accessible to a wider audience you need to consider what is involved

cheers

mark

...

-----Original Message----- From: pd-list-admin@iem.kug.ac.at

[mailto:pd-list-admin@iem.kug.ac.at]

...

On Behalf Of Marc Lavallée Sent: 12 February 2003 22:37 To: 'pd-list' Subject: RE: [PD] PD usability

Le mer 12/02/2003 à 16:59, mark a écrit :

...

Sorry to be blunt about this but I did say I had my day

job hat on.

...

...

:-)

I actually resigned from a well paid job in a university center because I was unable to bring artists to use free software

and be more

...

responsible. I had to manage a bunch of projects, buy computers and softwares, and program "art". It was a stupid and

impossible mandate,

...

because artists (especially students) must do their own stuff, not always rely on programmers to hold the mouse for them. Of

course, most

...

artists were asking for Macs/Max/MSP/Jitter, leaving little

money for

...

anything else, including humain brain juice.

So for me, a "better" PD would have been cool. I won't

accept such a

...

job unless artists agrees to change their tools and their attitude toward technology. But we need to help them a little bit,

or I might

...

never work with them again.

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at

http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list mailing list PD-list@iem.kug.ac.at

http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

errm, i believe the last time i installed pd was with the gruellingly challenging command:

'apt-get install pd'

for the similarly terrifying, strategically impossible debian distribution ;)

again, a progress bar does not make installation 'easier' only more comforting. this is the question here. anyway, i tend to distrust operating systems that allow me to install software with a double click.

yesterday a friend couldn't stop telling me "just how easy" using the planetCCRMA system was [30 free applications fresh from the web, one command]. the time it took him to install these applications is about the same amount of time [i hear] it takes to install Logic.

i understand however installing software under windows or macOSX is often more difficult.

julian

On Wed, 12 Feb 2003 22:59:41 -0000 "mark" mark@junklight.com wrote:

//If it where me that wanted to make PD more "producty" (technical //term that :-) - and its not - I already have enough joy with this //at work with users/support/testing/load testing/a development //team/a dept. head/etc. - Then I would try to establish a small group //of volunteers to do the work. I am sure the rest of the community //would support such an effort if it didn't mean much work on their //part. // //The key areas I see as being vital are; // //installer - not always an easy job 'cos of the platform thing (and the //quality of the tools). As a guide I have had a team member put in //about 6 man months over the last two years on our installer. // //Config - midi/audio selection would have to be a preferences //dialog for the more casual user. I guess this would have implications //on how PD starts up too. // //GUI - you can argue its fine until you are blue in the face - people //are used to and expect pretty interfaces - if you want //minimalist/functional //then it needs to be *designer* minimalist functional (think Peter //Saville/factory //records). Its just the way it goes. // //Docs - there needs to be a reference manual. Again you can argue //about it all you like - not having one means that the beginner has to //do a lot more work to get into the product. // //Support - who is going to provide support to people. What happens when //the mailing list is full of people going - "it does't work on my //pc..why?" or //"I NEED feature X..why can't you make it do that" // //Don't get me wrong - PD is just great as it is as far as I am concerned //- what //I am talking about is making it accessible to a wider audience. It //will grow larger as time goes by and by having a high level of knowledge //needed for entry we make life easier for ourselves. // //Again - not trying to pour water on ideas but if you want to make PD //accessible to a wider audience you need to consider what is involved // //cheers // //mark // // // //> -----Original Message----- //> From: pd-list-admin@iem.kug.ac.at //> [mailto:pd-list-admin@iem.kug.ac.at] On Behalf Of Marc Lavallée //> Sent: 12 February 2003 22:37 //> To: 'pd-list' //> Subject: RE: [PD] PD usability //> //> //> Le mer 12/02/2003 à 16:59, mark a écrit : //> //> > Sorry to be blunt about this but I did say I had my day job hat on. //> > :-) //> //> I actually resigned from a well paid job in a university //> center because I was unable to bring artists to use free //> software and be more responsible. I had to manage a bunch of //> projects, buy computers and softwares, and program "art". It //> was a stupid and impossible mandate, because artists //> (especially students) must do their own stuff, not always //> rely on programmers to hold the mouse for them. Of course, //> most artists were asking for Macs/Max/MSP/Jitter, leaving //> little money for anything else, including humain brain juice. //> //> So for me, a "better" PD would have been cool. I won't accept //> such a job unless artists agrees to change their tools and //> their attitude toward technology. But we need to help them a //> little bit, or I might never work with them again. //> //> -- //> Marc //> //> _______________________________________________ //> PD-list mailing list //> PD-list@iem.kug.ac.at //http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list // // //_______________________________________________ //PD-list mailing list //PD-list@iem.kug.ac.at //http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list // //

I love pd

it has taught me more about multi-platforms, electroacoustics, plugins,externals,ports,midi, RT, in the last 5 years (which i think was 0.27 if i am not completely forgetfull. I have tried to show dozens of people pd and they will usually say

"you realise now i have no idea what you are talking about Pat"

or

they will mention Miller, but rare few at least locally here use it. i have successfully used pd for several eA concerts then afterwards a few folks will ask about it then i will begin to tell them how i use it and they will usually say

"you realise now i have no idea what you are talking about Pat"

pd is a wonderful tool

sometimes it's nice to be arcing on that learning curve (LOL)

cheers~

Pat

On Wed, 12 Feb 2003, Andy Schmeder wrote:

Speaking of which, what happened to the pd-externals package?? It seems to be missing from the debian distro these days.

The pd-externals package still exists, it is a demudi only thing (maybe planet ccrma has it too, I don know ..)

deb http://devel.demudi.org/demudi woody demudi

I am planning to include it into Debian proper, but it is too experimental at the current stage.

In general, about the usability thread: These topics pop up now and then on the list. Maybe we write the ideas down, put them on pure-data.sf.net as a TODO list and hope that someone will implement these ideas some day and contribute them.

Guenter

On Thu, 13 Feb 2003, Frank Barknecht wrote:

Hi, guenter geiger schrieb:

...

The pd-externals package still exists, it is a demudi only thing (maybe planet ccrma has it too, I don know ..)

CCRMA only has zexy, Gem and ggee. I had a discussion with Fernando regarding joining forces with the CVS. I'd like to see rpm-packages with similar names and contents as the Debs, and Fernando agreed with that. This is necessary for Demudi/Rehmudi anyway, isn't it?

Maybe we should try to convince Fernando to put his rpm-scripts into the souceforge CVS? Then one could build rpms from the CVS contents as easy as the Debs.

Btw regarding my externals and other externals depending on flext in general. I've come to the conclusion, that they should build-depend on pd-flext, and not, as it is currently the case, look for flext in a repository's path. So we could maybe package all flext-externals together into a package called pd-flexternals, but build them after pd-flext is installed? This could include Thomas single externals like idelay and xsample as well.

Yes, this is a good idea. I am not very happy with the build system how it is now, but I do not have the time to change anything, so everyone who has new ideas and improvements is welcome to implement them.

Maybe we should make a release for that. We need someone who builds the externals on Windows and OSX too.

Guenter

On 13 Feb 2003, Fernando Pablo Lopez-Lezcano wrote:

I'm looking at the repository now. As far as I can tell there are debian packaging instructions for pd-linux(ogg stuff? should be called ogg?), pd-zexy, pd-flext and pd-osc (but I don't know much about the debian build process). What about the others? I was starting to do a spec file for the whole thing (spliting them to separate packages) and there are several issues. One is versioning. I think it would be better to split the collection into the component "subcollections" and maybe some of them (I have not checked all) do not have versioning information...

You can group the externals into different categories.

1. This is the main category

These externals have different authors, are most of the time single externals. The can be built with the build/linux/makefile. I would prefer to have all externals in this format, because it is more natural to use them, doesn't need commandline flags to load them, etc.

(The ogg externals are there too, but they use a hackish way to link to the ogg libraries, I amnot sure if it should stay this way).

2. Different "libraries", collections of externals.

Although the goal is to have as single externals, we still have some libraries that can not be split (different reasons for that).

This currently is: flext (and its externals, this will stay this way) OSC zexy (can't remember why, maybe because I was too lazy to sort out the problems I had when building them as standalone)

The debian build is happening in a makefile called debian/rules which "cd's" to the different subpackages and builds.

Proposal:

What about moving these directories that can not be built as single externals out ot "externals" and give them their own subproject. This way, externals based on flext would be part of flext, and built together with flext. ?

Guenter

...

Btw regarding my externals and other externals depending on flext in general. I've come to the conclusion, that they should build-depend on pd-flext, and not, as it is currently the case, look for flext in a repository's path. So we could maybe package all flext-externals together into a package called pd-flexternals, but build them after pd-flext is installed? This could include Thomas single externals like idelay and xsample as well.

Is there a way for each external to state its dependencies? Or do dependencies have to be compiled "by hand"? (sorry if this has an obvious answer to pd gurus)

I would imagine it would be hard to create a version for a composite package like the one suggested if all the externals are coming from different sources. I guess all packages could have the cvs date as the version, but that would make it impossible to track the evolution of individual packages. I think I would prefer individual packages (with proper dependencies, of course) so that you can mix and match stuff as you need it.

-- Fernando

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

On Sat, 15 Feb 2003, Frank Barknecht wrote:

It is very tempting to compile flext-ernals together with flext, because of compiler issues, but they should get a package of their own, or be included in the pd-externals package. The alternative would be to build-depend on a installed pd-flext-package. This looks cleaner, but might make things very complicated in the end (i.e. one would need to take care of version-depends and so on). But somehow putting flext-ernals in the same package as flext just *feels* wrong.

The problem with the build depends is that this is a Debian specific solution. In this case we have to come up with a proper configure script (and this is prop. true for every external depending on "unusual" libraries).

*** Other dependencies ***

Having externals only rely on themselves makes things easy for packagers and compilers. But 85 % of my externals depend on other libraries, and in this case it makes sense, IMO (of course). For example (flext-)iiwu makes iiwusynth available to Pd, which is very useful and it would be a wasted effort to try to reimplement libiiwusynth just for a 257 lines long external. But then flext can depend on STK and SndObj, to make a lot of things easier for external developers.

agreed.

Libraries might not be available and need to be packed as well (as you did with SndObj). Because of this, I would vote for a pd-externals package like now including externals without dependencies. But what to do with the rest? Each package might need different libraries, some need flext, some fftw, ...

I have no clear idea how to structure this, if we don't want to have packages with only one external inside.

You are right. The problem is not easily solveable. Sounds very much like the Gem dilemma.

*** Single externals are easy to install, libs are not ***

Libs require the user to add them to their pd-path. I'd prefer it, if a user will be made aware of this, maybe at installation or in the package README. So votes++ for a pd-extlibs package.

These thoughts are a bit chaotic, but might be valid for a deeper discussion.

Not at all, these discussions are important, and after all, using externals is one of the other "usability" issues that have to be solved.

I'll think it over again, and may come up with a more detailed list of the "higher level" externals.

Guenter

[and to follow yves on this one] part of the appeal of PD is that it is not candy coated: WYS *is* WYG etc..

anyway, WYSIWYG is just a lie ))) ( i've been bored with such applications long enough )

i think we should not provide binary distros and force somehow the users to become more aware of what's really in their engine ( PD is not a consumer product, standalones would be ).

upgrade users vs. downgrade software, haha ...

no, let's say, do binary distros if you feel users can't learn compilation basics, but, well, be bored with "version X.Y is not compatible with my debian x.y.z, blah, blah, blah, ... )

sevy/yves

On the subject of "why Pd GUIs are bad in performance" check out GrIPD, Joe Sarlo's GTK-based GUI builder for Pd:

http://crca.ucsd.edu/~jsarlo/

cheers Miller

On Wed, Feb 12, 2003 at 06:59:37PM +0100, martin pi wrote:

some points to this - or "why is pd really not friendly to the user"

1. it has modes (as opposed to modeless

environments (this is why people do not like vi, too). modes are hard to understand - especially for mac people since the mac interface is traditionally modeless

2. it does not support the usual features like

drag and drop, cut & paste (in message boxes for example) thus it is inconsistent (and that is the main point why people from the commercial side have problems with free software)

3. it does not have a clear rythm of behaviour -

sometimes it is fast as light, sometimes just stuck. most times inbetween. worst when audio processing is on (and realtime on my comp).

yet it is mostly verb-noun based thus good in the general flow

so much for the user interface. have to say that i really like it by the way.

martin

On Wed, 12 Feb 2003 eh@ixi-software.net wrote:

...

hi

i have been involved lately in software usability stuff and i don't really think PD is bad at all. there are some issues about the installation and
the externals. sometimes its difficult to know how to make them work.
etc... but they are minor if you think that you are getting it for FREE. the interface of PD and PD environment are ok and they are very logical and consistent in terms of usability. I would say that the interface is specially "transparent" compare to many other environments or programs.

this is my opinion, and i am not a big PD user at all. if he would be helping maybe PD would be better.

...

I had a strange conversation yesterday with a teacher who basically said that free software sucks because of usability issues, and that he'll refuse to teach Pure Data because Max is vastly superior at the cognitive level. The segmented patch cord functionnality seems to be of major importance to him. He also seemed quite revolted by the installation process of the OSX version. So to him, the whole idea of free software is simply irrelevent. This man (who call himself an anarchist, go figure) is telling all those young people that they must pay a fortune to get a fancy Mac and a Max/MSP/Jitter licence.

I'm the only one in my community to use free software for multimedia production. I'd really like my people to use free software, but they simply don't want to, because the very second they are in touch with "no so easy to use" softwares, they almost puke. How could we make PD better so these people would agree using free software? I stopped using Max because of its restrictive license, and I prefer PD to jMax because it's lighter and faster.

Most of us don't need fancy segmented patch cords and graphical objects with a puffy look, but can we focus a little bit on the graphical interface issues? I need those Mac addicts to use PD. I like being in touch with people on this list, but I also need real people (those I get in touch with everyday) to use the same tools than me.

-- Marc

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

   		martin pi

   		http://attacksyour.net/pi











       www.machfeld.net

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

On Fri, 14 Feb 2003 14:57:04 -0500 (EST) Mathieu Bouchard matju@sympatico.ca wrote:

Anyway, Gripd doesn't replace PD's patcher editor, so I don't think it is relevant to the discussion...

No, but you can design a nice looking, GTK+ gui for your performance patches, especially if you want to share them with others. But, then, maybe GTK is not your thing, I can understand that.

Speaking of GriPD, it needs tabs! (IMHO)

ciao

./MiS

Hi,

By default, GrIPD looks for gripd.py in ../gripd (relative to PD executable). To change this, send the gripd object the message "set_path <path>" where "<path>" is the path to the directory containing gripd.py. See the included README.txt file and the gripd.pd patch in gripd/examples/ for further information

Joe jsarlo@ucsd.edu

Frank Barknecht wrote:

Hallo,

...

On Wed, 12 Feb 2003, Miller Puckette wrote:

...

On the subject of "why Pd GUIs are bad in performance" check out GrIPD, Joe Sarlo's GTK-based GUI builder for Pd: http://crca.ucsd.edu/~jsarlo/

Hm, I tried to try gripd now, as I found, that I now have a wxgtk2.3-python installed on Debian, yep. But it won't start. The only message I get, when trying to open a .gpd file is:

GrIPD: Using port 3490 GrIPD: Waiting for a connection... GrIPD: Error launching gripd.py: No such file or directory

Around line 640 in gripd.c, there is this

       if ((execlp(pythExec, pythExec, filename, portString,
            "1", lockedString, (char *)0)) == -1)

which seems to fail. I change the source a bit to post() pythExec and this gives this:

pythExec: /usr/bin/../gripd/gripd

when trying to "open ../gripd/examples/fmsynth.gpd" as well as when trying to "open /full/path/to/gripd/examples/fmsynth.gpd".

I don't quite get, why gripd looks for itself in /usr/gripd/gripd (ok, it's relative to /usr/bin/pd, but this is not very FHS compliant) and how do I change that?

ciao

Is it possible that your setup has the gripd python script (the file gripd or gripd.py in older versions)owned by root or has setuid bit set for gripd? The gripd pd object tries to drop setuid root privileges before running the python script by setting the effective user id to the actual userid (line 587 of gripd.c). On my setup, I have the setuid bit set for the PD executable, and it is owned by root. The gripd python script is owned by the non-root user that starts PD, and does _not_ have the setuid bit set.

Joe jsarlo@ucsd.edu

Hallo, Joseph Sarlo hat gesagt: // Joseph Sarlo wrote:

...

By default, GrIPD looks for gripd.py in ../gripd (relative to PD executable). To change this, send the gripd object the message "set_path <path>" where "<path>" is the path to the directory containing gripd.py. See the included README.txt file and the gripd.pd patch in gripd/examples/ for further information

Thank you for this pointer, Josef. I misunderstood the README. But now I've got another problem, when starting gripd:

Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see:

http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

This known behaviour of Gtk occurs because I have Pd installed suid root to gain the best performance in realtime operation. I could remove the suid bit, then gripd would run, but this could be bad for Pd performance, and I don't want to do this. Does anyone have an idea for a workaround or would this require changes to Pd itself?

ciao

Frank Barknecht _ ______footils.org__

---

PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

Hallo, martin pi hat gesagt: // martin pi wrote:

some points to this - or "why is pd really not friendly to the user"

1. it has modes (as opposed to modeless

environments (this is why people do not like vi, too). modes are hard to understand - especially for mac people since the mac interface is traditionally modeless

(j)Max has modes as well. Word 5 for Dos had modes. Reactor kind of has modes, as well. I don't think, modes are bad, but I'm a Vim user. Of course, 'normal' users, i.e. those used to the whole Windows/Mac desktop paradigm will hate modes.

2. it does not support the usual features like

drag and drop, cut & paste (in message boxes for example) thus it is inconsistent (and that is the main point why people from the commercial side have problems with free software)

Yes, this isn't good. It is in part due to the cross-platform nature of Pd, but I'm sure this can be fixed. It's just, that there are other things that will be fixed earlier. I mean, up to 0.36 we didn't have Undo!

3. it does not have a clear rythm of behaviour -

sometimes it is fast as light, sometimes just stuck. most times inbetween. worst when audio processing is on (and realtime on my comp).

This is one of the thing that should be fixed before drag'n'drop, but might be much harder, because it seems to be deep in the current architecture. But the close dependency between DSP and GUI must go, as Thomas wrote.

yet it is mostly verb-noun based thus good in the general flow

Patch-writing is very much like creating a world, and may I remember you: a Creator's job isn't an easy one, and even HE made a lot of mistakes so it seems... (No religious harm intended. ;)

ciao

Frank Barknecht _ ______footils.org__

On Wed, 12 Feb 2003, martin pi wrote:

some points to this - or "why is pd really not friendly to the user"

1. it has modes (as opposed to modeless environments (this is why

people do not like vi, too). modes are hard to understand - especially for mac people since the mac interface is traditionally modeless

Modes are useful to reduce the number of different functions that need a key-binding or hot-spot. In VI, this is there because it allows a typewriter-trained person to keep his/her hands on the main part of the keyboard, while keeping the amount of pressing of modifier-keys quite low. In MAX/PD/JMAX this seems to be because there would be too many different clickable functions in a too small space, so some things are only available in Run mode, and some only in Edit mode.

However the presence of those modes is consistent with the fact that what you can do in edit mode doesn't affect what happens inside an object (except when you create or delete one), while what you can do in run mode affects what happens inside an object but not the rest... for example, the Undo function will not undo messages that have been sent through the message system due to a click in run mode (or whatever else) ! So there may be more to modes than what I said in the previous paragraph...

yet it is mostly verb-noun based thus good in the general flow

could you please explain this concept (verb-noun based) and how it opposes to other possible designs, or give references to webpages explaining it.

Mathieu Bouchard http://artengine.ca/matju