On Thu, Nov 12, 2015 at 9:43 AM, Eric Carlson <eric.carl...@apple.com> wrote: > >> On Nov 12, 2015, at 9:34 AM, Philip Jägenstedt <phil...@opera.com> wrote: >> >> On Thu, Nov 12, 2015 at 9:07 AM, Garrett Smith <dhtmlkitc...@gmail.com >> <mailto:dhtmlkitc...@gmail.com>> wrote: >>> >>> On 10/19/15, Philip Jägenstedt <phil...@opera.com> wrote: >>>> On Tue, Sep 1, 2015 at 11:21 AM, Philip Jägenstedt <phil...@opera.com> >>>> wrote: >>>>> On Mon, Aug 31, 2015 at 9:48 PM, Domenic Denicola <d...@domenic.me> wrote: >>>>>> From: Eric Carlson [mailto:eric.carl...@apple.com] >>>>>> >>> >>> [...] >>>> I've filed a spec issue to make it so: >>>> https://github.com/whatwg/html/issues/262 >>>> >>>> If there's any implementor interest in pitch control that goes beyond >>>> (independently) or that, please file a separate issue. >>>> >>> >>> They won't. >>> >>> You can hold the standard of "they need to come here and post up >>> cogent arguments in favor of feature X", but it ain't gonna happen >>> that way. >>> >>> There just isn't a whole lot of money in music education. How many >>> music education companies are W3C members? >>> >>> Unlike technology companies like Facebook, Google, Nokia, Opera, and >>> other companies the post here, small music education operations like >>> artistworks, jammit, licklibrary, etc are more about their domain — >>> "music" — than they are about technology. >>> >>> Major music education websites are still using Flash; their developers >>> are busy fixing broken links, making the login feature, database, etc >>> work, etc. Flash is not nice but they apparently were not funded or >>> motivated enough by the existing HTML5 HTMLMediaElement to use it >>> instead. >>> >>> Control over playbackRate has a greater value than pitch control. But >>> those sites don't even allow the students to change the playbackRate >>> because they're still using Flash. >>> >>> You won't read posts here about what students have to say about it the >>> value of having HTML5 vs Flash, or independent control over pitch and >>> playbackRate. >> >> Have you investigated whether you can achieve your use cases using the >> Web Audio API? If it isn't possible, is there a small addition to Web >> Audio that would solve the problem? >> >> It is unfortunately quite hard to get all browser vendors (or even >> one) interested in implementing support for something that is only >> expected to benefit a niche use case, but we should strive to make >> available the primitives that would it possible to implement yourself. >> > I am actually quite ambivalent about this feature - it is currently broken > on OSX and it has never been implemented on iOS, but as far as I can see we > haven’t received a single bug report about this.
Ah. I removed webkitPreservesPitched entirely from Blink because it wasn't implemented on any platforms, maybe you could do the same on iOS? More importantly, is it possible to support this on iOS, and is it likely to bubble to the top of your priorities any time soon if it were added to the spec? I don't think it's high priority for anyone working on Chromium, but unless Safari and Firefox are ready to drop their prefixed APIs entirely it still seems like a good idea to get what little interop we can by standardizing. Philip