220 26231 article Path: news.gmane.org!not-for-mail From: ron novy Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Thu, 9 Jun 2016 22:51:36 -0700 Lines: 195 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> <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11404722ccd1210534e6216c X-Trace: ger.gmane.org 1465537900 6098 80.91.229.3 (10 Jun 2016 05:51:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 05:51:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDO2TPGE4QNBB2VK5G5AKGQEP7FAWGQ@isocpp.org Fri Jun 10 07:51:40 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBFM3-0003FE-Vc for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 07:51:40 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id c72sf136286246ywb.1 for ; Thu, 09 Jun 2016 22:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=H9UJSl3rbNN8rT8Uo4KRsv91wvvb6f9Z2kpmvERH9OA=; b=tCIlYWtIKgQoLcd8Gb8Twtj7aG1esHlgmyYYPiHLWiOR+yNNti+t/dTyfKg4xbfaC3 oISiLQmvM7ZJn8SrmGx5DjIyZ5ZgNvuMMeV6Sl4YAsRCcs88EA81YtBwbvXQkdTAE+wQ 1UjDn9KNqraNOfk5cRLX3Q9nm4YDTT+apxFu+YZHeisFgnEFO8SU6aJgNT1Ma80ncj0k fE4hY4fT8zrcPjQ1Muh1+93j8+kA3oxVY+we2Ud/QRtjWrwZYv7p+SdXkSWPGrn7ilJH 2Fptr2lF/5t7tKoC9iCza0Cctrcd4gtNEO8gxPCDoXF1I/R53Oq/ojuSh94wpUAn9vJt a4Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=H9UJSl3rbNN8rT8Uo4KRsv91wvvb6f9Z2kpmvERH9OA=; b=Vd/f6AKeLfHzTmP7Qe3Hhp1j3WgCWWiufo+BLVM33CiqlHyNf8uAV/gxjuZEOBpnSd gLQNgcLwcXTydKwiJSResSGFN/xuEs88P0V85HK19RvWg6FDw+fwE9gA3Fowp+dbA3b5 BcpFHtguDJ9hYayWTEeYX7f1c+LvhYhvKU9Cr+m32UDY8RcH61j0oLTamkwJfrBoPY+i Qa7lkvCp13ekYKHgqQLJ5VyTUydb6Vpdfg01LyBem/BAP33yhVPC6zLbarFf4OsJmEoG +Sqh4VuQ7rYMWhSLKJnJKaSStCG1J0Oeml0W40+8jsB7+93dbzciLga+fM9QBatPdk5Q pj9Q== X-Gm-Message-State: ALyK8tKNlnrnr/2IylgPLB+kQ4ArE2blEWNSJlt0l7guEKhwIEtwiZwRq4lbPi59THVgOA== X-Received: by 10.140.144.65 with SMTP id 62mr124193qhq.25.1465537898956; Thu, 09 Jun 2016 22:51:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.197.132 with SMTP id v126ls707017iof.21.gmail; Thu, 09 Jun 2016 22:51:37 -0700 (PDT) X-Received: by 10.107.27.18 with SMTP id b18mr1103281iob.163.1465537897945; Thu, 09 Jun 2016 22:51:37 -0700 (PDT) Original-Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com. [2607:f8b0:4001:c0b::22a]) by mx.google.com with ESMTPS id y2si10372202ity.93.2016.06.09.22.51.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jun 2016 22:51:37 -0700 (PDT) Received-SPF: pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) client-ip=2607:f8b0:4001:c0b::22a; Original-Received: by mail-it0-x22a.google.com with SMTP id z189so173110514itg.0 for ; Thu, 09 Jun 2016 22:51:37 -0700 (PDT) X-Received: by 10.36.83.199 with SMTP id n190mr1181359itb.61.1465537897744; Thu, 09 Jun 2016 22:51:37 -0700 (PDT) Original-Received: by 10.64.29.204 with HTTP; Thu, 9 Jun 2016 22:51:36 -0700 (PDT) In-Reply-To: <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> X-Original-Sender: rsn10100@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) smtp.mailfrom=rsn10100@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:26231 Archived-At: --001a11404722ccd1210534e6216c Content-Type: text/plain; charset=UTF-8 Yes, I believe that would work. ;) On Thu, Jun 9, 2016 at 9:30 PM, wrote: > I suppose we could use the std::chrono library as a basis, and define a > clock type that has a dynamically set epoch. This would allow a time-point > to have a value relative to when the stream was started? > > So maybe the introduction of: > > std::audio::sample_clock;//a clock type that counts in frames(or samples) > /* > -has internal member of "rate" that is used for conversion > -keeps track of number of frames(or samples) elapsed > -can produce a time_point that is a real number of seconds from epoch. > -epoch can be reset > -clock will be synced with hardware??? if possible?? or good idea?? > > */ > std::chrono::time_point foo;//the current time > since epoch in seconds > > > > > > On Thursday, June 9, 2016 at 10:05:08 PM UTC-5, Ron wrote: >> >> >> On Thursday, June 9, 2016 at 7:26:37 PM UTC-7, alexande...@gmail.com >> wrote: >>> >>> Do you have any suggestions as far as an explicit notion of time should >>> be in this context? >>> >> >> As a suggestion, something I usually use is a start and end to the buffer >> and the rate of the buffer. Basically a class that has a value equal to >> the start frame of the given buffer, a value equal to the end frame of the >> buffer (or start of next frame) and a value equal to the frame rate. So >> you can derive a real for each, like start frames over frame rate and end >> frame over frame rate. From that you can get the seconds as a double or >> long double. >> >> class frame_ticks // or some name that better describes this... >> { >> uint64_t fstart; >> uint64_t fend; >> uint64_t frate; >> // ... >> }; >> >> Allowing the start value to be set or reset on starting or stopping >> record/playback is another feature that some might need here. And I >> don't recommend eliminating the rate portion from this class since it could >> lead to trouble where people are making assumptions they shouldn't, best to >> have them together. >> >> Also, I would not add other data to this class since it could be re-used >> elsewhere as is. Other properties of a buffer can be defined in another >> class/structure, but again this is just a suggestion... >> >> -- > 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 > email 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/83016a47-e902-4292-b109-652e811d17fb%40isocpp.org > > . > -- 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 email 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/CAOcFa%3DcUNbJ7qB8hqU8jnX18S%3D_CdapSAMHsnFur8thE-8PVHw%40mail.gmail.com. --001a11404722ccd1210534e6216c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I believe that would work. ;)

