W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Loop points proposal

From: Joseph Berkovitz <joe@noteflight.com>
Date: Tue, 4 Sep 2012 11:25:05 -0400
Cc: Joseph Berkovitz <joe@noteflight.com>, Chris Rogers <crogers@google.com>, Audio Working Group <public-audio@w3.org>
Message-Id: <5B81718E-E64E-4223-B446-6852289A9E24@noteflight.com>
To: Gabriel Cardoso <gabriel.cardoso@inria.fr>
Hi Gabriel,

We did not discuss breaking out LoopMode as an object in its own right. I don't think that approach is inconsistent. It might be overkill in that it commits developers to a more complex approach of creating this additional object any time they want a loop behavior other than whole-sample.

I suppose that if we are going to cross the bridge on adding another descriptive object, we could do it now. In this approach, there could be an optional AudioBufferSourceNode attribute with type LoopBehavior (placeholder name), which would itself be a separate interface. LoopBehavior in turn could have attributes like mode, startTime and endTime, and could be potentially extended or subclassed in future API versions.  I don't see that app developers would be able to write these subclasses, though, since the implementation of any particular looping behavior would be native.

I'm curious what Chris's thoughts are on this alternative. It increases the number of objects the developer and API implementor must manage, but decreases the number of attributes on AudioBufferSourceNode. As yet I don't have a strong feeling one way or the other based purely on the external shape of the API.

With respect to loop crossfade (or any other type of crossfade), I agree that this can currently be implemented with multiple source nodes. 

…Joe


On Sep 3, 2012, at 8:02 AM, Gabriel Cardoso <gabriel.cardoso@inria.fr> wrote:

> Hi Joe, Chris
> 
> I had a look at it and it seems pretty easy to use and extendable.
> 
> However, as a developer, I would apreciate to be able to extend or override existing "loop modes" to implement my own behaviour. Did you discuss a more object oriented approach for loops (i.e.: passing a LoopMode object to an AudioBufferSourceNode) ? Would that be overkill or inconsistent ?
> 
> Here is a short video showing an advanced looping feature in a DAW :
> http://www.ehow.com/video_4949643_fruity-loops-studio-tutorial_-looping.html
> (the buffer plays once and then loops between two given loop points with crossfade)
> 
> Nevertheless, this particular feature looks easy to implement with your proposal using two AudioBufferSourceNode. This may be more than enough.
> 
> Gabriel
> 
> De: "Joseph Berkovitz" <joe@noteflight.com>
> À: "Audio Working Group" <public-audio@w3.org>
> Envoyé: Mercredi 29 Août 2012 23:25:10
> Objet: Loop points proposal
> 
> Hi Group,
> 
> Loop start/stop points are an important feature for some key music synthesis scenarios. To make some progress In advance of the next call, I would like to ask the group whether anyone has any comments, suggestions or objections to the loop points approach outlined here:
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390#c6
> 
> Chris R. and I have been corresponding on the subject both on and off list, and this represents my current thinking on loop points in a way that I believe accounts for his feedback.
> 
> Best,
> 
> ... .  .    .       Joe
> 
> Joe Berkovitz
> President
> 
> Noteflight LLC
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com
> 
> 
> 

... .  .    .       Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
Received on Tuesday, 4 September 2012 15:25:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 September 2012 15:25:43 GMT