Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Wednesday 05 February 2003 6:18 pm, Tim Hockin wrote: > > That is a great feature of C++ but PortAudio is using 'C' not C++. So I > > think our only choices are #define and enum. PortAudio uses both. > > you can still use const variables - gcc with optimizations treats them like > defines, but w

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

> That is a great feature of C++ but PortAudio is using 'C' not C++. So I > think our only choices are #define and enum. PortAudio uses both. you can still use const variables - gcc with optimizations treats them like defines, but with type-safety. > Are enums better than #defines?? I am always t

RE: [linux-audio-dev] newest audio server for Linux (yep, yet another)

David O'Toole writes: > > > > Probably. I think it was Bjarne Stroustrup who said > > > something along the > > > lines of "Every use of a define is an instance of a programmer not > > > programming correctly." But I was just wondering if it was some > > > portability thing or something.

RE: [linux-audio-dev] newest audio server for Linux (yep, yet another)

> > Probably. I think it was Bjarne Stroustrup who said > > something along the > > lines of "Every use of a define is an instance of a programmer not > > programming correctly." But I was just wondering if it was some > > portability thing or something. > > I think the basic idea is not to

RE: [linux-audio-dev] newest audio server for Linux (yep, yet another)

> -Original Message- > From: Bob Ham [mailto:[EMAIL PROTECTED]] > > On Wed, 2003-02-05 at 00:26, Josh Haberman wrote: > > On Tue, 2003-02-04 at 13:41, Bob Ham wrote: > > > On Tue, 2003-02-04 at 20:47, Josh Haberman wrote: > > > > > > > Imagine being able to write to an API as simple and

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

>Gee, thanks. But Bjarne Stroustrup was probably writing about C++, which >allows constants to be associated with a class: > >const double Synth::DEFAULT_FRAME_RATE = 44100.0; > >For C++, this construct is preferable to using a #define because the scope >is limited to the class and would not co

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tuesday 04 February 2003 21:03, David Olofson wrote: > OTOH, I'll need a nice replacement for the ALSA sequencer, if the > thing is to be usable for anything but music and SFX playback on > other platforms. Currently, the most "portable" control API I have is > OSS rawmidi... *heh* Some suppor

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Wednesday 05 February 2003 05.21, Josh Haberman wrote: [...] > What platforms are not supported that you would like to see? There > is a list of currently supported platforms at > Well, that covers it, basically. I bet a few users of PDAs, consoles, vari

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tuesday 04 February 2003 21.47, Josh Haberman wrote: [...] > Right now the only ways to choose a callback model in Linux audio > applications are: > > * use JACK. Using JACK directly only makes sense for: >1. applications whose only possible use in in a JACK graph > (jackrack) 2. applicatio

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

Steve Harris wrote: On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin wrote: On Tue, 4 Feb 2003, Abramo Bagnara wrote: Despite that I strongly think that an audio server that not permit in native way the traditional approach (what you call blocking approach) will never achieve the dr

RE: [linux-audio-dev] newest audio server for Linux (yep, yet another)

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mike > Andrews > Sent: Tuesday, February 04, 2003 8:50 AM > To: [EMAIL PROTECTED] > Subject: Re: [linux-audio-dev] newest audio server for Linux (yep, yet > another) > >

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Mon, 3 Feb 2003, Paul Davis wrote: > no sign of that. this is the same old design. sigh. no sample sync, > the whole thing is still based on the idea of applications deciding > what and when to do their stuff. sigh, sigh, sigh. it looks like a > decent thing for network-based apps, but nothing

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

>Despite that I strongly think that an audio server that not permit in >native way the traditional approach (what you call blocking approach) >will never achieve the driving role we'd need. if linux developers continue to work with this traditional model, then yes, i think you are right and its a

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin wrote: > On Tue, 4 Feb 2003, Abramo Bagnara wrote: > > > Despite that I strongly think that an audio server that not permit in > > native way the traditional approach (what you call blocking approach) > > will never achieve the driving role we'

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, Feb 04, 2003 at 07:15:07 -0500, Taybin Rutkin wrote: > On Tue, 4 Feb 2003, Steve Harris wrote: > > > MAS itsself its not suitable for RT audio*, but I suggested that we might > > want some MAS<->JACK interfaces for network transparent audio, and left a > > bussiness card, they seemed enthu

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, 4 Feb 2003, Steve Harris wrote: > MAS itsself its not suitable for RT audio*, but I suggested that we might > want some MAS<->JACK interfaces for network transparent audio, and left a > bussiness card, they seemed enthusiastic, but I never heard back from the > MAS guys. Yes, I spoke to t

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, 4 Feb 2003, Abramo Bagnara wrote: > Despite that I strongly think that an audio server that not permit in > native way the traditional approach (what you call blocking approach) > will never achieve the driving role we'd need. Well, given that Ardour, amsynth, alsaplayer, and freqtweak al

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Mon, Feb 03, 2003 at 06:22:26 -0500, Ivica Bukvic wrote: > Kidding aside, this may prove to be so ubiquitous that it will quickly > overshadow all other implementations. It's the MAS audio server that is > going to be implemented into the X server itself and will be > network-transparent. I spo

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

Paul Davis wrote: > > >Kidding aside, this may prove to be so ubiquitous that it will quickly > >overshadow all other implementations. It's the MAS audio server that is > >going to be implemented into the X server itself and will be > >network-transparent. > > > >Slashdot just posted a news blurb

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

>Kidding aside, this may prove to be so ubiquitous that it will quickly >overshadow all other implementations. It's the MAS audio server that is >going to be implemented into the X server itself and will be >network-transparent. > >Slashdot just posted a news blurb on it: >http://slashdot.org/artic