220 26222 <4922d8b8-7909-44a2-a24f-8dcf4090911f@isocpp.org> article Path: news.gmane.org!not-for-mail From: Ross Bencina Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Thu, 9 Jun 2016 09:07:29 -0700 (PDT) Lines: 544 Approved: news@gmane.org Message-ID: <4922d8b8-7909-44a2-a24f-8dcf4090911f@isocpp.org> References: <5751B06A.4080501@mail1.stofanet.dk> <5290948.va25uYNizX@tjmaciei-mobl1> <1580229.cHEgQxCuA1@tjmaciei-mobl1> <62b7649a-5de5-4330-9bac-708375d36e2c@isocpp.org> <3c0fde91-671d-4751-955d-7b04cfa120bc@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_133_45814346.1465488449899" X-Trace: ger.gmane.org 1465488461 20444 80.91.229.3 (9 Jun 2016 16:07:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jun 2016 16:07:41 +0000 (UTC) Cc: alexander.zywicki@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDWNJVP63IJBBQ5I425AKGQEZQXGTFA@isocpp.org Thu Jun 09 18:07:34 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bB2UW-0005DV-R9 for gclcip-std-proposals@m.gmane.org; Thu, 09 Jun 2016 18:07:33 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id c127sf30024733vkb.1 for ; Thu, 09 Jun 2016 09:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SrE6h4oQW9K0ScShqaym/fohoSg1J8GomWOot9vEjuk=; b=w4iFXsVHVCo2Gsi+HRQFjHBAoGYAsjFwKejI55rqpZc5nEqjm6PhOyETinBKbd2+hq JE7PSmRYA28lr/xg9o9JQoRxCg4Z1sz6PV4WFWjyU4V5KRTlWCL41huzWSKxe6D9oWfX sYV4T9SPIsr36D6rY2Q9vqJ5ozkdazlVKm4SP1TajkaQ5I3LkrwLY84u0nmqDUzauSYK hJdd4sAR11GDmgnyVJBRdESNuwe3mhCw7i5t3s94W2Fv/6dwXgYq2LgCpqy6Q78ZvsCa zA+xjaGxsMkZAuY0vd66HYRqSoEvkO0S+AadEUUcLSlrudLcTXCs9KIgl2rDl0AIooX/ zMhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SrE6h4oQW9K0ScShqaym/fohoSg1J8GomWOot9vEjuk=; b=qZEEIfYYzQBYNqsnUzOAjZLUmVjKjjmjkTdfQN6Bm0iZEQ0k1KVCmjXQagAAC8qomv 7uS6G2oalTGca+ZyE40IbtnqCLrk1iHSSKuftArUvgiPd9Cgj/LmVNP6nxmNWMPo3Z7Y sx9emoiIM9AMd1rvIgUGITciJnarrwdtyjQvKlpGFEj1bPKd5h0JQU3+9BmkoBWywugx gFuEe481HL1Lzez6pDgiu94gMzJ1UvPEYh2y8f92OV5dbthM+nZ5805bIy1q4W2OGQMD j18GWpBmWR79N6p8E2ex79nSYjOz4/we0mzZuJNza+8HYjww069XIIhSzKqFFCOm3NdW 2+uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=SrE6h4oQW9K0ScShqaym/fohoSg1J8GomWOot9vEjuk=; b=AcTBSb6z+Q1zKqWBwp2rwrpMAuLrLWYz45bwwu7hGVLNHm1RA5lDNg3C+jod717xpz ARaP2/4eXmwYtgMRO4WL9I2vAJM/I8lBkXq4uSDL0k8YOugnaccVxYKf9YQTOm28AATm ESg+uuylqJZBEp1wc4pFBdHJjE8yyOjDdwS5yAunEKY6yuDxgltHVbi01BYy4SeSMEel ovM/gJ1oUBTHiIYTlf0UsLl/4JRme9ZZ2fVhACLg62BmZfJgOLO2DaaMGAK97Fs5t19S zPAe3EZF9uz8pHWZ5FiqUf5Fuo5m8MyIXa7DjCSIxyc6n4/tzHXIalQIp7oDzJXsY6P4 wBvg== X-Gm-Message-State: ALyK8tJUA9ajE/OnqeP2gvbw9JeXyAbBu6Lvvs5Y5O8gaA9cr7BAf20lb/e+MP84YcRRwg== X-Received: by 10.140.225.207 with SMTP id v198mr24945016qhb.6.1465488451906; Thu, 09 Jun 2016 09:07:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.77.195 with SMTP id l186ls454225itb.6.gmail; Thu, 09 Jun 2016 09:07:30 -0700 (PDT) X-Received: by 10.36.20.206 with SMTP id 197mr531541itg.3.1465488450627; Thu, 09 Jun 2016 09:07:30 -0700 (PDT) In-Reply-To: <3c0fde91-671d-4751-955d-7b04cfa120bc@isocpp.org> X-Original-Sender: ross.bencina@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:26222 Archived-At: ------=_Part_133_45814346.1465488449899 Content-Type: multipart/alternative; boundary="----=_Part_134_1923840484.1465488449900" ------=_Part_134_1923840484.1465488449900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Everyone, I've been involved with PortAudio since the beginning. PortAudio supports= =20 10+ audio APIs. I didn't write all the implementations myself, but I've=20 worked with the people who did. I use C++ almost daily and have been=20 lurking in [sg14] recently. Although I'm not a modern C++ guru, I can offer= =20 some insights about the API and requirements. In particular things that=20 PortAudio doesn't do (or doesn't do very well). Here's a bit of a braindump: - The streams (read(), write()) model is problematic if you want to do=20 synchronous input/output (i.e. audio processing, or some forms of echo=20 cancellation). The problem is that there is no explicit notion of time that= =20 can be used to synchronize input and output buffers. In PortAudio we offer= =20 both streams and callback. Most modern native APIs use callbacks or=20 something equivalent. There are arguments for streams too, I'm don't=20 remember them. - Enumerating capabilities is a can of worms. There is a wide variety of=20 capability managment systems out there. Some of the challenges include:=20 slow speed of accessing native device information, non-orthogonal formats= =20 of device information, non-observable constraints between device=20 capabilities (e.g. this device supports 96k, but only in stereo, 44k 8=20 channel is ok though!). - You may want to clarify who this API is targeted at. (Will it support Pro= =20 Audio?) - A model of time seems to be lacking from the current proposal. There=20 should be a way to correlate input/output samples with a system monotonic= =20 clock. This means you also need to be able to provide latency information. - Periodicity of callbacks (or not) and fraction of total callback period= =20 that can be consumed should be documented. - Concurrency issues need to be clearly documented. For example, it should= =20 be expressly prohibited from using blocking synchronisation primitives in= =20 an audio callback. See=20 e.g. http://www.rossbencina.com/code/real-time-audio-programming-101-time-w= aits-for-nothing - There needs to be some mechanism to signal asynchronous failures (common= =20 for example on OS X where the audio subsystem can reconfigure itself while= =20 audio is playing back). - Latency control (most APIs provide support for adjusting buffer sizes,=20 and many also have different modes for low/high latency applications, e.g.= =20 bypass high-latency mixing). - Robert already mentioned hot-plug. This is a must-have feature these days= =20 (although PortAudio doesn't yet support it) At a minimum I recommend reviewing the documentation for PortAudio,=20 CoreAudio, WASAPI, ALSA and JACK to make sure that you have all of the=20 domain elements. A while ago I compiled some notes on buffering models in different audio=20 APIs, it might be useful: https://www.assembla.com/wiki/show/portaudio/BufferingLatencyAndTimingImple= mentationGuidelines Unfortunately, right now I don't have time to participate much in this=20 discussion due to deadlines. But if this proposal is serious, if someone=20 would like to send me drafts for review (to rossb@audiomulch.com), I'm=20 happy to give feedback. As an idea: you could consider building a demonstration implementation on= =20 top of PortAudio (either starting from our existing C++ binding, or from=20 scratch). Kind Regards, Ross. On Saturday, June 4, 2016 at 2:04:21 PM UTC+10, alexande...@gmail.com wrote= : > > I have drafted up a list of basic definitions about how audio could be=20 > represented based on your comment here. I think if we are to attempt to= =20 > move forward a consensus must be reached about the fundamental=20 > representation of audio data the library will take.=20 > > C++ std::audio library > > theory and definitions: > > sample: > a single sample of audio data. > can be represented by a signed integer, float or double. > must pass the following test to be a valid sample type: > ((std::is_integral::value && std::is_signed::value) ||=20 > std::is_floating_point::value) =3D=3D true > or could be constrained by: > std::is_arithmetic::value=3D=3Dtrue > if unsigned samples are allowed/desired > > frame: > a collection of 0-N samples > each sample represents an individual channel of audio data > indexable as an array > (should N be runtime or compile time?) > > buffer: > a collection of 0-N frames > indexable as an array > (should N be runtime or compile time?) > ideally maintains a continous piece of memory to house its frames > > device /interface: > a device recognized by the system as being capable of reading and=20 > writing audio data > can be polled for information regarding the capabilities of the=20 > device/interface > > > audio callback: > a function/lambda/functor registered with the library to be called=20 > once per buffer interval > > sampling rate: the number of samples per second of audio data > > frame interval: the length of a frame in seconds (1.0/sample_rate) > buffer interval: the length of a buffer in seconds (frame_interval*= =20 > buffer_size) > > What should be added/removed/edited or clarified? > > > On Friday, June 3, 2016 at 9:11:26 PM UTC-5, Ron wrote: >> >> Okay, I've done some thinking here. The simplest solution should be the= =20 >> correct one. I think the standard should stick to something very basic= =20 >> here, otherwise we get into an area that is too complicated to implement= .. =20 >> All we should have in terms of a standard audio interface for C++ is: >> >> 1) A method for enumerating the interfaces on a machine. >> 2) A method for getting each interfaces capabilities (supported rates,= =20 >> bit depths etc.). >> 3) A method for activating a requested device for sending and receiving= =20 >> frames in the requested format. >> >> Valid types for audio samples should be either a signed integer, a float= =20 >> or a double. And that's pretty much it. Get audio input, put audio=20 >> output. Anything other than that would be a different proposal all=20 >> together. Audio, video or DSP processing in general should certainly be= a=20 >> different proposal. >> >> But I would propose we also add an int24_t class into the standard for= =20 >> processing 24-bit samples. Something as simple as this would suffice fo= r=20 >> now: >> class int24_t >> { >> private: >> int8_t val[3]; >> }; >> >> Something more fully featured would be desirable, like this:=20 >> https://github.com/RonNovy/CppDSP/blob/master/src/int24_t.h >> But I guess that, would be another proposal. >> >> On Fri, Jun 3, 2016 at 6:47 PM, wrote: >> >>> On Friday, June 3, 2016 at 8:30:49 PM UTC-5, Jeffrey Yasskin wrote: >>> > On Fri, Jun 3, 2016 at 6:09 PM, Thiago Macieira = =20 >>> wrote: >>> > On s=C3=A1bado, 4 de junho de 2016 02:20:15 BRT Andrey Semashev wrote= : >>> > >>> > > What is needed is a standardized interface for these different=20 >>> modules >>> > >>> > > to work with each other. The interface should also allow me, the >>> > >>> > > developer, to work with the media (e.g. create my own audio or imag= e >>> > >>> > > filter or a new codec or a new device driver). >>> > >>> > >>> > >>> > That I agree with. >>> > >>> > >>> > >>> > But should the standard mandate that there should be at least one? Ho= w=20 >>> does >>> > >>> > someone write a plugin to the C++ Standard Library? Will we now=20 >>> mandate this >>> > >>> > kind of ability? >>> > >>> > >>> > >>> > Yes. We already do this with things like the random engines. >>> > >>> > >>> > If not, then will there be a requirement that the C++ library vendor= =20 >>> provide >>> > >>> > it? If so, please think carefully how Apple should code libc++ to wor= k=20 >>> on iOS. >>> > >>> > >>> > >>> > WebCrypto has an example of navigating a legal minefield for=20 >>> implementers. >>> > >>> > >>> > >>> > Also remember to leave the legal speculation to lawyers. It's good to= =20 >>> have the heads-up that "hey lawyers should look at this", but anything = more=20 >>> is unwise. >>> > >>> > >>> > Again, I think this is not material for the C++ Standard Library. >>> > >>> > >>> > I think it's a great area for the C++ library to expand into. I'm=20 >>> definitely worried about the expertise of the people writing the propos= al=20 >>> (e.g. if I proposed an audio library for C++, I should be laughed off t= he=20 >>> stage), but we can overcome that by asking well-known audio users for t= heir=20 >>> opinions before standardizing the proposal. >>> > >>> > >>> > Jeffrey >>> >>> I agree about the issue of expertise. By no means would I call myself a= n=20 >>> expert, but I have a degree in audio engineering and a pretty solid gra= sp=20 >>> of the c++ language. Are there people out there more skilled than me at= =20 >>> each topic? Of course, but that's why I am here, to get the opinions of= =20 >>> those people if I can an figure out what needs to be done to make this= =20 >>> library a reality. >>> >>> -- >>> You received this message because you are subscribed to the Google=20 >>> Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to std-proposal...@isocpp.org. >>> To post to this group, send email to std-pr...@isocpp.org. >>> To view this discussion on the web visit=20 >>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62b7649a-5= de5-4330-9bac-708375d36e2c%40isocpp.org >>> . >>> >> >> --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/4922d8b8-7909-44a2-a24f-8dcf4090911f%40isocpp.or= g. ------=_Part_134_1923840484.1465488449900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,

