On Thu, Nov 12, 2015 at 10:55 AM, Garrett Smith <dhtmlkitc...@gmail.com>
> On 11/12/15, Philip Jägenstedt <phil...@opera.com> wrote:
>> On Thu, Nov 12, 2015 at 9:07 AM, Garrett Smith <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?
> https://html.spec.whatwg.org/multipage/embedded-content.html#audiotrack

I don't understand, isn't the AudioTrack API (enabling/disabling individual
audio tracks) separate a separate concern? Or are you saying that there's
no way to get the audio tracks separately into the Web Audio API in order
to process them differently? That is certainly true, and if having that
capability would allow you to solve the problem with the Web Audio API, I
think that seems like a powerful primitive to have.

>> 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.
> The situation where you want hear the audio at the desired pitch,
> while simultaneously watching the video at the desired speed, to see
> it performed, and to play along. It doesn't work well when trying to
> play to a video example, such as playing an open G chord, and the
> sound from the video does not match the sound from your own guitar.
> What I can do now on websites that use VIDEO, such as YouTube, is
> limited to using the web inspector (console). I click "inspect
> element" to find the VIDEO element, then change its DOM properties for
> playbackRate = .95 and mozPreservesPitch = false. That'll get
> everything down a half-step (although at 95% speed).
> For example, watch Andy James play "Harvester of Sorrow" but hear it
> 1/2 step down:
> https://www.youtube.com/watch?v=vYZjC_U1VJg
> 1) Right click on the video "Inspect Element"
> 2) Right click on the VIDEO in the HTML tab. Choose "Show DOM Properties"
> 3) set playbackRate: 0.95, mozPreservesPitch: 0
> Ed Van Halen, Yngwie Malmsteen, Jimi Hendrix, Zakk Wylde, to name a
> few tune down 1/2 step. Others, Black Sabbath, Racer X, have tuned
> down further.
> A=440 (standard tuning) is much more common. When you want to learn
> something played tuned down 1/2 step and your guitar is in standard
> tuning, it is a problem. Constantly retuning the instrument is not
> practical. Especially for guitars with locking nut systems or for
> other instruments like piano. I don't know about learning horn parts.
> Or you can buy multiple instruments and maintain different tunings for
> them.
> Fast passages, it's helpful to slow the speed down but keep the pitch
> as original and in some cases, you want to slow the speed down and
> adjust the pitch separately, so you can do things like learning Yngwie
> Malmsteen songs while using a guitar in standard tuning.
> I realize there's not much demand for it. But there seems to be
> separation of playback pitch with `preservesPitch` and `playbackRate`.
> It would be much better with a control to adjustm pitch, if it is not
> too much work.

Two things.

1. Do the underlying media frameworks that browsers are using support
arbitrary pitch changes, or do they also only have the limited
preservesPitch-style API?

2. I'm quite skeptical about changing prefixed APIs into something else
when standardizing and unprefixing, because that makes it harder for sites
to switch to the unprefixed API. In several cases the end result has been
that the prefixed API couldn't be removed, e.g. webkitMatchesSelector and
prefixed flexbox. IMHO, the prefixed API has to be *terrible*, not just
imperfect, to justify changes.


Reply via email to