220 26226 article Path: news.gmane.org!not-for-mail From: alexander.zywicki@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Thu, 9 Jun 2016 19:26:36 -0700 (PDT) Lines: 585 Approved: news@gmane.org Message-ID: 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> <4922d8b8-7909-44a2-a24f-8dcf4090911f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1517_1134889615.1465525596934" X-Trace: ger.gmane.org 1465525610 2414 80.91.229.3 (10 Jun 2016 02:26:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 02:26:50 +0000 (UTC) Cc: alexander.zywicki@gmail.com, ross.bencina@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCS7TY6DTQOBBXWK5C5AKGQE2CVUWBY@isocpp.org Fri Jun 10 04:26:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBC9g-00089f-HC for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 04:26:40 +0200 Original-Received: by mail-qk0-f199.google.com with SMTP id l185sf116796842qkc.0 for ; Thu, 09 Jun 2016 19:26:40 -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=P6AyvTYaufQ9fRDc048fSSgvu5ubNP4vmeAbkrWofds=; b=ofvl0LmOToA6uS/rh2XAQ5Bm0kIwtE+6CuNM2bdZ13vcBC3v3jganc/tV74LRBqYoM VkwHToLv0FDHhCF6od9Kv10Vv2+FbNffCRuIJN6aSv1yenR0o2NuA8fxnSZi7GmqnQyW Uib1mJIFOuSdxb+k6EsRXDQ1JlFI7rAESSmwo1bUKVS/cjjA0Rc59roBcgpDJ651k5/8 V7sQ2j06tS6iNqPBNYp4W+TG2q9cNgsA3UtB6U3fTSmFJlq+HsQ+qGXhe5gE5jA9p91Y L00msOcpv995PoiVpERt4kGzbE5ToX+uTPrE5SA7T6+Imv2qrbbEHHs5gZt11rc9nQ5O lMqg== 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=P6AyvTYaufQ9fRDc048fSSgvu5ubNP4vmeAbkrWofds=; b=TViIWE2XZRFtUQm+sddaylrUK9O1sUP/PxHAjUkCh2AqavBliWnNGnuX8uFOUwagfp nDYGFf1D3oN8sLyDJikzOtLCPCr1pJ75ZRIKrA4L/l5QE3LypEm6f+RPugmxYp07ugqC A9azGz7ALu24GDiA4h6o+4U/Q6dieNaEpmzW93r3u5hijgsrkn598C03qKNg8YVZsFRS dn0ccZakXoOTST/VRrL8pbix8UW2QAsYw18+Pac7p6Y8EuKNG50brtGJdtADvRjsWq8o /e2+oYVJw5320pZI4aDF6MCQPqSLkF5IR6OERm/HYX+RYF9EleRTs5ruNFZJ0ieHBFm4 3Kmw== 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=P6AyvTYaufQ9fRDc048fSSgvu5ubNP4vmeAbkrWofds=; b=NyivGibkk9bC5WXz+RubuEJgZz0mvqpca6xEsSj9Ch1gm9oN6mwapYNaVtH6/ywMgg H/pWXO/SpSH/X19axIu90KKYq3HPAWMG9g+D8uplXyTEXoGCIhoCB/wPjejwsY0ju8mJ NsE5zZ0c2rwk2n9vPmhKuo4fowiH7Z/6pCacieNB396KnobZ3dn28YGl9ABUHuTmGmQR eO1wTLIjLRCwq3ACCVcsJ7bkq/S5H43cFPM3z4PaYsY5m6bZXofBL7wklsT1EI/YVgt2 MBcgiMNSXt7K4CPVdd3APG9ahJhUrtA+MmZoJ1GbBvfvsPBe5RCdIQ0RS7PAFX/0Kr0R 7SaA== X-Gm-Message-State: ALyK8tJm+NmuAIR0mkV2Jxj1CYDgBavbAECzVxXhVtbbt5/EaDYTnwin4LNuIW2RUNedew== X-Received: by 10.129.153.205 with SMTP id q196mr17160340ywg.11.1465525599297; Thu, 09 Jun 2016 19:26:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.36.69 with SMTP id k66ls706741iok.22.gmail; Thu, 09 Jun 2016 19:26:38 -0700 (PDT) X-Received: by 10.36.110.207 with SMTP id w198mr4399itc.6.1465525598044; Thu, 09 Jun 2016 19:26:38 -0700 (PDT) In-Reply-To: <4922d8b8-7909-44a2-a24f-8dcf4090911f@isocpp.org> X-Original-Sender: alexander.zywicki@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:26226 Archived-At: ------=_Part_1517_1134889615.1465525596934 Content-Type: multipart/alternative; boundary="----=_Part_1518_1894493109.1465525596935" ------=_Part_1518_1894493109.1465525596935 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you have any suggestions as far as an explicit notion of time should be= =20 in this context? On Thursday, June 9, 2016 at 11:07:29 AM UTC-5, Ross Bencina wrote: > > 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 off= er=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 th= at=20 > can be used to synchronize input and output buffers. In PortAudio we offe= r=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= =20 > Pro 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 shoul= d=20 > be expressly prohibited from using blocking synchronisation primitives in= =20 > an audio callback. See e.g.=20 > http://www.rossbencina.com/code/real-time-audio-programming-101-time-wait= s-for-nothing > > - There needs to be some mechanism to signal asynchronous failures (commo= n=20 > for example on OS X where the audio subsystem can reconfigure itself whil= e=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=20 > days (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/BufferingLatencyAndTimingImp= lementationGuidelines > > 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 ro...@audiomulch.com=20 > ), I'm 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=20 > 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 th= e=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 implemen= t. =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 floa= t=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 b= e 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 f= or=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 wrot= e: >>>> > >>>> > > 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 ima= ge >>>> > >>>> > > 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?= =20 >>>> How 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=20 >>>> work 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 t= o=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 propo= sal=20 >>>> (e.g. if I proposed an audio library for C++, I should be laughed off = the=20 >>>> stage), but we can overcome that by asking well-known audio users for = their=20 >>>> opinions before standardizing the proposal. >>>> > >>>> > >>>> > Jeffrey >>>> >>>> I agree about the issue of expertise. By no means would I call myself= =20 >>>> an expert, but I have a degree in audio engineering and a pretty solid= =20 >>>> grasp of the c++ language. Are there people out there more skilled tha= n me=20 >>>> at each topic? Of course, but that's why I am here, to get the opinion= s 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-= 5de5-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/fa20d105-71df-445b-a773-6de77ece5c09%40isocpp.or= g. ------=_Part_1518_1894493109.1465525596935 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do you have any suggestions as far as an explicit notion o= f time should be in this context?

