[gnuspeech-contact] Re: cvs

[Gregory John Casamento]

David,

I think using CoreAudio is fine.   In my previous email, I was specifically 
resonding to Eric's comment about using data structures which have Cocoa 
equivalents (NSDictionary instead of CFHashTable and etc.).  

As sound output, using ioctl doesn't seem to be the best idea.  I'm not even 
certain it would work properly on Mac OS X, if at all. It would be best, I 
think, if the calls to CoreAudio were isolated in one place, so that this could 
be implemented on a per platform basis.  
  
Later, GJC

--
Gregory Casamento

----- Original Message ----
From: David Hill <address@hidden>
To: Gregory John Casamento <address@hidden>
Cc: address@hidden; Steve Nygard <address@hidden>; gnuspeech <address@hidden>
Sent: Monday, October 16, 2006 12:56:35 AM
Subject: Re: cvs

Greg,

Thanks for the input.  You are right about the Core Audio problem, of  
course, but GNUstep doesn't really cover the audio needs as it  
stands, as we agreed earlier.  However the audio is handled, it needs  
to be easily portable so I am somewhat leery of getting into IOCTL  
and stuff.  How *do* you think we should handle the sound output?  It  
would be very appropriate if something better could be figured out  
right now because I am dealing with a bunch of that stuff right now  
and using Core Audio because it seems the best route and I have a  
working system that could use whatever sound means are on a given  
machine by using it.  Or am I being obtuse?

Best

david


On Oct 15, 2006, at 9:30 PM, Gregory John Casamento wrote:

> Eric,
>
> As David suggests, it would be best to make the changes you are  
> discussing on a branch.   This would avoid breaking the trunk.
>
> The "pure Cocoa" route, by the way, is preferable for me since  
> GNUstep doesn't implement any of the CF* (or Core Foundation)  
> functions.. and there are no plans to do that within GNUstep itself.
>
> Thanks, GJC
> --
> Gregory Casamento
>
> ----- Original Message ----
> From: David Hill <address@hidden>
> To: address@hidden
> Cc: Greg Casamento <address@hidden>; Steve Nygard  
> <address@hidden>; gnuspeech <address@hidden>
> Sent: Sunday, October 15, 2006 11:47:19 PM
> Subject: Re: cvs
>
> Hi Eric,
>
> You need to coordinate with Greg Casamento and Steve Nygard.  Adam
> Fedor did a lot of work originally to change the NeXT code to
> OpenStep/Cocoa and Greg is working on the GNUStep port.  At the very
> least, if you are making big changes, you probably ought to work on a
> split and merge later when it can be shown that you haven't caused
> problems.
>
> In response to you latest comment that this ought to be posted to the
> list -- yes.  I should have thought of that.  I'll post them and then
> post this.
>
> Live long and prosper!
>
> david
>
>
> On Oct 15, 2006, at 8:32 PM, address@hidden wrote:
>
>> Oh, one more thing. The way I am doing the port to OS X may be more
>> 'invasive' than what you had in mind. As I am going through the
>> source code, I am essentially changing everything that is done in a
>> C/C++ style (such as the use of C strings, const char * , etc.) and
>> changing them to use the equivalent Objective-C classes (e.g.
>> NSString).  Also, there are places that use data structures such as
>> an NXHashtable which in the OS X world is a "core foundation" class
>> (CFHashtable or some such), which is part of Carbon. While these
>> core foundation classes would work fine in Cocoa as well, I am
>> changing these to use the equivalent Cocoa Objective-C class (such
>> as NSDictionary); essentially I am taking a pure Cocoa approach.
>>
>> Furthermore, none of the NEXTstep Objective-C code will work as-is
>> in Cocoa. On the most basic level, at least the NX prefixes on all
>> the Objective-C classes have to be changed to NS prefixes.
>>
>> Here is my concern, however: while all this is a good way to port
>> the application to a native Cocoa application, and is a good way
>> for me to learn all about Cocoa on OS X, I have no idea what the
>> implications to this are for the port to GNUstep.
>>
>> Eric
>>
>
> [snip]
>
>
>
>