I've been involved = with PortAudio since the beginning. PortAudio supports 10+ audio APIs. I di= dn't write all the implementations myself, but I've worked with the= people who did. I use C++ almost daily and have been lurking in [sg14] rec= ently. Although I'm not a modern C++ guru, I can offer some insights ab= out the API and requirements. In particular things that PortAudio doesn'= ;t do (or doesn't do very well).

Here's a = bit of a braindump:

- The streams (read(), write()= ) model is problematic if you want to do synchronous input/output (i.e. aud= io processing, or some forms of echo cancellation). The problem is that the= re is no explicit notion of time that can be used to synchronize input and = output buffers. In PortAudio we offer both streams and callback. Most moder= n native APIs use callbacks or something equivalent. There are arguments fo= r streams too, I'm don't remember them.

- = Enumerating capabilities is a can of worms. There is a wide variety of capa= bility managment systems out there. Some of the challenges include: slow sp= eed of accessing native device information, non-orthogonal formats of devic= e information, non-observable constraints between device capabilities (e.g.= this device supports 96k, but only in stereo, 44k 8 channel is ok though!)= ..

- You may want to clarify who this API is target= ed at. (Will it support Pro Audio?)

- A model of t= ime seems to be lacking from the current proposal. There should be a way to= correlate input/output samples with a system monotonic clock. This means y= ou also need to be able to provide latency information.

