simple sound problem

[Damiano Michael]

I try to play a simple sound with Java.

I create a Class with : import java.applet.AudioClip;

public class Class_Sound extends JApplet{

AudioClip clip;

public Class_Sound(){

String filename=getParameter("bouchon-champagne.wav");
clip=getAudioClip(getDocumentBase(),filename);


}

public void Play(){

clip.play();


}

public void Stop(){

clip.stop();

}

}



I get an error with getParameter. It seems that Java can't find the file. I
put the sound file in the same directory as the App itself. What is the
proper way to load a sound file ?

Thanks.

Michael.

 

[Andrew Thompson]

"Damiano Michael" ...
| I try to play a simple sound with Java.
|
| I create a Class with : import java.applet.AudioClip;
|
| public class Class_Sound extends JApplet{

/* a better name is SoundApplet */

|
| AudioClip clip;
|
| public Class_Sound(){

/* wrong! use the 'init()' method for applets, they
do not have a 'constructor' */
public void init() {

| String filename=getParameter("bouchon-champagne.wav");
| clip=getAudioClip(getDocumentBase(),filename);
|
|
| }

....
| I get an error with getParameter. It seems that Java can't find the file.

No you don't! You never _call_ getParameter,
so it cannot be Java having a problem with it!

Further, you at the stage where you should
be posting at rather than here..

And several more points:

If you are new to Java, you should avoid
GUI's, let alone applets.

When you get back to Applets, it is
a good idea to supply an URL, and you
need to able to know how to use the
Java Console, in order to debug.

Debugging is another matter again,
but your example shows you have not
put 'println' calls everywhere, the first step.

HTH

 

[Larry Coon]

If you are new to Java, you should avoid
GUI's, let alone applets.

Well....that's a matter of pedagogical preference. And
it's often an issue out of the learner's (direct) control.
For instance, if the person is studying Deitel & Deitel,
he will be jumping into both GUIs and Applets right away.

 

[Andrew Thompson]

"Larry Coon" ...
| Andrew Thompson wrote:
|
| > If you are new to Java, you should avoid
| > GUI's, let alone applets.
|
| Well....that's a matter of pedagogical preference.

So, state and justify _your_ preference,
if you have a better one!

| ..And
| it's often an issue out of the learner's (direct) control.

What a load of rubbish!

| For instance, if the person is studying Deitel & Deitel,
| he will be jumping into both GUIs and Applets right away.

a) The learner can study a different book.
b) The learner can flip the pages of bad
books to the bits that deal with the basics.
c) The learner can suplement one book with
other books ..or tutorials on the internet.

 

[Larry Coon]

So, state and justify _your_ preference,
if you have a better one!

Sorry, but I never said this was _my_ preference, I never
claimed my preference to be better, and I wouldn't claim
superiority in something that's a matter of preference to
begin with. I was merely stating that some pedagogies DO,
in fact, jump into GUI/Applet stuff right away. If you're
interested in _their_ justifications, I'm sure you can
find what they wrote about them. And if you want to argue
the merits, then by all means, argue with them, not me. I
was only pointing out that differing pedagogical approaches
exist.

What a load of rubbish!
[. . .]
a) The learner can study a different book.
b) The learner can flip the pages of bad
books to the bits that deal with the basics.
c) The learner can suplement one book with
other books ..or tutorials on the internet.

This is the reason I added "(direct)" to my statement. Yes,
a learner -can- study a different book, supplement, etc.,
but that's entirely beside my point. For example, if the
learner is a student in a college course that's standardized
on Deitel & Deitel (to use the example I brought up before),
he -will- be jumping into the GUI/Applet aspects right away,
because the course (if it's structured around the book) will
present the material that way. Unless you think he should
convince his instructor to halt the class while he goes out
and studies some other material first, he will have no control
over the fact that he'll be doing GUI and applets right away.

 

[Andrew Thompson]

"Larry Coon" ...

This no longer (if it ever did) applies to the OP.
...
| ...Unless you think he should
| convince his instructor to halt the class while he goes out
| and studies some other material first,

I think such a person can
a) Change schools.
b) Drop out.
c) Stay at the same school and stop
bothering us to do the work for them
that is obviously over their heads.