On Thursday, June 9, 2016 at 11:07= :29 AM UTC-5, Ross Bencina wrote:
Hello Everyone,

I've been involv= ed with PortAudio since the beginning. PortAudio supports 10+ audio APIs. I= didn'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] = recently. Although I'm not a modern C++ guru, I can offer some insights= about the API and requirements. In particular things that PortAudio doesn&= #39;t do (or doesn't do very well).

Here's= a bit of a braindump:

- The streams (read(), writ= e()) model is problematic if you want to do synchronous input/output (i.e. = audio processing, or some forms of echo cancellation). The problem is that = there is no explicit notion of time that can be used to synchronize input a= nd output buffers. In PortAudio we offer both streams and callback. Most mo= dern native APIs use callbacks or something equivalent. There are arguments= for streams too, I'm don't remember them.

- Enumerating capabilities is a can of worms. There is a wide variety of c= apability managment systems out there. Some of the challenges include: slow= speed of accessing native device information, non-orthogonal formats of de= vice information, non-observable constraints between device capabilities (e= ..g. this device supports 96k, but only in stereo, 44k 8 channel is ok thoug= h!).

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

- A model o= f time seems to be lacking from the current proposal. There should be a way= to correlate input/output samples with a system monotonic clock. This mean= s you also need to be able to provide latency information.

- Periodicity of callbacks (or not) and fraction of total callback= period 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.rossb= encina.com/code/real-time-audio-programming-101-time-waits-f= or-nothing

- There needs to be some mechanism = to signal asynchronous failures (common for example on OS X where the audio= subsystem can reconfigure itself while audio is playing back).
<= br>
- Latency control (most APIs provide support for adjusting bu= ffer sizes, and many also have different modes for low/high latency applica= tions, e.g. bypass high-latency mixing).

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

At a minim= um I recommend reviewing the documentation for PortAudio, CoreAudio, WASAPI= , ALSA and JACK to make sure that you have all of the domain elements.

A while ago I compiled some notes on buffering models = in different audio APIs, it might be useful:


<= div>As an idea: you could consider building a demonstration implementation = on top of PortAudio (either starting from our existing 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 comment here. I think if= we are to attempt to move forward a consensus must be reached about the fu= ndamental representation of audio data the library will take.

C++ std::audio library

theory and defini= tions:

=C2=A0=C2=A0=C2=A0 sample:
=C2=A0=C2=A0=C2=A0 a single sam= ple of audio data.
=C2=A0=C2=A0=C2=A0 can be represented by a signed int= eger, float or double.
=C2=A0=C2=A0=C2=A0 must pass the following test t= o be a valid sample type:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((s= td::is_integral<T>::value && std::is_signed<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/desired

=C2=A0=C2=A0= =C2=A0 frame:
=C2=A0=C2=A0=C2=A0 a collection of 0-N samples
=C2=A0= =C2=A0=C2=A0 each sample represents an individual channel 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 of reading and writing au= dio data
=C2=A0=C2=A0=C2=A0 can be polled for information regarding the = capabilities of the device/interface


=C2=A0=C2=A0=C2=A0 audio ca= llback:
=C2=A0=C2=A0=C2=A0 a function/lambda/functor registered with the= library to be called once per buffer interval

=C2=A0=C2=A0=C2=A0 sa= mpling rate: the number of samples per second of audio data

=C2=A0= =C2=A0=C2=A0 frame interval: the length of a frame in seconds (1.0/sample_r= ate)
=C2=A0=C2=A0=C2=A0 buffer interval: the length of a buffer in secon= ds (frame_interval* buffer_size)

What= should be added/removed/edited or clarified?


On Fri= day, June 3, 2016 at 9:11:26 PM UTC-5, Ron wrote:
Okay, I've done some thinking here.= =C2=A0 The simplest solution should be the correct one.=C2=A0 I think the s= tandard should stick to something very basic here, otherwise we get into an= area that is too complicated to implement.=C2=A0 All we should have in ter= ms of a standard audio interface for C++ is:

1) A = method for enumerating the interfaces on a machine.
2) A method f= or getting each interfaces capabilities (supported rates, bit depths etc.).=
3) A method for activating a requested device for sending and re= ceiving frames in the requested format.

Valid type= s 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 outp= ut.=C2=A0 Anything other than that would be a different proposal all togeth= er.=C2=A0 Audio, video or DSP processing in general should certainly be a d= ifferent proposal.

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

Something more fully featured would be desir= able, like this: https://github.com= /RonNovy/CppDSP/blob/master/src/int24_t.h
But I gue= ss that, would be another proposal.

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 wro= te:
> 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/fa20d105-71df-445b-a773-6de77ece5c09= %40isocpp.org.
------=_Part_1518_1894493109.1465525596935-- ------=_Part_1517_1134889615.1465525596934-- .