- Periodicity of callbacks (or not) and fraction of total callback pe= riod that can be consumed should be documented.

- = Concurrency issues need to be clearly documented. For example, it should be= expressly prohibited from using blocking synchronisation primitives in an = audio callback. See e.g.=C2=A0http://www.rossbencina.com/code/real-time-aud= io-programming-101-time-waits-for-nothing

- There = needs to be some mechanism to signal asynchronous failures (common for exam= ple on OS X where the audio subsystem can reconfigure itself while audio is= playing back).

- Latency control (most APIs provi= de support for adjusting buffer sizes, and many also have different modes f= or low/high latency applications, e.g. bypass high-latency mixing).

- Robert already mentioned hot-plug. This is a must-have = feature these days (although PortAudio doesn't yet support it)

At a minimum I recommend reviewing the documentation for P= ortAudio, CoreAudio, WASAPI, ALSA and JACK to make sure that you have all o= f the domain elements.

A while ago I compiled some= notes on buffering models in different audio APIs, it might be useful:
https://www.assembla.com/wiki/show/portaudio/BufferingLatencyAndTimi= ngImplementationGuidelines

Unfortunately, righ= t now I don't have time to participate much in this discussion due to d= eadlines. But if this proposal is serious, if someone would like to send me= drafts for review (to rossb@audiomulch.com), I'm happy to give feedbac= k.

As an idea: you could consider building a demon= stration implementation on top of PortAudio (either starting from our exist= ing C++ binding, or from scratch).

Kind Regards,

Ross.



On Saturday,= June 4, 2016 at 2:04:21 PM UTC+10, alexande...@gmail.com wrote:
I have drafted up a list= of basic definitions about how audio could be represented based on your co= mment here. I think if we are to attempt to move forward a consensus must b= e reached about the fundamental representation of audio data the library wi= ll take.

C++ std::audio library
theory and definitions:

=C2=A0=C2=A0=C2=A0 sample:
=C2=A0=C2= =A0=C2=A0 a single sample of audio data.
=C2=A0=C2=A0=C2=A0 can be repre= sented by a signed integer, float or double.
=C2=A0=C2=A0=C2=A0 must pas= s the following test to be a valid sample type:
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ((std::is_integral<T>::value && std::is_si= gned<T>::value) || std::is_floating_point<T>::value) =3D= =3D true
=C2=A0=C2=A0=C2=A0 or could be constrained by:
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::is_arithmetic<T>::value=3D= =3Dtrue
=C2=A0=C2=A0=C2=A0=C2=A0 if unsigned samples are allowed/de= sired

=C2=A0=C2=A0=C2=A0 frame:
=C2=A0=C2=A0=C2=A0 a collection o= f 0-N samples
=C2=A0=C2=A0=C2=A0 each sample represents an individual ch= annel of audio data
=C2=A0=C2=A0=C2=A0 indexable as an array
=C2=A0= =C2=A0=C2=A0 (should N be runtime or compile time?)

=C2=A0=C2=A0=C2= =A0 buffer:
=C2=A0=C2=A0=C2=A0 a collection of 0-N frames
=C2=A0=C2= =A0=C2=A0 indexable as an array
=C2=A0=C2=A0=C2=A0 (should N be runtime = or compile time?)
=C2=A0=C2=A0=C2=A0 ideally maintains a continous piece= of memory to house its frames

=C2=A0=C2=A0=C2=A0 device /interface:=
=C2=A0=C2=A0=C2=A0 a device recognized by the system as being capable o= f reading and writing audio data
=C2=A0=C2=A0=C2=A0 can be polled for in= formation regarding the capabilities of the device/interface


=C2= =A0=C2=A0=C2=A0 audio callback:
=C2=A0=C2=A0=C2=A0 a function/lambda/fun= ctor registered with the library to be called once per buffer interval
<= br>=C2=A0=C2=A0=C2=A0 sampling rate: the number of samples per second of au= dio data

=C2=A0=C2=A0=C2=A0 frame interval: the length of a frame in= seconds (1.0/sample_rate)
=C2=A0=C2=A0=C2=A0 buffer interval: the lengt= h of a buffer in seconds (frame_interval* buffer_size)

What should be added/removed/edited or clarified?


On Friday, June 3, 2016 at 9:11:26 PM UTC-5, Ron wrote:
Okay, I've do= ne some thinking here.=C2=A0 The simplest solution should be the correct on= e.=C2=A0 I think the standard should stick to something very basic here, ot= herwise we get into an area that is too complicated to implement.=C2=A0 All= we should have in terms of a standard audio interface for C++ is:

1) A method for enumerating the interfaces on a machine.
2) A method for getting each interfaces capabilities (supported ra= tes, bit depths etc.).
3) A method for activating a requested dev= ice for sending and receiving frames in the requested format.
Valid types for audio samples should be either a signed integer= , a float or a double.=C2=A0 And that's pretty much it.=C2=A0 Get audio= input, put audio output.=C2=A0 Anything other than that would be a differe= nt proposal all together.=C2=A0 Audio, video or DSP processing in general s= hould certainly be a different proposal.