Any of those things are _within_
_their_ _direct_ control.

--
Andrew Thompson
* http://www.PhySci.org/codes/ Web & IT help
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

 

[Larry Coon]

This no longer (if it ever did) applies to the OP.

Oh, I agree. In fact, I think your original statement to
which I responded is where it deviated.

I think such a person can
a) Change schools.
b) Drop out.

Yep, I can see the wheels turning in the students' heads:
"I need this Java course, but it teaches GUIs right away.
The teacher says it's fine, and the book we're using says
it's fine, but dangit, Andrew Thompson says that's a bad
idea. I'd better change schools or drop out." Yes, those
are certainly viable and appropriate alternatives to
address this "problem."

c) Stay at the same school and stop
bothering us to do the work for them
that is obviously over their heads.

Non sequiter -- the fact that it may be over the OP's
head, and the fact that he's "bothering us to do work for
them" have nothing to do with the assertion that learning
GUIs early is not always under the learner's direct
control. Nor do I see any justification that learning
GUIs early LEADS to the above. For that matter (since you
brought up justification in an earlier post), nor do I see
one for why learning GUIs early in the process is a bad
idea.

Any of those things are _within_
_their_ _direct_ control.

I suppose they can kill themselves too, but that's a pretty
harsh reaction to working with GUIs early-on in the learning
curve. Sorry, and while I don't want this to degrade into a
silly semantic argument (it's silly enough as it is, thank
you), while THOSE things are in the learner's _direct_
control, I'll stand by my statement that the point at which
the learner begins learning things like GUIs and Applets is
often an issue OUT of his direct control. If you want to
classify those indirect measures as "direct control" then so
be it, but I'll stand behind my reasoning.

 

[Andrew Thompson]

| ..I'll stand behind my reasoning.

Good for you Larry.

 

[Chris Smith]

Just a few picky points "for the record"...

"Damiano Michael" ...

| import java.applet.AudioClip;
|
| public class Class_Sound extends JApplet{
|
| AudioClip clip;
|
| public Class_Sound(){
| String filename=getParameter("bouchon-champagne.wav");
| clip=getAudioClip(getDocumentBase(),filename);
|
|
| }
[...]

| I get an error with getParameter. It seems that Java can't find the file.

/* wrong! use the 'init()' method for applets, they
do not have a 'constructor' */
[...]

No you don't! You never _call_ getParameter,
so it cannot be Java having a problem with it!

The truth is halfway in the middle. Yes, applets do have constructors.
The base class Applet has a single constructor that takes no arguments
(see the API documentation), and subclasses of Applet must have a
constructor that takes no arguments as well. (Though an Applet subclass
is welcome to provide additional constructors, they will not be used by
a normal applet container.)

This is very important at a VM level because certain kinds of simple
initialization code (for example, inline field initializaters) are moved
to the constructor by the compiler. It's less important at the language
level, but it is worth understanding that applets follow the same basic
lifecycle as any other Java object, and aren't really "magical" in any
way. There are some kinds of initialization that can be done in the
applet's constructor, and some kinds that cannot. (And incidentally,
the same restrictions that apply to code in the constructor also apply
to inline field initializers.)

The problem is that the setup of an applet by the web browser is a two-
stage process. First, the applet object itself is created, and then the
applet is linked to the web browser (via a bridge object that implements
the AppletStub interface). Since the constructor is run as the applet
object is being created, any code that is written in the applet's
constructor may not interact with the web browser in any way. So, it's
fine to use the constructor to initialize an array of the first 200
fibinacci (sp?) numbers, but it's not fine to use the constructor to get
parameters from the applet's PARAM tags.

