Re: [PD] default [output~] in Pd-extended
On Mar 25, 2009, at 3:03 AM, Jonathan Wilkes wrote: --- On Wed, 3/25/09, Steffen Juul wrote: From: Steffen Juul Subject: Re: [PD] default [output~] in Pd-extended To: "Pd List" Date: Wednesday, March 25, 2009, 7:48 AM On 24/03/2009, at 18.10, Hans-Christoph Steiner wrote: Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. So thats the initial reason. Chancing the numberbox to a slider could live together with not making the colour changes i opposed to (- i shall not repeat it). Actually, could you repeat it? I searched the thread and couldn't find any remarks about the color. If your point is that the tutorials are completely black and white, and that having a gop abstraction with colored gui's would be distracting-- I've thought about that, too. But if that turns out to be the case it's a simple fix of just changing the slider and bng back to white (but maybe leaving the dsp-indicator green so you can quickly see if it's on or not). Pd-extended is now setup to use a version of this with very tamed color (attached). I think its important to have the GUIs something other than white to make them look solid and clickable. But yes, too much color would be distracting. Some color also attracts the eye just enough so that people know that its important, because really, without turning on the output~, the rest of the patch is kind of useless. .hc output~-help.pd Description: Binary data output~.pd Description: Binary data Also I've meet Pd sliders i could not recognize as sliders for a while. As a total it took me longer to learn sliders then numberboxes, since the looks of sliders can be altered so much. I rest my case, I don't think i get through. Happy hacking. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
hi I am to writing some example patches, but found the dependency of an other abstraction confusing and therefore made [pd output~] as a gop subpatch. It comes in a classic Pd black'n'white look, see attached. cheers eni #N canvas 510 50 450 300 10; #N canvas 40 22 651 595 output~ 0; #X obj 105 120 vsl 15 64 0 100 0 0 \$0-volume \$0-volume-r Volume 0 -10 0 12 -262144 -1 -1 5310 1; #X obj 105 210 tgl 15 0 empty empty DSP 19 7 0 12 -262144 -1 -1 1 1 ; #X obj 105 191 bng 15 250 50 0 \$0-mute \$0-mute-r Mute 19 7 0 12 -262144 -1 -1; #X obj 410 78 inlet~; #X obj 242 382 line~; #X obj 395 449 *~; #X obj 395 489 dac~; #X text 331 78 audio in; #X obj 473 78 inlet~; #X obj 457 448 *~; #X obj 410 329 hip~ 3; #X obj 472 329 hip~ 3; #X obj 105 279 send pd; #X obj 242 342 pack 0 50; #X obj 232 175 dbtorms; #X obj 233 299 f; #X obj 261 240 f 0; #X obj 301 240 == 0; #X obj 261 270 select 1; #X text 313 489 audio out; #X obj 232 75 loadbang; #X obj 232 105 f 70; #X obj 104 409 rmstodb; #X msg 104 440 set \$1; #X msg 105 249 dsp \$1; #X obj 252 145 r \$0-volume; #X obj 261 210 r \$0-mute; #X obj 104 469 s \$0-volume-r; #X obj 14 101 r pd; #X obj 14 131 route dsp; #X msg 14 161 set \$1; #X connect 1 0 24 0; #X connect 3 0 10 0; #X connect 4 0 9 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 8 0 11 0; #X connect 9 0 6 1; #X connect 10 0 5 1; #X connect 11 0 9 1; #X connect 13 0 4 0; #X connect 13 0 22 0; #X connect 14 0 15 0; #X connect 15 0 13 0; #X connect 16 0 17 0; #X connect 16 0 18 0; #X connect 17 0 16 1; #X connect 18 0 15 0; #X connect 18 1 13 0; #X connect 20 0 21 0; #X connect 21 0 14 0; #X connect 22 0 23 0; #X connect 23 0 27 0; #X connect 24 0 12 0; #X connect 25 0 14 0; #X connect 26 0 16 0; #X connect 28 0 29 0; #X connect 29 0 30 0; #X connect 30 0 1 0; #X coords 0 -1 1 1 55 130 2 100 100; #X restore 36 60 pd output~; #X obj 34 22 osc~ 440; #X connect 1 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Sat, 21 Mar 2009, Kyle Klipowicz wrote: I took Modern Algebra as my first course in "Higher Math." Big mistake. Learning to do proofs this way is a big headache, especially if you have a curmudgeonly teacher! I don't know what kind of prof you had, but Group Theory tends to need proofs that start from the very scratch. You can hardly skip any step or make any assumptions. Making proofs at this level is very akin to programming in low-level languages like machine language and assembly language: you need to go in the little details, and all you have are little details put together. Fortunately, other courses (and perhaps other parts of the same course) are higher-level than that: I don't need to re-prove every little thing. But it's often not very clear in what level of detail I have to go. As a really bored student, I constantly tested the limits of what I can submit in an exam, and I'd say that they were quite tolerant of my terse proofs. For your learning process, perhaps it has more to do with the teacher being curmudgeonly than about the actual topic that you use for learning how to prove things. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Tue, 24 Mar 2009, Hans-Christoph Steiner wrote:
I've taught Pd quite a bit at this point, and I have watched many people
not understand the number boxes as a interactive GUI element. Its based
on my experience, that's all. There is no scientific process behind it.
It is also based on my experience learning Pd, back in the day. I
remember it took me a while before I could get the examples working, and
I had been working with Csound, Cmix, MusicKit and others before, so I
was quite familiar with the concepts.
Ok. My next question is then: why isn't numberbox taught before any
[output~] is introduced, in tutorials and courses that it's intended to go
in?
And then, if they shouldn't learn the numberbox at the beginning, then
when should they?... the numberbox is pretty much all over the place, and
its behaviour (compared to spinboxes and such) is not something that was
done randomly... well, understanding the creative process, then maybe it's
been done randomly, but it certainly wasn't kept randomly! ergonomically
it makes sense: it gives faster control on a number, than a spinbox does.
I'd even say it didn't go far enough. There is no sensitivity control for
dragging ("scrolling") into numberboxes. The [nbx] (IEMGUI) class has the
log-height feature, but of course it only works in log mode. With the
sensitivity control, the numberbox would be a clearer winner, but not as
much as if it actually had the spinbox's arrow. That's especially feasible
in the [nbx] class, which wastes a lot of space that could be recycled as
buttons.
Now, about scientific processes... it's not all to have a scientific
process or not... you get to different conclusions (scientific processes
or not) depending on what you aim for. This is a part that I don't see
many people talking about. One's aims determine assumptions about the
research, assumptions that might be implicit or else often worded like
they are only ones worth using. But usability studies are funded by
companies who have a mass diffusion model. Those companies live by selling
new licenses of software. Those licenses of software tend to be more sold
to beginners than to experimented users, if the userbase is in vast
expansion compared to the rate of license renewal. As the usability
studies are ordered by the marketing operations, the assumptions will be
as beginner-oriented as the marketing department is. This is why user
interfaces are geared towards what the first impression will be like, at
the expense of the following years of use, with a tendency to ignore the
fact that people learn, because that learning only occurs after the
license is bought. This is IMHO why usability studies and famous UI
guideline books have to be approached with suspicion, regardless of how
tight their scientific and statistical standards are.
Free, community-oriented software isn't necessarily different. Rationally,
it depends on their score-keeping: if they are mainly motivated by getting
new beginner users, they will just do the same as companies that are
mainly selling licenses to new beginner users. Non-rationally, a project
could have any other userbase goals but still act like they're aiming for
beginners, because they follow UI advice designed for new beginner users
without questioning whether it really applies.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
--- On Wed, 3/25/09, Steffen Juul wrote: > From: Steffen Juul > Subject: Re: [PD] default [output~] in Pd-extended > To: "Pd List" > Date: Wednesday, March 25, 2009, 7:48 AM > On 24/03/2009, at 18.10, Hans-Christoph Steiner wrote: > > > Scrolling in a number box is not a standard GUI > interaction, and not particularly intuitive. > > So thats the initial reason. Chancing the numberbox to a > slider could live together with not making the colour > changes i opposed to (- i shall not repeat it). Actually, could you repeat it? I searched the thread and couldn't find any remarks about the color. If your point is that the tutorials are completely black and white, and that having a gop abstraction with colored gui's would be distracting-- I've thought about that, too. But if that turns out to be the case it's a simple fix of just changing the slider and bng back to white (but maybe leaving the dsp-indicator green so you can quickly see if it's on or not). > > Also I've meet Pd sliders i could not recognize as > sliders for a while. As a total it took me longer to learn > sliders then numberboxes, since the looks of sliders can be > altered so much. > > I rest my case, I don't think i get through. > > Happy hacking. > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
--- On Wed, 3/25/09, Matt Barber wrote: > From: Matt Barber > Subject: Re: [PD] default [output~] in Pd-extended > To: pd-list@iem.at > Date: Wednesday, March 25, 2009, 5:38 AM > > Intuition improves itself by learning. > > > > This is my most beloved pedagogical principle. > > I must constantly disabuse my composition students of the > notion that > "composing systematically" and "composing by > ear" are entirely > different activities, as though "The Ear" were > totally disconnected > from "The Mind" (of course, the ear is the more > romantic homunculus in > this scenario). I've never actually heard the phrase "composing by ear." I have heard composers from a certain generation describe their process as "intuitive," but I've always taken that as code for, "I'm a decent human being, and, unlike some, I won't take the tiny bit of power entrusted to me by this lecture to blather on shamelessly like a used-car salesman in some awful alternate universe where the customer leaves the lot not with a car, but with the memory of a dry, uninspired post-serialist compositional process." But if you press the "intuitive" composer for some details, I've found they'll usually give them. And in a clear and concise manner, which is always a bonus. -Jonathan > > I say, the best time to look for constraints on your > freedom is when > you feel the most intuitively "free..." it's > possible someone else is > doing the thinking for you (see ProTools), and the > constraints that > are there are really the ones that are your own and > haven't inspected > yet. This is something that learning addresses. > > Matt > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On 24/03/2009, at 18.10, Hans-Christoph Steiner wrote: Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. So thats the initial reason. Chancing the numberbox to a slider could live together with not making the colour changes i opposed to (- i shall not repeat it). Also I've meet Pd sliders i could not recognize as sliders for a while. As a total it took me longer to learn sliders then numberboxes, since the looks of sliders can be altered so much. I rest my case, I don't think i get through. Happy hacking. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
> Intuition improves itself by learning. > This is my most beloved pedagogical principle. I must constantly disabuse my composition students of the notion that "composing systematically" and "composing by ear" are entirely different activities, as though "The Ear" were totally disconnected from "The Mind" (of course, the ear is the more romantic homunculus in this scenario). I say, the best time to look for constraints on your freedom is when you feel the most intuitively "free..." it's possible someone else is doing the thinking for you (see ProTools), and the constraints that are there are really the ones that are your own and haven't inspected yet. This is something that learning addresses. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 24, 2009, at 10:04 PM, Jonathan Wilkes wrote: After playing with ezoutput~, I have a few thoughts: 1. A [change] after [route dsp] in the dsp logic subpatch. At least on windows, the slider motion is sluggish because of constant color messages to the tgl. 2. Allow the slider to go to zero, maybe with a [- 0.01] between the slider and the [pack]. Good ideas. Done! ezoutput~.pd Description: Binary data 3. I think a label for the mute button would be nice (could just be my own personal preference, though). I tried, but the font just seemed too small, especially on Pd-vanilla. .hc -Jonathan --- On Tue, 3/24/09, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] default [output~] in Pd-extended To: "Jonathan Wilkes" Cc: "IOhannes m zmoelnig" , "Pd List" > Date: Tuesday, March 24, 2009, 6:10 PM The current [output~] is not easy to use, lots of people have trouble with it. Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. .hc On Mar 24, 2009, at 3:41 AM, Jonathan Wilkes wrote: Why not use Miller's output~ as the default in pd-ext? I like the fact that the tutorials have both an abstraction and a subpatch for output, and it might be nice to have another gop that uses a slider as in your proposed abstraction. I think it would additionally be nice to have something like the attached somewhere in the tutorials, which is just a clone of your ezoutput~ using data structures. It would helpful when someone gets to the ds tutorial to be able to have an abstraction they've already been using to show as an example. The ds stuff is separated from the rest of the patch for that reason, though maybe something simpler would make a better example (at least as much as possible without using abstractions). -Jonathan --- On Mon, 3/23/09, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig" Cc: "Pd List" Date: Monday, March 23, 2009, 10:49 PM On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: So if we are introducing the concept of objects and GUI in Pd, then I think it is safe to use GOP objects. After all, we don't expect newbies to know anything about C or Tcl, but that's under it it all. I don't think we should add an output~ to help patches that don't already have them. I just think we should have a more intuitive and usable output~. The current one already uses GOP, so that's not a change. i fully agree. and would like to stress, that i am pretty sure that most users will not have a clue about gop when they first encounter the [output~] module (be it a new one or the original one). at least i cannot seem to find any documentation about gop prior to 3/A.05; nevertheless i think it is a good idea to use a gop-abstraction here. fgmasdr IOhannes Anyone else want to weigh in on this? I'd like to lobby Miller to get this included in 'extra' at least, then also used in the help and docmentation. .hc Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 24, 2009, at 10:29 PM, Mathieu Bouchard wrote: On Tue, 24 Mar 2009, Hans-Christoph Steiner wrote: Should we let snarkiness end this discussion? I thought it was actually pretty productive til this little bit... You can still work around my comments, and continue this discussion, but what I'm trying to say is that you can't necessarily just wave some word like "intuitive" and explain nothing about why you use it and expect people to just nod and call it productive. Go be productive with your intuitivity if you will, but when I make a comment like that, it's because I'm concerned that something is going the wrong way. I don't mock for the sake of mocking. If there can't be any disapproval of your ways, then why do you look like you want to get some approval at all? You can simply change the numberbox in pd-extended so as to suit your fancy and that would be the end of the story. Now if you could simply present your reasons to believe that a numberbox may be unintuitive to beginners in a way so significant that it warrants avoiding it, ... it sounds curious, so, I'm curious. Do you think sliders are nonintuitive as well? Pd's sliders are pretty nonstandard as far as UIs go. I've taught Pd quite a bit at this point, and I have watched many people not understand the number boxes as a interactive GUI element. Its based on my experience, that's all. There is no scientific process behind it. It is also based on my experience learning Pd, back in the day. I remember it took me a while before I could get the examples working, and I had been working with Csound, Cmix, MusicKit and others before, so I was quite familiar with the concepts. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Tue, 24 Mar 2009, Hans-Christoph Steiner wrote: Should we let snarkiness end this discussion? I thought it was actually pretty productive til this little bit... You can still work around my comments, and continue this discussion, but what I'm trying to say is that you can't necessarily just wave some word like "intuitive" and explain nothing about why you use it and expect people to just nod and call it productive. Go be productive with your intuitivity if you will, but when I make a comment like that, it's because I'm concerned that something is going the wrong way. I don't mock for the sake of mocking. If there can't be any disapproval of your ways, then why do you look like you want to get some approval at all? You can simply change the numberbox in pd-extended so as to suit your fancy and that would be the end of the story. Now if you could simply present your reasons to believe that a numberbox may be unintuitive to beginners in a way so significant that it warrants avoiding it, ... it sounds curious, so, I'm curious. Do you think sliders are nonintuitive as well? Pd's sliders are pretty nonstandard as far as UIs go. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
After playing with ezoutput~, I have a few thoughts: 1. A [change] after [route dsp] in the dsp logic subpatch. At least on windows, the slider motion is sluggish because of constant color messages to the tgl. 2. Allow the slider to go to zero, maybe with a [- 0.01] between the slider and the [pack]. 3. I think a label for the mute button would be nice (could just be my own personal preference, though). -Jonathan --- On Tue, 3/24/09, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] default [output~] in Pd-extended > To: "Jonathan Wilkes" > Cc: "IOhannes m zmoelnig" , "Pd List" > Date: Tuesday, March 24, 2009, 6:10 PM > The current [output~] is not easy to use, lots of people > have trouble with it. Scrolling in a number box is not a > standard GUI interaction, and not particularly intuitive. > > .hc > > On Mar 24, 2009, at 3:41 AM, Jonathan Wilkes wrote: > > > Why not use Miller's output~ as the default in > pd-ext? > > > > I like the fact that the tutorials have both an > abstraction and a subpatch for output, and it might be nice > to have another gop that uses a slider as in your proposed > abstraction. > > > > I think it would additionally be nice to have > something like the attached somewhere in the tutorials, > which is just a clone of your ezoutput~ using data > structures. It would helpful when someone gets to the ds > tutorial to be able to have an abstraction they've > already been using to show as an example. The ds stuff is > separated from the rest of the patch for that reason, though > maybe something simpler would make a better example (at > least as much as possible without using abstractions). > > > > -Jonathan > > > > > > --- On Mon, 3/23/09, Hans-Christoph Steiner > wrote: > > > >> From: Hans-Christoph Steiner > >> Subject: Re: [PD] default [output~] in Pd-extended > >> To: "IOhannes m zmoelnig" > > >> Cc: "Pd List" > >> Date: Monday, March 23, 2009, 10:49 PM > >> On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig > wrote: > >> > >>> Hans-Christoph Steiner wrote: > >>> > >>>> So if we are introducing the concept of > objects > >> and GUI in Pd, then I think it is safe to use GOP > objects. > >> After all, we don't expect newbies to know > anything > >> about C or Tcl, but that's under it it all. I > don't > >> think we should add an output~ to help patches > that > >> don't already have them. I just think we > should have a > >> more intuitive and usable output~. The current > one already > >> uses GOP, so that's not a change. > >>> > >>> i fully agree. > >>> and would like to stress, that i am pretty > sure that > >> most users will not have a clue about gop when > they first > >> encounter the [output~] module (be it a new one or > the > >> original one). > >>> > >>> at least i cannot seem to find any > documentation about > >> gop prior to 3/A.05; nevertheless i think it is a > good idea > >> to use a gop-abstraction here. > >>> > >>> fgmasdr > >>> IOhannes > >> > >> > >> Anyone else want to weigh in on this? I'd > like to > >> lobby Miller to get this included in > 'extra' at > >> least, then also used in the help and > docmentation. > >> > >> > >> .hc > >> > >> > > >> > >> Man has survived hitherto because he was too > ignorant to > >> know how to realize his wishes. Now that he can > realize > >> them, he must either change them, or perish. > -William > >> Carlos Williams > >> > >> > >> > >> ___ > >> Pd-list@iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > I spent 33 years and four months in active military service > and during that period I spent most of my time as a high > class muscle man for Big Business, for Wall Street and the > bankers. - General Smedley Butler ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 24, 2009, at 5:10 PM, Mathieu Bouchard wrote: On Tue, 24 Mar 2009, Frank Barknecht wrote: Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. Should we stop using the number box in Pd? Patching is not a standard GUI interaction, and not particularly intuitive. Should we stop using Pd? What's that kind of talking anyway? After two minutes of trying to use a number box, it becomes intuitive. Intuition improves itself by learning. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Should we let snarkiness end this discussion? I thought it was actually pretty productive til this little bit... .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Tue, 24 Mar 2009, Frank Barknecht wrote: Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. Should we stop using the number box in Pd? Patching is not a standard GUI interaction, and not particularly intuitive. Should we stop using Pd? What's that kind of talking anyway? After two minutes of trying to use a number box, it becomes intuitive. Intuition improves itself by learning. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Frank Barknecht wrote: > Hallo, > Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > >> Scrolling in a number box is not a standard GUI interaction, and not >> particularly intuitive. > > Should we stop using the number box in Pd? why not? people are way more used to spinners (or however they are called). and shadows. gmdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Scrolling in a number box is not a standard GUI interaction, and not > particularly intuitive. Should we stop using the number box in Pd? Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
The current [output~] is not easy to use, lots of people have trouble with it. Scrolling in a number box is not a standard GUI interaction, and not particularly intuitive. .hc On Mar 24, 2009, at 3:41 AM, Jonathan Wilkes wrote: Why not use Miller's output~ as the default in pd-ext? I like the fact that the tutorials have both an abstraction and a subpatch for output, and it might be nice to have another gop that uses a slider as in your proposed abstraction. I think it would additionally be nice to have something like the attached somewhere in the tutorials, which is just a clone of your ezoutput~ using data structures. It would helpful when someone gets to the ds tutorial to be able to have an abstraction they've already been using to show as an example. The ds stuff is separated from the rest of the patch for that reason, though maybe something simpler would make a better example (at least as much as possible without using abstractions). -Jonathan --- On Mon, 3/23/09, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig" Cc: "Pd List" Date: Monday, March 23, 2009, 10:49 PM On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: So if we are introducing the concept of objects and GUI in Pd, then I think it is safe to use GOP objects. After all, we don't expect newbies to know anything about C or Tcl, but that's under it it all. I don't think we should add an output~ to help patches that don't already have them. I just think we should have a more intuitive and usable output~. The current one already uses GOP, so that's not a change. i fully agree. and would like to stress, that i am pretty sure that most users will not have a clue about gop when they first encounter the [output~] module (be it a new one or the original one). at least i cannot seem to find any documentation about gop prior to 3/A.05; nevertheless i think it is a good idea to use a gop-abstraction here. fgmasdr IOhannes Anyone else want to weigh in on this? I'd like to lobby Miller to get this included in 'extra' at least, then also used in the help and docmentation. .hc Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Why not use Miller's output~ as the default in pd-ext? I like the fact that the tutorials have both an abstraction and a subpatch for output, and it might be nice to have another gop that uses a slider as in your proposed abstraction. I think it would additionally be nice to have something like the attached somewhere in the tutorials, which is just a clone of your ezoutput~ using data structures. It would helpful when someone gets to the ds tutorial to be able to have an abstraction they've already been using to show as an example. The ds stuff is separated from the rest of the patch for that reason, though maybe something simpler would make a better example (at least as much as possible without using abstractions). -Jonathan --- On Mon, 3/23/09, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] default [output~] in Pd-extended > To: "IOhannes m zmoelnig" > Cc: "Pd List" > Date: Monday, March 23, 2009, 10:49 PM > On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig wrote: > > > Hans-Christoph Steiner wrote: > > > >> So if we are introducing the concept of objects > and GUI in Pd, then I think it is safe to use GOP objects. > After all, we don't expect newbies to know anything > about C or Tcl, but that's under it it all. I don't > think we should add an output~ to help patches that > don't already have them. I just think we should have a > more intuitive and usable output~. The current one already > uses GOP, so that's not a change. > > > > i fully agree. > > and would like to stress, that i am pretty sure that > most users will not have a clue about gop when they first > encounter the [output~] module (be it a new one or the > original one). > > > > at least i cannot seem to find any documentation about > gop prior to 3/A.05; nevertheless i think it is a good idea > to use a gop-abstraction here. > > > > fgmasdr > > IOhannes > > > Anyone else want to weigh in on this? I'd like to > lobby Miller to get this included in 'extra' at > least, then also used in the help and docmentation. > > > .hc > > > > Man has survived hitherto because he was too ignorant to > know how to realize his wishes. Now that he can realize > them, he must either change them, or perish.-William > Carlos Williams > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ezdac~.pd Description: application/puredata ezdac~-help.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: So if we are introducing the concept of objects and GUI in Pd, then I think it is safe to use GOP objects. After all, we don't expect newbies to know anything about C or Tcl, but that's under it it all. I don't think we should add an output~ to help patches that don't already have them. I just think we should have a more intuitive and usable output~. The current one already uses GOP, so that's not a change. i fully agree. and would like to stress, that i am pretty sure that most users will not have a clue about gop when they first encounter the [output~] module (be it a new one or the original one). at least i cannot seem to find any documentation about gop prior to 3/A.05; nevertheless i think it is a good idea to use a gop- abstraction here. fgmasdr IOhannes Anyone else want to weigh in on this? I'd like to lobby Miller to get this included in 'extra' at least, then also used in the help and docmentation. .hc Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Hans-Christoph Steiner wrote: So if we are introducing the concept of objects and GUI in Pd, then I think it is safe to use GOP objects. After all, we don't expect newbies to know anything about C or Tcl, but that's under it it all. I don't think we should add an output~ to help patches that don't already have them. I just think we should have a more intuitive and usable output~. The current one already uses GOP, so that's not a change. i fully agree. and would like to stress, that i am pretty sure that most users will not have a clue about gop when they first encounter the [output~] module (be it a new one or the original one). at least i cannot seem to find any documentation about gop prior to 3/A.05; nevertheless i think it is a good idea to use a gop-abstraction here. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 21, 2009, at 11:46 AM, Steffen Juul wrote: To cut a longer story short: - No i don't want everyone to live there life linearly. How could that at all be assumed. (I rather embrace the opposite.) - The Pd tutorials that Miller ship with Pd is bottom-up. That is the didactic contract with the reader. So if you want a canvas'ified- gui-volume-control with such use of canvas with graph-on-parent, it need be introduced first. That could be done in the "2.control.examples" section. I used to believe strongly in what you are saying as well, but my opinion has changed a bit. I definitely agree that concepts should be introduced before the are used in the tutorials. We can also rely on existing knowledge of computers, and GUI elements are pretty widely understood. I have seen lots of people who don't know that they can click and drag in the number boxes. That's not a common GUI element outside of Pd. Buttons and sliders are much more common, and few people need to have them explained. So if we are introducing the concept of objects and GUI in Pd, then I think it is safe to use GOP objects. After all, we don't expect newbies to know anything about C or Tcl, but that's under it it all. I don't think we should add an output~ to help patches that don't already have them. I just think we should have a more intuitive and usable output~. The current one already uses GOP, so that's not a change. .hc "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
To cut a longer story short: - No i don't want everyone to live there life linearly. How could that at all be assumed. (I rather embrace the opposite.) - The Pd tutorials that Miller ship with Pd is bottom-up. That is the didactic contract with the reader. So if you want a canvas'ified-gui- volume-control with such use of canvas with graph-on-parent, it need be introduced first. That could be done in the "2.control.examples" section. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
I took Modern Algebra as my first course in "Higher Math." Big mistake.
Learning to do proofs this way is a big headache, especially if you have a
curmudgeonly teacher!
~Kyle
On Sat, Mar 21, 2009 at 9:28 AM, Mathieu Bouchard wrote:
> On Sat, 21 Mar 2009, Steffen Juul wrote:
>
>> Unveiled mysteries are indeed good, yes, we could almost define it as
>> learning. But did you learn Modern Algebra before Linear Algebra?
>>
>
> What I recall is that the first course of Modern Algebra (Group Theory)
> didn't really use much of anything from Linear Algebra, but the second
> course did. Your university may vary...
>
> Basically, there's not much in a math degree curriculum that requires
> Linear Algebra to be taught first. I could very well see one that teaches
> Modern Algebra first, and it wouldn't be a scandal to me. There are probably
> universities that do, somewhere -- at least if they are as experimental as
> they are in compsci... some universities teach computer programming in quite
> wild ways.
>
> So, what's your point about unveiled mysteries?
>
> _ _ __ ___ _ _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Sat, 21 Mar 2009, Steffen Juul wrote: Unveiled mysteries are indeed good, yes, we could almost define it as learning. But did you learn Modern Algebra before Linear Algebra? What I recall is that the first course of Modern Algebra (Group Theory) didn't really use much of anything from Linear Algebra, but the second course did. Your university may vary... Basically, there's not much in a math degree curriculum that requires Linear Algebra to be taught first. I could very well see one that teaches Modern Algebra first, and it wouldn't be a scandal to me. There are probably universities that do, somewhere -- at least if they are as experimental as they are in compsci... some universities teach computer programming in quite wild ways. So, what's your point about unveiled mysteries? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 21, 2009, at 12:07 PM, IOhannes m zmoelnig wrote: Steffen Juul wrote: On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote: On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote: but myteries unveiled are good for learning. so it boils down to in-line documentation of the mysteries used. Unveiled mysteries are indeed good, yes, we could almost define it as learning. But did you learn Modern Algebra before Linear Algebra? i don't think i can follow you here. it seems like you want to keep people from teaching "Modern Algebra" because the students might not have learned "Linear Algebra" yet. this leaves us at learning only the most simplistic ideas, unless we can enforce people to encounter mysteries only at well defined places in their life. i think most RPG work like this. i would prefer my life to be less linear. So here's my attempt at a vanilla combination of Miller's output~, rradical/ezdac~, and pddp/dsp. I find that quite confusing. I can't say i know how it works. i can only tell you that it is buggy: if you "mute" and then adjust to valume (in "mute" state), and then "mute" again it doesn't do anything. probably this makes it harder to understand. Now with fixed mute and outlet~s ezoutput~-help.pd Description: Binary data ezoutput~.pd Description: Binary data .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Steffen Juul wrote: > > On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote: > >> >> On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote: >>> >>> but myteries unveiled are good for learning. >>> so it boils down to in-line documentation of the mysteries used. > > Unveiled mysteries are indeed good, yes, we could almost define it as > learning. But did you learn Modern Algebra before Linear Algebra? i don't think i can follow you here. it seems like you want to keep people from teaching "Modern Algebra" because the students might not have learned "Linear Algebra" yet. this leaves us at learning only the most simplistic ideas, unless we can enforce people to encounter mysteries only at well defined places in their life. i think most RPG work like this. i would prefer my life to be less linear. > >> So here's my attempt at a vanilla combination of Miller's output~, >> rradical/ezdac~, and pddp/dsp. > > I find that quite confusing. I can't say i know how it works. i can only tell you that it is buggy: if you "mute" and then adjust to valume (in "mute" state), and then "mute" again it doesn't do anything. probably this makes it harder to understand. gfamrd IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote: On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote: but myteries unveiled are good for learning. so it boils down to in-line documentation of the mysteries used. Unveiled mysteries are indeed good, yes, we could almost define it as learning. But did you learn Modern Algebra before Linear Algebra? So here's my attempt at a vanilla combination of Miller's output~, rradical/ezdac~, and pddp/dsp. I find that quite confusing. I can't say i know how it works. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
I likey! Although, it would be nice to include [outlet~]s on the bottom to
pass through to recording devices.
~Kyle
On Fri, Mar 20, 2009 at 9:44 PM, Hans-Christoph Steiner wrote:
>
> On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote:
>
> Steffen Juul wrote:
>>
>>> On 10/03/2009, at 18.11, Hans-Christoph Steiner wrote:
>>>
(...) and the green/white toggle from [pddp/dsp].
>>> I quite strongly think [cvn]'s tricks should be avoided in help patches,
>>> especially those default for vanilla objects.
>>>
>>
>> what are "[cnv]'s tricks"? setting their colour?
>> i wouldn't call it a trick, as it is one of the few things you can
>> actually do with a cnv.
>> (a trick would probably be to set the send/receive labels at runtime;
>> which really makes patches rather unreadably; another trick would be to move
>> objects around to make GOPs be polymorphic; i agree that simple every-day
>> objects should probably avoid such things; i still don't see any trick in
>> setting the colour of a canvas or the value of a numberbox)
>>
>> Reason being it took me quite some time before i got heads and tails of
>>> it. Before that, it was a total mystery. Such mysteries are bad for learning
>>> since it may well obstruct learning of basic things. There is enough syntax
>>> to get into when starting to learn Pd.
>>>
>>
>>
>> but myteries unveiled are good for learning.
>> so it boils down to in-line documentation of the mysteries used.
>>
>
> So here's my attempt at a vanilla combination of Miller's output~,
> rradical/ezdac~, and pddp/dsp.
>
>
>
>
> .hc
>
>
>
>>
>>
>> fgmasdr
>> IOhannes
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
>
>
>
>
> "Free software means you control what your computer does. Non-free software
> means someone else controls that, and to some extent controls you." -
> Richard M. Stallman
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote: Steffen Juul wrote: On 10/03/2009, at 18.11, Hans-Christoph Steiner wrote: (...) and the green/white toggle from [pddp/dsp]. I quite strongly think [cvn]'s tricks should be avoided in help patches, especially those default for vanilla objects. what are "[cnv]'s tricks"? setting their colour? i wouldn't call it a trick, as it is one of the few things you can actually do with a cnv. (a trick would probably be to set the send/receive labels at runtime; which really makes patches rather unreadably; another trick would be to move objects around to make GOPs be polymorphic; i agree that simple every-day objects should probably avoid such things; i still don't see any trick in setting the colour of a canvas or the value of a numberbox) Reason being it took me quite some time before i got heads and tails of it. Before that, it was a total mystery. Such mysteries are bad for learning since it may well obstruct learning of basic things. There is enough syntax to get into when starting to learn Pd. but myteries unveiled are good for learning. so it boils down to in-line documentation of the mysteries used. So here's my attempt at a vanilla combination of Miller's output~, rradical/ezdac~, and pddp/dsp. ezoutput~-help.pd Description: Binary data ezoutput~.pd Description: Binary data .hc fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
Steffen Juul wrote: On 10/03/2009, at 18.11, Hans-Christoph Steiner wrote: (...) and the green/white toggle from [pddp/dsp]. I quite strongly think [cvn]'s tricks should be avoided in help patches, especially those default for vanilla objects. what are "[cnv]'s tricks"? setting their colour? i wouldn't call it a trick, as it is one of the few things you can actually do with a cnv. (a trick would probably be to set the send/receive labels at runtime; which really makes patches rather unreadably; another trick would be to move objects around to make GOPs be polymorphic; i agree that simple every-day objects should probably avoid such things; i still don't see any trick in setting the colour of a canvas or the value of a numberbox) Reason being it took me quite some time before i got heads and tails of it. Before that, it was a total mystery. Such mysteries are bad for learning since it may well obstruct learning of basic things. There is enough syntax to get into when starting to learn Pd. but myteries unveiled are good for learning. so it boils down to in-line documentation of the mysteries used. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On 10/03/2009, at 23.27, Hans-Christoph Steiner wrote: (snip) Many newbies are hung up because they can't get the example patches to do anything. A lot of the time, that's because they haven't turned up the audio. So to be precis and to check if i understand you correct: It's the word "dB" that is confusing? - While maybe the word "Vol" or "Volume" might clear it. If it is encapsulated in an object, then the complexity is hidden until you want to see it. Same idea with a osc~. The osc~ C code is far more complex. I don't think that's a fair analogy. I think it's quite clear, and i think most folk will have something like the same feeling, that what is "beneath" osc~ and other things you can type into a object-box such that an object is instantiated is by the syntax in a class of "hidden until I want to see it". Abstractions generate another class and so does subpatches. The to later are maybe in the same class to some. Then comes GOBified abstractions. Then GOBified abstactions that use [cvn] tricks to make a "funky" interface. The syntax of the last is way different from the first and different from the rest too in the way that the syntax is a "graphical design matter". GOP asb inherent syntax from the Pd it passes though, some i don't think that is conceptually that hard. Is this all blahblabbarbar? I agree it's getting hairy. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 10, 2009, at 2:50 PM, Steffen Juul wrote: On 10/03/2009, at 18.11, Hans-Christoph Steiner wrote: (...) and the green/white toggle from [pddp/dsp]. I quite strongly think [cvn]'s tricks should be avoided in help patches, especially those default for vanilla objects. Reason being it took me quite some time before i got heads and tails of it. Before that, it was a total mystery. Such mysteries are bad for learning since it may well obstruct learning of basic things. There is enough syntax to get into when starting to learn Pd. I agree that the patch should be conceptually simple, but usability is also a concern. Many newbies are hung up because they can't get the example patches to do anything. A lot of the time, that's because they haven't turned up the audio. If it is encapsulated in an object, then the complexity is hidden until you want to see it. Same idea with a osc~. The osc~ C code is far more complex. .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On 10/03/2009, at 18.11, Hans-Christoph Steiner wrote: (...) and the green/white toggle from [pddp/dsp]. I quite strongly think [cvn]'s tricks should be avoided in help patches, especially those default for vanilla objects. Reason being it took me quite some time before i got heads and tails of it. Before that, it was a total mystery. Such mysteries are bad for learning since it may well obstruct learning of basic things. There is enough syntax to get into when starting to learn Pd. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 9, 2009, at 10:45 PM, hard off wrote: a very simple solution would be to use a subpatch instead of an abstraction in the help files. [pd output~] Yeah, some of them have a subpatch. this would also remedy the problem reported more often: "why doesn't the output~ object work when i copy the help files to my desktop?" Having a abstraction in "extra" would also solve this problem. I think that we can make [ezdac~] better by adding the db numbox and mute function from Miller's [output~], and the green/white toggle from [pddp/dsp]. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
a very simple solution would be to use a subpatch instead of an abstraction in the help files. [pd output~] this would also remedy the problem reported more often: "why doesn't the output~ object work when i copy the help files to my desktop?" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
+1
I love [ezdac~]. If there's an output patch that's better, I'd like to see
it!
~Kyle
On Mon, Mar 9, 2009 at 5:38 PM, Hans-Christoph Steiner wrote:
>
> On Mar 9, 2009, at 6:32 PM, Hans-Christoph Steiner wrote:
>
> >
> > There is a object in iemlib called [output~], and its currently the
> > default object called [output~]. All of Miller's sound examples use
> > an included object called [output~]. So if you save one of those
> > examples to a different folder, then open it, that patch will then
> > have [iemlib/output~] instead of Miller's. This is very confusing
> > to many people, so I'd like to try to remedy the situation.The
> > question is how...
> >
> > - make Miller's output~ an object in extra, and make it the default
> > output~
> > - replace [output~] in those patches with something like rradical/
> > ezdac~ in the build process
> > - other ideas?
>
> Or perhaps a better idea: make a better version combining output~,
> ezdac~, and pddp/dsp into a nice pure pd controller, include it as a
> standard object in extra, then lobby Miller to accept changes to make
> it the default output object for all the included doc patches.
>
> Fixing this would a huge help to newbies.
>
> .hc
>
> >
> >
> > .hc
> >
> >
>
> >
> > http://at.or.at/hans/
> >
> >
>
>
>
>
>
>
> There is no way to peace, peace is the way. -A.J. Muste
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] default [output~] in Pd-extended
On Mar 9, 2009, at 6:32 PM, Hans-Christoph Steiner wrote: > > There is a object in iemlib called [output~], and its currently the > default object called [output~]. All of Miller's sound examples use > an included object called [output~]. So if you save one of those > examples to a different folder, then open it, that patch will then > have [iemlib/output~] instead of Miller's. This is very confusing > to many people, so I'd like to try to remedy the situation.The > question is how... > > - make Miller's output~ an object in extra, and make it the default > output~ > - replace [output~] in those patches with something like rradical/ > ezdac~ in the build process > - other ideas? Or perhaps a better idea: make a better version combining output~, ezdac~, and pddp/dsp into a nice pure pd controller, include it as a standard object in extra, then lobby Miller to accept changes to make it the default output object for all the included doc patches. Fixing this would a huge help to newbies. .hc > > > .hc > > > > http://at.or.at/hans/ > > There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] default [output~] in Pd-extended
There is a object in iemlib called [output~], and its currently the default object called [output~]. All of Miller's sound examples use an included object called [output~]. So if you save one of those examples to a different folder, then open it, that patch will then have [iemlib/output~] instead of Miller's. This is very confusing to many people, so I'd like to try to remedy the situation.The question is how... - make Miller's output~ an object in extra, and make it the default output~ - replace [output~] in those patches with something like rradical/ ezdac~ in the build process - other ideas? .hc http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
