Re: Oscillators with time-domain custom wave shape

I think it is a bug, and I filed bug reports :

https://code.google.com/p/chromium/issues/detail?id=471675
https://bugzilla.mozilla.org/show_bug.cgi?id=1149053

A test case, included in those bug reports is there :
http://jsfiddle.net/gh144L2u/

Joe, in the case of a sawtooth, having a glitch is the whole point (as you
have a ramp and go back to 0 at the end of the ramp).

I talked very quickly with Paul which explained me that the glitch in the
test case might be due to BufferSourceNode being optimized for playbackRate
changing slowly. Also, what happens if say I have a buffer of 1 second, and
playbackRate is 234? How is the interpolation going to behave? Am I going
to really have a 234Hz oscillation, or is the interpolaton going to create
strange artifacts when looping over? And in consequence, if this is a job
for BufferSourceNode shouldn't it be a bit better specified so that this
use case is taken into account?

On Tue, Mar 31, 2015 at 11:08 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> FWIW I've extensively used BufferSourceNodes with modulated playbackRate
> in our application Noteflight which uses looped samples with continuously
> varying pitch. I'm not sure why you say this technique "doesn't work in
> Chrome", and it should generally be glitch free. If there are glitches,
> that would seem to be a bug.
>
> However it is k-rate rather than a-rate, and of course you have to make
> your BufferSourceNode loop perfectly from the last sample back to the
> first. If it doesn't manage to loop cleanly that can be a source of
> glitches.
>
> On Tue, Mar 31, 2015 at 2:27 PM, s p <sebpiq@gmail.com> wrote:
>
>> Hi Chris,
>>
>> I am not criticizing the oscillators. They are indeed good at what they
>> do :)
>>
>> At the moment, there is no way to make custom non-bandlimited oscillators
>> right?
>>
>> > If you need both file position and also a waveform, it would seem
>> better to use a loop,
>>
>> I am not sure I understand what you mean here. I mentioned synthesis just
>> as another use case , I don't actually need "both file position and also a
>> waveform" as you said.
>>
>> Basically, the initial idea for me was that I want to read a sound file
>> by using a WaveShaperNode instead of BufferSourceNode. What it provides, is
>> that you control directly the read position with another AudioNode, which
>> is amazingly flexible and allows to do a lot of very funny things by
>> connecting different types of control signals. You can read you sound with
>> ramps, exponential ramps, sine waves, triangle waves (
>> http://sebpiq.github.io/WAATableNode/demos/cello-drone.html) ... it is
>> hugely flexible. Now, I can also for example just loop the sample (as I
>> would for a BufferSourceNode), but vary the start position, end position of
>> the loop live (by using a sawtooth and adding an offset for start position,
>> and a gain for end position), and vary the playrate (by varying the
>> frequency of the sawtooth). This is not something I can do with a
>> band-limited oscillator. For these in fact, I need to be sure of what my
>> control signal is going to look like.
>> Once again, I know it might be hard to understand from a Web Audio
>> perspective, but this way of doing things come from the usage of Pure Data
>> and SuperCollider where this is THE way to playback buffers, and allows you
>> to easily do crazy things, granular synthesis, wavetable and so on ... and
>> the real reason why I need it is to implement it into WebPd.
>>
>> More generally, I have the feeling that this something that the
>> BufferSourceNode should be fully capable of doing, as it sounds to me like
>> the right object for this job. However the current spec is not precise
>> enough to enforce this on the BufferSourceNode, thus it is not reliable
>> enough for a serious use as what I am thinking about. So I was wondering if
>> that's something that could improved !?
>>
>> On Tue, Mar 31, 2015 at 7:01 PM, Chris Lilley <chris@w3.org> wrote:
>>
>>> Hello Sébastien,
>>>
>>> Monday, March 30, 2015, 4:10:45 PM, you wrote:
>>> > In the past days I've struggled to get an oscillator that would
>>> > output an exact sawtooth. The use case for me is to modulate an
>>> > AudioParam and the approximative sawtooth provided by the
>>> > OscillatorNode is not precise enough. For example, I wanted to loop
>>> > through a sound file, using WaveShaperNode, and drive the read
>>> > position in that file with a sawtooth, but since the decrease after
>>> > the top of the sawtooth is not instant, you can hear a very loud
>>> > artifact when you reach the end of the file (peak of the saw), a bit
>>> > like fast rewind.
>>>
>>> Not having an infinite slope is a feature, not a bug (this is
>>> bandlimited synthesis, to minimize aliasing artifacts from frequencies
>>> above Nyquist).
>>>
>>> If you want a non-bandlimited sawtooth, you would need to make a
>>> custom oscillator (and subsequent nodes may introduce bandlimiting).
>>>
>>> To just iterate through file positions, this is just a loop, right?
>>> Why drive this from a waveform? If you need both file position and
>>> also a waveform, it would seem better to use a loop, the counter for
>>> which is used directly to produce the file position and also to create
>>> a phase pointer for whatever waveform you are generating.
>>>
>>>
>>> --
>>> Best regards,
>>>  Chris Lilley, Technical Director, W3C Interaction Domain
>>>
>>>
>>
>>
>> --
>>
>> *Sébastien Piquemal*
>>
>>  -----* @sebpiq*
>>  ----- http://github.com/sebpiq
>>  ----- http://funktion.fm
>>
>
>
>
> --
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>



-- 

*Sébastien Piquemal*

 -----* @sebpiq*
 ----- http://github.com/sebpiq
 ----- http://funktion.fm