all the OS X bits (__MACH__) relating to dirent code
are not compiling because they conflict with dirent.h.

Do they need to be there?

Victor


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It depends on which version of OSX you have!  I have 10.2 and it
compiled for me last time I tried.  Others seem to be rich enough
for 10.3 and it is very different wrt dirent.h

I think I have found someone to give me 10.4 on the university
machine, but home will remain 10.2 for the moment

==John ffitch


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> all the OS X bits (__MACH__) relating to dirent code
> are not compiling because they conflict with dirent.h.
> 
> Do they need to be there?

The #ifdefs were added by John ffitch, apparently the dirent.h
header is broken in the version of OS X he uses, and needs these
work-arounds. On the other hand, in newer releases of OS X,
dirent.h does work, and the hacks for the older version cause
problems as you noticed.
Is it possible to find out the version of OS X with #ifdefs ?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I built it in 10.2, but I have a reasonably recent set of development
tools (gcc 3.3 etc). I think the dirent problem might be with an older
development suite.

Any ideas why the OSX gcc doesn't like -gstabs (-g on its own is OK)?
I get an 'internal compiler error', which I suspect is a bug.

Victor

At 15:41 26/04/2005, you wrote:
>Victor Lazzarini wrote:
>
>>all the OS X bits (__MACH__) relating to dirent code
>>are not compiling because they conflict with dirent.h.
>>Do they need to be there?
>
>The #ifdefs were added by John ffitch, apparently the dirent.h
>header is broken in the version of OS X he uses, and needs these
>work-arounds. On the other hand, in newer releases of OS X,
>dirent.h does work, and the hacks for the older version cause
>problems as you noticed.
>Is it possible to find out the version of OS X with #ifdefs ?
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is there a way of knowing whether the user has tried to open the
same device, as in -odac -iadc?

Before the changes, it was possible to compare device numbers, since
rtin_dev and rtout_dev were globals. Now the device number is in
csRtAudioParms and it is not possible to do the hack I did before.

In other words: I need to know if the same device was open full-duplex,
if so we only open it once and use a separate full-duplex read & write
portaudio callback.

That's the only way to do full duplex in CoreAudio (or ASIO).  My hack was
to check if the device was the same, then open only once (either in recopen_
or playopen_). However this is ugly and the best thing would be to provide
an interface for opening the device once (recplayopen_ ?).

Can it be done? something ENVIRON::SetRecPlayopenCallback ?
This would be called in OSX (and possibly windows)
if the input and output are the same.

The problem is only really opening the portaudio only once and
registering with it a read/write callback; then paBlockingRead() and Write()
can be used as usual.

This fundamental difference needs to be resolved before any full-duplex
audio is possible on OSX or ASIO, with or without portaudio.

Victor


Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net