Re: Cocoa friendly Quicktime APIs?
Re: Cocoa friendly Quicktime APIs?
- Subject: Re: Cocoa friendly Quicktime APIs?
- From: publiclook <email@hidden>
- Date: Sat, 8 Mar 2003 09:46:52 -0500
NeXTstep had extensive sound recording and playback based on the .snd
file format that was similar or the same as Sun's .au format as I
recall. There were GUI controls for recording, seeing the amplitude
modulation of the input sound as a scrolling EDITABLE graph. You could
copy and paste sounds between any two applications. There were limited
sound mixing features and controls over gain etc. You could even link
and embed sounds! All of linking and embedding is gone from Cocoa.
Does anyone remember dragging sounds into Draw documents ? (Draw was
the example that Sketch superseded, but sketch dropped a lot of
features and gained others) Diagram! used to have great sound
embedding support.
If I remember correctly, all of that capability was lost in the
transition to Openstep, but maybe it was lost with Rhapsody.
Certain Cocoa old-timers have been justifiably complaining that Apple
downgraded existing technology... while improving other things.
On Saturday, March 8, 2003, at 08:11 AM, Oleg Svirgstin wrote:
Hi all!
IMHO, QuickTime suffers from its Classic heritage. Not from being
"Carbon-oriented". It is NOT.
I mean these FSSpec, absolutely necessary to use while recording
sound. They
do LIMIT us (our users) in their choice of file names, or make us
invent
some complex file-manipulation schemes. It is NO good. Extra code means
extra bugs... and less features for the same time and money. In the
long run
it hurts the platform sales!
Carbon is transparently callable from Cocoa, I consider it as an extra
source of fun, never a problem. Carbon is as powerful as a trailer
truck,
and the fact that we can used it anywhere warms my self-confidence.
Imagine
having a super-fighter's super-engine under the hood of your car...
Now some problems:
1. After I record a sound to a movie file, however I create a NSMovie
after
this (by URL with ref:YES and ref:NO, with a Movie instance received
from my
OpenMovieFile etc) the object does NOT store in the archive. I use a
workaround, but I want to know whether it is a bug in NSMovie, in
documentation or in NSKeyedArchiver/NSKeyedUnarchiver. I did not try
NSPasteboard format with the sound movies, but I had suspicious
problems
passing between applications an RTFD containing movies. I do pass its
PATH
now, everything works fine.
When I store a 30+ M movie into an archive the archive never becomes
significantly larger. I can put up with this situation. I am not even
sure I
would be happy with a 3000+ M archive, taking 200 years to load or
save...
But for smaller sounds storing them in the archive would simplify my
code.
2. Well, I store all my "supporting" files and context-specific
archives
inside a wrapper. Real movie names are guarantied to fit all
limitations of
FSMakeFSSpec since it is me who generates them. However, there is a
user-controllable instance in the middle of the chain: the name of the
file
package and names of directories where a user might put my package. The
users are expected to use very long file names, not in English, and I
don't
want to deprive them of that right.
Try to explain a _Diehard Mac User_ that he CANNOT store his file as
"the
file that I want to open on my birthday" in a directory with a path
like
this: "~/Documents/My documents for the project 656/The documents that
I
like/The documents that I like most of all/Don't forget to buy
butter/My
files again/...". I am a Mac user since 1987, believe me!
Currently I convert a NSString path to Mac OS (":") separators (taking
into
account all that device name trivia), convert it to a pascal string
and
pass to the FSSpec creation as a whole. I control the path - normally
it is
around 110-150 chars, FSSpec eats it without a problem.
I don't use NSURL because
- I am stupid and stubborn
- I like my own algorithm
- It was the first solution that came into my mind before I knew about
FSSpec <-> CFURL <-> NSURL and I hate to kill a working code, I was a
terrible horrible Cocoa newbie when I started this project...
- I like NSString and every chance to play with these excellent toys
while
my wife is sure I am deep in my work...
- Did I tell I am stupid and stubborn?
Does anybody remember a fast and easy way to get folder ids (I mean
FSMakeFSSpec compatible folder ids) from a full path to a directory? Is
there a MODERN way to get folder ids for any folder in HFS+, with any
encoding and practically any length of the path? The ids look like
quite
alive in HFS+ even now.
Thanks in advance
IMHO, a better NSMovie and NSMovieView would be a great help to all of
us. I
consider an easy to use sound recording as ABSOLUTE must of Cocoa, and
I
hope that either Apple or a third-party genius will finally fill this
gap
before we all get too old to enjoy it.
I saw an NSMutableSound in my dreams doing all this... :^)
Oleg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.