[JL!]

Ok, I've asked this question all over different forums and mailing lists and no one can give me an answer. I'll be duly impressed with anyone (or any group of people for that matter) that can answer this humm-dinger.

I want to write an app in Cocoa. That's fine, I know C++, I'm learning Java, and I'm assuming that besides learning some extras about Obj-C the actual programming won't be too difficult. But it involves sound. You should hear scary music now As far as I can tell, sound is somewhat uncharted territory in Cocoa. Please correct me if I'm wrong.

I've conducted various phone interviews (I used to work at a radio station with crappy equipment) and I got sick of trying to find a good way to record them. So... I want the app to be able to select a sound input source (the internal modem in this case) and then let the user click a button that toggles between "Record" and "Stop Recording."
Then I would really be happy if I could tell the program to save the file it just recorded to disk as a certain type of file (any type of sound file really) which could be played back and edited with another different application.

My questions are as follows:

1) How do I tell Cocoa to select a sound input source
2) How do I capture sound from it
3) How do I serialize that to disk

The first two are the most important really, but the third kinda closes the deal.

I would actually be just as interested in seeing how many people read this and don't know the answer as I would in how many actually do.

TTFN

JL!

[This message has been edited by JL! (edited 01-26-2001).]

[JL!]

I'm kinda surprised... no one here knows anything about this? Is it that bad? Do I need to write drivers or something?

JL!

[absmiths]

I'm sure you have heard this before - but Apple hasn't yet finalized the Sound API's that are going to exist in Cocoa. I remember Apple saying that the sound API would be a really awesome part of Cocoa and they want to get it right. Maybe that explains why they bought the engineer from C&G who led Sound Jam?

At any rate, I have a simple solution that costs about $36. Buy one of those phone taps tha Radio Shack sells ($7) that suctions onto your phone and outputs the audio in 1/8" phono. Next, use SoundJamMP ($29) and tell it to capture sound in and then you can save the result to MP3, AIFF, etc.

I am not 100% sure if SoundJam will capture under OS X, I don't see why it couldn't. At the very least, it should work when OS X is realesed, which is probably sooner than you could write/test/debug it anyway.

If Apple ships JDK 1.3 with OS X final, then you could use the excellent javax.sound API's in conjunction with the media API to do at lot of this yourself.

I hope that was helpful (not too impressive).

------------------

[JL!]

Actually, the Radio Shack solution defeats the point. I really want a software-only solution because this is part of an academic exercise of sorts, and that is one of the requirements. I must write it all myself, using Cocoa is the goal. I could do a Java Cocoa program.

Maybe I should clarify my situation: I'm supposed to make some sort of simple Cocoa app that takes 10 - 15hours to plan/code and the like. It's for an extra requirement I must fulfill because I'm in the honors program at my college. So I suppose anything with sound is the worst possible Cocoa focus I could choose right now, huh? What kind of program should I do?

Any other ideas? I hadn't heard anywhere that Apple hadn't finalized the sound API. I just thought that they were either being slow at it, or hadn't updated the documentation.

JL!

[This message has been edited by JL! (edited 01-26-2001).]

[absmiths]

That's what happens when you ask a professional engineer about how to solve a problem - I would choose the quickest, cheapest and best solution (in academic terms, the most elegant solution). Nothing can be planned, implemented and tested and 10-15 hours except the most trivial code. To be realistic- to make a reasonable excercise it should follow sound practices, which means emphasis on a quality, thought-out design. A professor may expect you to design and code something in 10-15 hours because he will never use it again. In the real world, if you told your boss that you produced code in 10 hours and you are done, and it isn't a simple shell script, you will probably be replaced by someone they have more confidence in.

Bottom line is this: If you need something to work now for a particular purpose, then take the easy road using code others have written. If you are pursuing an excercise, only attempt a reasonable goal. At A high-level OO seminar I attended a few weeks ago we had assignments to design code, but never implemented. Most programmers can write good code, but not many can create a workable design.

Sorry for tha rant, here is a practical suggestion: Why not write a simple process viewer, one that can operate on the console, in text mode, or as an Aqua app, offering the best of either interface. The API set if fairly small, and the concepts are well known, besides, you can never have too many Process Managers.

------------------

[absmiths]

By the way, I tested Sound Jam and in case you still need a tool for recording conversations - it will work. Just make sure you get the version for OS X, not the Classic version.

------------------