Modify Options - Add WPM and Volume Parameters

[ozdemirburak]

Currently, there are two variables that control the sound - unit and fwUnit. And these confuse most users about the Audio generated.

Instead of these two, taking PARIS (50 units) as the standard word (60 seconds / 50 units = 1.2), a WPM parameter for an end user would be better.

Here is a great resource on this: https://www.morsecodeclassnet.com/ch3-timing/

Other than this, the current default frequency value is 500, but a more common value would be better.

Lastly, a volume parameter can also be added.

Here is the expected output:

 const options: Options = {
    ...opts,
    dash: opts.dash || '-',
    dot: opts.dot || '.',
    space: opts.space || '/',
    separator: opts.separator || ' ',
    invalid: opts.invalid || '#',
    priority: opts.priority || 1,
    >>>>>>>wpm: opts.wpm || 20,
    >>>>>>>volume: opts.volume || 100,
    oscillator: {
      ...opts.oscillator,
      type: opts.oscillator?.type || 'sine', // sine, square, sawtooth, triangle
       >>>>>>>frequency: opts.oscillator?.frequency || SOME_ANOTHER_VALUE, // value in hertz
      onended: opts.oscillator?.onended || null // event that fires when the tone has stopped playing
    }
  };

[chris--jones]

I'm back for Hacktober fest (again), so happy to pick this up and also look at the misleading audio api as referenced in #25 - namely adding support for pause and a more intuitive stop (one that resets the position in the audio rather than disposing)

[ozdemirburak]

That'd be awesome, @chris--jones, thanks.

[chris--jones]

I think I have the wpm working, although the timing seems a little off and I think it's due to the "getGainTimings" implementation.

The current code seems to always insert one unit of silence after a dot or a dash tone even if the next char is a space, so all your gaps of 3 units will actually end up as 4 units.

The example you linked to illustrates the unit distribution rather well:

You can also validate the behaviour using the PARIS example and audio export function. Since we don't encode the final space of 7 units, we should expect the audio length to be 43 seconds long when using a unit length of 1, but instead it is 48 seconds. The difference of 5 is for the extra silence unit after each character.

My question is what should the correct behaviour be?

I think I should update the timings to not add the silence if we're about to add a gap (either between characters or between words), however this will change the current behaviour even when using the previous farnsworth timing configuration.

Removing the extra units of silence do not significantly change the audio output unless you're explicitly timing the output; but I feel like if you're configuring based on wpm you might be doing exactly that.

[ozdemirburak]

I think the correct behavior is the one that is found on that website. And yes, in this case, updating the getGainTimings is a necessity.

The current code seems to always insert one unit of silence after a dot or a dash tone even if the next char is a space, so all your gaps of 3 units will actually end up as 4 units.

Definitely, this is wrong in the current implementation. And if the next character is a space, there shouldn't be an extra silence character.

Another great resource on timing - https://youtu.be/a20EGt4eEQo?t=45 The part about Farnsworth - https://youtu.be/a20EGt4eEQo?t=312