So in the end, yes Michael is calling getParameter. Furthermore, he is
calling getParameter before it has the information it needs to complete
the task. That is most likely causing an exception to be thrown (though
the API docs don't really specify what happens in this case).

Of course, there are other problems as well. The code most likely
demonstrates a confusion about what the getParameter method does; and
declares two methods called Play() and Stop() that are never called and
that grossly violate esteblished and near-universal Java identifier
naming conventions. Incidentally, Stop() is a very close misspelling of
the actual lifecycle method called stop(), and I wonder if these two
methods are intended to be start() and stop() instead of the current
Play() and Stop().

Debugging is another matter again,
but your example shows you have not
put 'println' calls everywhere, the first step.

(Just a side-comment; I agree that println is a great means of
demystifying what is happening when the behavior of code gets a little
strange. However, I certainly prefer that those statements are removed
before posting... unless, of course, they are part of demonstrating the
problem itself.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

I think such a person can [...]
c) Stay at the same school and stop
bothering us to do the work for them
that is obviously over their heads.

Non sequiter -- the fact that it may be over the OP's
head, and the fact that he's "bothering us to do work for
them" have nothing to do with the assertion that learning
GUIs early is not always under the learner's direct
control.
Sure.

Nor do I see any justification that learning
GUIs early LEADS to the above. For that matter (since you
brought up justification in an earlier post), nor do I see
one for why learning GUIs early in the process is a bad
idea.

Ah, but *that* is a definite point of contention. Specifically, if you
take a look at my recent response summarizing one of the problems in
Michael's code, I think you'll see that in this case, many of the
problems were directly related to difficulties in the applet framework
(i.e., GUI stuff) that Michael was trying to use. Specifically, he was
using a constructor for initialization, in a way that would make perfect
sense except for the additional complexities involved in the convoluted
setup process for an applet.

I happen to be with Andrew on the fundamental point here: from the
perspective of learning and understanding Java, it's best to begin as
much as possible in isolation from complex framework code. Note that
it's actually the framework elements that really push this over the edge
-- the event-oriented nature of GUI development, for example, which
turns the tables and makes it feel as if *you* are supplying a library
and Sun has provided the client code. The serious danger here is to
encourage the programmer to classify the behavior of the system under
that mental file for "it's magical, so just memorize it". From that
point, it becomes hard to convince students to generalize and apply
rules for the behavior of all objects. (I speak from experience here.)

Frankly, I doubt that even Dietel and Dietel, or other authors who jump
into the GUI/applet world right away would disagree that it's an
inferior approach from a learning standpoint. I'd hazard a guess that
the reason they chose that approach is more motivational and even sales-
oriented than because they feel the approach produces better
programmers.

I suppose they can kill themselves too, but that's a pretty
harsh reaction to working with GUIs early-on in the learning
curve.

Andrew may be having a bad day, but even a student in a class that is
following a specific approach can benefit from being advised to start
from the beginning. Most successful students in programming learn about
the subject from multiple sources. I don't think anyone should be
encouraged to think of themselves as incapable of learning something if
it isn't contained in a certain section of a book.

When this advice is given it's generally because something *extremely*
important and fundamental is being missed... something that really
should have come up by now regardless of the techniques involved in a
class or study environment. If Michael had not posted with methods
called "Play()" and "Stop()" -- a sign of any of plain messiness, a
misunderstanding about Java being case sensitive, or a failure to even
check the part of the book that says that applets have methods called
start() and stop() (or perhaps all of the above) -- then I doubt that
section of Andrew's response would have appeared.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew Thompson]

| Just a few picky points "for the record"...
<snip long post on the finer points>

Wow! As usual, I did not realise there
was that much too it.

| > Debugging is another matter again,
| > but your example shows you have not
| > put 'println' calls everywhere, the first step.
|
| (Just a side-comment; I agree that println is a great means of
| demystifying what is happening when the behavior of code gets a little
| strange. However, I certainly prefer that those statements are removed
| before posting... unless, of course, they are part of demonstrating the
| problem itself.)

That is a _very_ good point Chris.
I can just imagine myself criticizing
somebody for posting 15Kb of code,
then shrinking when they comment it
was 8Kb before they added the 'println'
statements!

I will try to remember not to say that
again, ..though I wonder if it is worth
doing a page on debugging. *

It would seem, from a lot of answers,
that the OP often does not even
understand where the problem is
occurring.

* I have been following a lot of the
links to mentioned resources recently,
to consider linking from my 'codes' site,
but the few relating to 'noob debugging'
generally result in a 404.. :-(

--
Andrew Thompson
* http://www.PhySci.org/codes/ Web & IT help
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

 

[Larry Coon]

Ah, but *that* is a definite point of contention. Specifically, if you
take a look at my recent response summarizing one of the problems in
Michael's code, I think you'll see that in this case, many of the
problems were directly related to difficulties in the applet framework
(i.e., GUI stuff) that Michael was trying to use. Specifically, he was
using a constructor for initialization, in a way that would make perfect
sense except for the additional complexities involved in the convoluted
setup process for an applet.

I happen to be with Andrew on the fundamental point here: from the
perspective of learning and understanding Java, it's best to begin as
much as possible in isolation from complex framework code.

This might sound surprising after reading my earlier responses,
but I agree. When I wrote that I didn't see a reason why it
was a bad idea, what I meant was that I didn't see Andrew provide
one, which was ironic given that it was one of the first things
he mentioned in his criticism. However, upon re-reading what I
wrote I can see that it can be interpreted as saying I can't
think of a reason why it's a bad idea. (Your valid justification
snipped...)

Frankly, I doubt that even Dietel and Dietel, or other authors who jump
into the GUI/applet world right away would disagree that it's an
inferior approach from a learning standpoint. I'd hazard a guess that
the reason they chose that approach is more motivational and even sales-
oriented than because they feel the approach produces better
programmers.

I've never talked to them about it, so I don't know the basis
for that decision, nor whether pedagogical factors were the only
ones considered in their approach. What I -do- know is that
their book -does- structure the material in that way (and
probably other books, I'm sure), and that their book -is- used
as required text for college Java courses (including the
University where I teach, although I don't teach Java so I can't
comment on the effectiveness of the approach). So my point
continues to be that some people don't have direct control over
the order in which such material is presented to them (although
Andrew and I apparently disagree about what constitutes "direct
control"). That was my only point, and I'm certainly not
married to any single pedagogy for teaching Java.

Andrew may be having a bad day, but even a student in a class that is
following a specific approach can benefit from being advised to start
from the beginning. Most successful students in programming learn about
the subject from multiple sources. I don't think anyone should be
encouraged to think of themselves as incapable of learning something if
it isn't contained in a certain section of a book.

I agree 100%, but I'll also respectfully suggest that it's
orthogonal to my point.

When this advice is given it's generally because something *extremely*
important and fundamental is being missed... something that really
should have come up by now regardless of the techniques involved in a
class or study environment. If Michael had not posted with methods
called "Play()" and "Stop()" -- a sign of any of plain messiness, a
misunderstanding about Java being case sensitive, or a failure to even
check the part of the book that says that applets have methods called
start() and stop() (or perhaps all of the above) -- then I doubt that
section of Andrew's response would have appeared.

Absolutely -- with the caveat that I wouldn't make blanket
assumptions about pedagogy based on the failings of one
student. I'm not saying YOU were doing that, but I -did-
see responses which appeared to make that (unjustified)
leap. Of course, a valid response to me would be that it's
based on not just this one case, but on many similar examples.
But that just gets me back to my point -- some people don't
get to choose the order in which things are presented.

 

[Andrew Thompson]

...hmmm. Seems we have come to some
sort of consensus on this thread.

Unfortunately there is _one_ thing
I have to revisit..

"Andrew Thompson" ...
<re: java students at bad schools, or with bad resources..>
| I think such a person can
......
| c) Stay at the same school and stop
| bothering us to do the work for them
| that is obviously over their heads.

(groans) I cannot believe I said that!

If a student is stuck at a particular
school (only one within 500klicks or,
...only free one) or has to make do
with inadeqaute resources, books
or whatever...

They are most welcome here*, at
least they have shown the initiative
to seek further sources of information.

* ..and I only mean that _I_ welcome
such folks, not that I feel I have the right
to speak on behalf of any other member
of these forums. ;-)

--
Andrew Thompson
* http://www.PhySci.org/codes/ Web & IT help
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site