On Thu, Jun 9, 2016 at 9:30 PM, <alexander.zywicki@gmail.com> wrote:
I suppose we could use the std::chron= o library as a basis, and define a clock type that has a dynamically set ep= och. This would allow a time-point to have a value relative to when the str= eam was started?

So maybe the introduction of:

std::audio::sample_clock;//a clock type that counts in frames(or samples)
/*
-has internal m= ember of "rate" that is used for conversion
-keeps track of nu= mber of frames(or samples) elapsed
-can produce a time_point that is a r= eal number of seconds from epoch.
-epoch can be reset
-clock will be = synced with hardware??? if possible?? or good idea??

*/
std::chrono::time_point= <std= ::audio= ::sample_clock= > fo= o;//the= current time since epoch in seconds
<= br>



On Thursday, = June 9, 2016 at 10:05:08 PM UTC-5, Ron wrote:

On Thursday, June 9,= 2016 at 7:26:37 PM UTC-7, alexande...@gmail.com wrote:
Do you have any suggestions as = far as an explicit notion of time should be in this context?

As a suggestion, something I usually use is a start and end to the buf= fer and the rate of the buffer.=C2=A0 Basically a class that has a value eq= ual to the start frame of the given buffer, a value equal to the end frame = of the buffer (or start of next frame) and a value equal to the frame rate.= =C2=A0 So you can derive a real for each, like start frames over frame rate= and end frame over frame rate.=C2=A0 From that you can get the seconds as = a double or long double.

class frame_ticks =C2= =A0// or some name that better describes = this...
{
=C2=A0 =C2=A0 uint64_t fstart;
=C2= =A0 =C2=A0 uint64_t fend;
=C2=A0 =C2=A0 uint64_t frate;
=C2=A0 =C2=A0 // ...
};

Allowing the start value= to be set or reset on starting or stopping record/playback is another feat= ure that some might need here.=C2=A0 And I don't recommend eliminating the rat= e portion from this class since it could lead to trouble where people are m= aking assumptions they shouldn't, best to have them together.

Also, I would not add other data to this class since it could be re-used = elsewhere as is.=C2=A0 Other properties of a buffer can be defined in anoth= er class/structure, but again this is just a suggestion...

--
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-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/83016a47-e902-= 4292-b109-652e811d17fb%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/CAOcFa%3DcUNb= J7qB8hqU8jnX18S%3D_CdapSAMHsnFur8thE-8PVHw%40mail.gmail.com.
--001a11404722ccd1210534e6216c-- .