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/
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
+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 hans@eds.org 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
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?"
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
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.
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
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.
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
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
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 hans@eds.orgwrote:
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
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.
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
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
.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
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
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 matju@artengine.cawrote:
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
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
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.
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
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
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
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 hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "Pd List" pd-list@iem.at 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
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 hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "Pd List" pd-list@iem.at 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><ezdac~-help.pd>
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
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
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
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
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
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
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
After playing with ezoutput~, I have a few thoughts:
- 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.
- Allow the slider to go to zero, maybe with a [- 0.01] between the slider and the [pack].
- 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 hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, "Pd List" pd-list@iem.at 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
hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig"
Cc: "Pd List" pd-list@iem.at 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><ezdac~-help.pd>
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
On Mar 24, 2009, at 10:04 PM, Jonathan Wilkes wrote:
After playing with ezoutput~, I have a few thoughts:
- 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!
- 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 hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, "Pd List" <pd-list@iem.at
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
hans@eds.org wrote:
From: Hans-Christoph Steiner hans@eds.org Subject: Re: [PD] default [output~] in Pd-extended To: "IOhannes m zmoelnig"
Cc: "Pd List" pd-list@iem.at 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><ezdac~-help.pd>
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
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.
--- On Wed, 3/25/09, Steffen Juul stffn@dibidut.dk wrote:
From: Steffen Juul stffn@dibidut.dk Subject: Re: [PD] default [output~] in Pd-extended To: "Pd List" pd-list@iem.at 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
On Mar 25, 2009, at 3:03 AM, Jonathan Wilkes wrote:
--- On Wed, 3/25/09, Steffen Juul stffn@dibidut.dk wrote:
From: Steffen Juul stffn@dibidut.dk Subject: Re: [PD] default [output~] in Pd-extended To: "Pd List" pd-list@iem.at 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
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
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;
-
Enrique Erne -
Frank Barknecht -
Hans-Christoph Steiner -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Kyle Klipowicz -
Mathieu Bouchard -
Steffen Juul