But I wou= ld propose we also add an int24_t class into the standard for processing 24= -bit samples.=C2=A0 Something as simple as this would suffice for now:
class int24_t
{
private:
=C2=A0 =C2=A0 = int8_t val[3];
};

Something more fully f= eatured would be desirable, like this: On Fri, Jun 3, 2016 at 6:47 PM, <alexande...@gmail.com> wrote:
=
On Friday, June 3, 2016 at 8:30:49 PM UTC-5,= Jeffrey Yasskin wrote:
> On Fri, Jun 3, 2016 at 6:09 PM, Thiago Macieira <thi...@ma= cieira.org> wrote:
> On s=C3=A1bado, 4 de junho de 2016 02:20:15 BRT Andrey Semashev wrote:=
>
> > What is needed is a standardized interface for these different mo= dules
>
> > to work with each other. The interface should also allow me, the<= br> >
> > developer, to work with the media (e.g. create my own audio or im= age
>
> > filter or a new codec or a new device driver).
>
>
>
> That I agree with.
>
>
>
> But should the standard mandate that there should be at least one? How= does
>
> someone write a plugin to the C++ Standard Library? Will we now mandat= e this
>
> kind of ability?
>
>
>
> Yes. We already do this with things like the random engines.
>
>
> If not, then will there be a requirement that the C++ library vendor p= rovide
>
> it? If so, please think carefully how Apple should code libc++ to work= on iOS.
>
>
>
> WebCrypto has an example of=C2=A0navigating a legal minefield for impl= ementers.
>
>
>
> Also remember to leave the legal speculation to lawyers. It's good= to have the heads-up that "hey lawyers should look at this", but= anything more is unwise.
>
>
> Again, I think this is not material for the C++ Standard Library.
>
>
> I think it's a great area for the C++ library to expand into. I= 9;m definitely worried about the expertise of the people writing the propos= al (e.g. if I proposed an audio library for C++, I should be laughed off th= e stage), but we can overcome that by asking well-known audio users for the= ir opinions before standardizing the proposal.
>
>
> Jeffrey

I agree about the issue of expertise. By no means would I call mysel= f an expert, but I have a degree in audio engineering and a pretty solid gr= asp of the c++ language. Are there people out there more skilled than me at= each topic? Of course, but that's why I am here, to get the opinions o= f those people if I can an figure out what needs to be done to make this li= brary a reality.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62b= 7649a-5de5-4330-9bac-708375d36e2c%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/4922d8b8-7909-44a2-a24f-8dcf4090911f= %40isocpp.org.
------=_Part_134_1923840484.1465488449900-- ------=_Part_133_45814346.1465488449899-- .