Time is not constant through viewport width

raphaelbastide commented

2021-12-10 14:11:03 +00:00

(Migrated from gitlab.com)

It appears that an element placed at left:100vw is not similar to left:0vw at least from a sound perspective.
The result of that is that every beginning of beat (everything that is on the left of the viewport) is slightly rushing.

> Demo

In the demo the out-of-viewport bug has to be ignored, see #66 .

It appears that an element placed at left:100vw is not similar to left:0vw at least from a sound perspective. The result of that is that every beginning of beat (everything that is on the left of the viewport) is slightly rushing. [> Demo](https://raphaelbastide.com/cascade/tests/vw.html) In the demo the out-of-viewport bug has to be ignored, see #66 .

raphaelbastide commented

2021-12-10 14:12:39 +00:00

(Migrated from gitlab.com)

changed the description

raphaelbastide commented

2021-12-10 14:13:41 +00:00

(Migrated from gitlab.com)

changed the description

raphaelbastide commented

2021-12-10 14:26:10 +00:00

(Migrated from gitlab.com)

changed title from Time {-sounds inhomogeneous-} through viewport width to Time {+is not constant+} through viewport width

changed title from **Time {-sounds inhomogeneous-} through viewport width** to **Time {+is not constant+} through viewport width**

raphaelbastide commented

2021-12-18 14:20:52 +00:00

(Migrated from gitlab.com)

This demo has also a weird timing that can be related to this issue: the blue element at the very right lags each time it is triggered for the first time. Also, when the patch is played, each first cycle sounds a bit clumsy.

[This demo](https://raphaelbastide.com/cascade/cember/17.html) has also a weird timing that can be related to this issue: the blue element at the very right lags each time it is triggered for the first time. Also, when the patch is played, each first cycle sounds a bit clumsy.

raphaelbastide commented

2021-12-22 22:20:25 +00:00

(Migrated from gitlab.com)

After some investigation:

the function createInstruments() takes about 400ms to be completed, that’s a bit long but that can’t be related to this issue because it is happening at init() once.
Every time interpret() is called, it loops all the element at once, this can explain why the lag happens at every beginning of tick.
TODO: create a sound tick and compare it to a visible 1:1 sound pulse

After some investigation: - the function `createInstruments()` takes about 400ms to be completed, that’s a bit long but that can’t be related to this issue because it is happening at `init()` once. - Every time `interpret()` is called, it loops all the element at once, this can explain why the lag happens at every beginning of tick. - TODO: create a sound tick and compare it to a visible 1:1 sound pulse

raphaelbastide commented

2021-12-22 22:24:39 +00:00

(Migrated from gitlab.com)

marked this issue as related to #39

raphaelbastide commented

2022-01-10 17:13:18 +00:00

(Migrated from gitlab.com)

mentioned in commit e5a2dd209e

mentioned in commit e5a2dd209edd8391b88741d71ee8926d52488b3b

Rows
Columns

Time is not constant through viewport width #65