Hi Stefan, I only had a quick glance at your new code. I definitely support the idea of supporting the new MacOSX methods on NSSound, but haven't had the time to see, whether there is a way of supporting them with the old openaudio interface. What I don't understand is what we gain/loose by giving up our own sound server? I will look into all this in more detail, but there is already one thing I noticed that needs to be changed in your code. You changed the encoding/decoding in a non compatible way and also did not change the version of the class. Could you please fix this?
Fred Stefan Bidigaray wrote: > Well, I've been messing with NSSound for a few weeks now and got to the > point where, in order to continue, I need some help. I posted a few > patches up on Savannah, but as I kept working on a fall back code for > whenever there's no libsndfile (the patches I put up was based on it, > and the fall back can currently read AU/SND and WAV in PCM 8, 16, 32 > bit, uLaw and aLaw [I'm planning on 32 and 64 bit float soon]) I pretty > much ended up having to rewrite most of NSSound so that it can now > respond to -initWithData:. I've somewhat hit a point where I need > someone to take a look at what I've done so far and let me know if I'm > going in the right direction or not. > > I've also started branching out a bit from the Apple docs and introduced > a -dataWithFormat:fileType: which allows data to be written to a NSData > object in any of the formats that I can read in. I thought it would be > nice having the ability to convert between different file types. I'm > also think about adding a method to read RAW PCM data, which wouldn't be > very hard and would allow for NSSounds to be created from raw CD data, > and in combination with the previous method write it to file (pretty > much all you would need to create a CD ripper would be someway to read > the CD data, which I thought would a good idea). > > I'm attaching the files I worked on. A diff of this stuff is huge, so I > thought it would be easier to just attach the files themselves. I still > haven't done any work on AIFF/AIFF-C, but plan on taking a look into it > soon. AIFF poses a problem (for me at least) because of that stupid > 80-bit IEEE float representing the sampling rate, where as the others > are just straight integers. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
