Start time must be strictly greater than previous start time #50

New issue

Open

opened 2021-11-19 16:36:56 +00:00 by raphaelbastide · 6 comments

raphaelbastide commented

2021-11-19 16:36:56 +00:00

(Migrated from gitlab.com)

When several elements are present on the page, the following Tone error sometimes shows:

Uncaught Error: Start time must be strictly greater than previous start time
    at r (Tone.js:1)
    at xe.start (Tone.js:21)
    at nn._triggerEnvelopeAttack (Tone.js:21)
    at nn.triggerAttack (Tone.js:21)
    at nn.triggerAttackRelease (Tone.js:21)
    at cascade.js:240

An answer online says:

I received this error due to multiple sounds/notes being queued with triggerAttackRelease() at the exact same time. For me, I found that using multiple Synth instances (one per each distinct sound/note) was the best approach. Be careful not to spawn too many Synth instances, however.

This could be a way to solve it.

When several elements are present on the page, the following Tone error sometimes shows: ``` Uncaught Error: Start time must be strictly greater than previous start time at r (Tone.js:1) at xe.start (Tone.js:21) at nn._triggerEnvelopeAttack (Tone.js:21) at nn.triggerAttack (Tone.js:21) at nn.triggerAttackRelease (Tone.js:21) at cascade.js:240 ``` An answer online says: > I received this error due to multiple sounds/notes being queued with triggerAttackRelease() at the exact same time. For me, I found that using multiple Synth instances (one per each distinct sound/note) was the best approach. Be careful not to spawn too many Synth instances, however. This could be a way to solve it.

alicericci commented

2021-12-16 13:35:59 +00:00

(Migrated from gitlab.com)

mentioned in commit b3834e06fc

mentioned in commit b3834e06fc84a2112fe26ae3020d44c349f2f0f8

alicericci commented

2021-12-20 11:09:25 +00:00

(Migrated from gitlab.com)

mentioned in commit 23d6dc1a1d

mentioned in commit 23d6dc1a1db3977c8d2f1133efc4d4a80b3b22ce

alicericci commented

2021-12-20 11:11:31 +00:00

(Migrated from gitlab.com)

In order to fix this issue, I implemented a new instrument parameter called instrumentDuplicate. This variable value should be in between 0 and 1. It creates duplicate synth according to the number of cascade element playing the same instrument.
So if 10 cascade element use the same instrument and in the instrument parameter instrumentDuplicate is set to 0.5, then 5 tonejs synths will be created and the cascade elements will share them.
If this value is changed while cascade is running, then the corresponding element should be updated for the change to take effect. This can be done with element.update() or by changing the appearance of the element.

Also, the error is caught and a custom error is logged into the console

In order to fix this issue, I implemented a new instrument parameter called instrumentDuplicate. This variable value should be in between 0 and 1. It creates duplicate synth according to the number of cascade element playing the same instrument. So if 10 cascade element use the same instrument and in the instrument parameter instrumentDuplicate is set to 0.5, then 5 tonejs synths will be created and the cascade elements will share them. If this value is changed while cascade is running, then the corresponding element should be updated for the change to take effect. This can be done with element.update() or by changing the appearance of the element. Also, the error is caught and a custom error is logged into the console

raphaelbastide commented

2021-12-20 13:31:26 +00:00

(Migrated from gitlab.com)

That’s great. I just tested it a bit and I have a question : if I have 10 possibly overlapping notes with the same instrument that has a instrumentDublicate:0:1, which one will have its own synth? What is the order of priority?

That’s great. I just tested it a bit and I have a question : if I have 10 possibly overlapping notes with the same instrument that has a `instrumentDublicate:0:1`, which one will have its own synth? What is the order of priority?

alicericci commented

2021-12-20 14:14:28 +00:00

(Migrated from gitlab.com)

The last element to arrive will trigger the creation of a new synth and will be assigned to it.

Also, when an element is deleted or changes instrument, the synth is not deleted and not reassigned to another element. It might be an interesting thing to implement in the future, if we notice performance issues.

To find which synth is assigned to an element:
insList[element.computedProperties.insName].indexOf(element.computedProperties.currentInstrument)

The last element to arrive will trigger the creation of a new synth and will be assigned to it. Also, when an element is deleted or changes instrument, the synth is not deleted and not reassigned to another element. It might be an interesting thing to implement in the future, if we notice performance issues. To find which synth is assigned to an element: `insList[element.computedProperties.insName].indexOf(element.computedProperties.currentInstrument)`

raphaelbastide commented

2021-12-20 15:17:12 +00:00

(Migrated from gitlab.com)

Great, thanks for those details!