Re: [Agenda] Audio WG Teleconference, 22 August

Hi Joe, all

Too late for today as we already adjourned (sorry for those who missed it - and I know the changes in time haven't really helped) but this sounds like something we can look at and wrap up soon, yes. 

Olivier

On 22 Aug 2012, at 18:46, "Joseph Berkovitz" <joe@noteflight.com> wrote:

> Dear Olivier,
> 
> I would like to to propose (possibly for a later call if we run out of time today) that we resume an agendum that was dropped from a previous call due to lack of a quorum: loop start/stop points.  (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390)
> 
> Thank you!
> 
> ...Joe
> 
> 
> On Aug 22, 2012, at 11:41 AM, olivier Thereaux wrote:
> 
>> Hi group,
>> 
>> Here is a slightly more detailed agenda for our teleconference. 
>> See you on the bridge in 20 minutes.
>> 
>> 
>> On the Agenda:
>>  Agenda+ Renaming interfaces
>>  Agenda+ Remaming noteOn/noteOff to start/stop or play/stop
>>  Agenda+ Renaming setTargetValueAtTime (and other AudioParam methods)
>>  Agenda+ Naming consistency for Create methods
>>  Agenda+ Teleconference schedule
>> 
>> Time permitting:
>>  Agenda+ Renaming JavaScriptAudioNode
>>  Agenda+ Revisiting the circular graph issue
>> 
>> Probably later:
>>  Agenda+ MIDI API naming
>> 
>> 
>> 
>> 
>> ** Topic: Renaming interfaces
>> 
>> The main issue is to balance the desire for interface names that make sense (should ideally be self explanatory and consistent with the rest of the spec).
>> We have discussed this a little bit at a teleconference back in May:
>> http://www.w3.org/2012/05/02-audio-minutes.html#item02
>> 
>> If we decide to change the name of an interface, then in almost all cases, our options would be:
>> - We change the name in the spec. 
>>  Webkit implementation keeps supporting (or not) for webkit-prefixed code
>> - An informative note in the spec about the old name 
>>  (ditto above for webkit-prefixed code)
>> - Normative mention of both names in the spec, 
>>  with mention that the "bad" one is deprecated
>> 
>> ChrisW has written about this:
>> http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0569.html
>> 
>> 
>> ** Topic: Remaming noteOn/noteOff to start/stop or play/stop
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17344
>> http://www.w3.org/2012/05/02-audio-minutes.html#item02
>> 
>> Back in May, there seemed to be general consensus that noteOn/noteOff was not the best name. start/stop was proposed and liked, and there was another proposal for play/stop. The question seems to be about what happens to noteOn/noteOff. 
>> 
>> 
>> ** Topic: Renaming setTargetValueAtTime (and other AudioParam methods)
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17334
>> 
>> This proposed list got a large number of +1's 
>> - AudioParam.set(value, time)
>> - AudioParam.linearRamp(value, time)
>> - AudioParam.exponentialRamp(value, time)
>> - AudioParam.approach(target, time, k)
>> - AudioParam.curve(value_set, time, duration)
>> 
>> ** Topic: Naming consistency for Create methods
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18332
>> Did not get a lot of discussion yet.
>> 
>> 
>> ** Topic: Teleconference schedule
>> 
>> Whether, how often, and when.
>> 
>> 
>> ** Topic: Renaming JavaScriptAudioNode
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17348
>> This one is complicated. I am guessing the solution will be architectural (whether we have a WorkerNode, etc) rather than a pure naming issue. 
>> 
>> 
>> ** Topic: Revisiting the circular graph issue
>> 
>> Summarised here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17326
>> We need more work on this to get to a resolution. I'd like the group to think about how we can inform our decision better.
>> 
>> 
>> ** Topic: MIDI API naming
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17724
>> We might wait until officially chartered to work on MIDI to discuss this. That said, since we want to publish an FPWD soon, we may want to give it a thought or two sooner rather than later.
>> 
>> 
>> Olivier
>> 
>> On 20 Aug 2012, at 11:32, olivier Thereaux wrote:
>> 
>>> Dear all,
>>> 
>>> Based on your feedback (on the list and directly), here is the agenda for the upcoming group teleconference.
>>> 
>>> When: Wednesday 22nd August, noon Boston for 60-90 minutes
>>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=8&day=22&hour=16&min=0&sec=0&p1=224&p2=43&p3=136&p4=291&p5=195&p6=237&p7=22
>>> 
>>> Logistics: http://www.w3.org/2011/audio/wiki/Main_Page#Telcon_Times
>>> 
>>> Proposed Agenda:
>>> 1) renaming some of the interfaces in the web audio API (and MIDI API)
>>> Read more:
>>> 	http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0569.html
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17344
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17334
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=18332
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17348
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17724
>>> 
>>> (we will probably split this agenda into several, e.g cover start/stop, JSAudioNode and the MIDI interfaces naming separately)
>>> 
>>> 
>>> 2) Teleconference schedule
>>> Lessons from a async-only summer. Should we get back to a weekly teleconference pace from September onwards? 
>>> 
>>> 
>>> 3) [time permitting] Revisiting the circular graph (and sample rate limits) issue, which I believe got dropped from view in the past couple of months.
>>> Read more:
>>> 	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17326
>>> 
>>> 
>>> Thanks,
>>> Olivier
>> 
> 
> ... .  .    .       Joe
> 
> Joe Berkovitz
> President
> 
> Noteflight LLC
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com
> 

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.