search

monome / crow

Crow speaks and listens and remembers bits of text. A scriptable USB-CV-II machine
GNU General Public License v3.0
166 stars 34 forks source link

ASLs with near zero times don't run #415

Closed trentgill closed 3 years ago

trentgill commented 3 years ago

from @dndrks

grabbed this branch and in testing the ar envelopes, i noticed that output[2]( ar(0.00001,3) ) will not execute, but output[2]( ar(0.0001,3) ) or output[2]( ar(0,3) ) will. i know that 0.00001 is a dumb val to pass in, but it was actually passed into the function as the result of rounding in a Max patch (it wasn't perfectly 0, so it pushed this "close enough" value).

should it be expected that ASL would clamp values to usable ranges, or should output[2]( ar(0.00001,3) ) execute?

edit: actually, this happens on the latest THREE beta as well. so, not branch-specific. sorry for crossing streams -- happy to post elsewhere!

trentgill commented 3 years ago

noting here that 0.00001 is a rise time of less-than-1-sample. there is a special edge case to handle 'instant' slopes (where time == 0), but otherwise there is an assumption that it will be at-least-1 sample before reaching the breakpoint.

could likely solve this by treating any time that is less than 1/48000 = 0.00002083 as 0, and instantly jumping to the next slope.

testing at 0.00003 rise time works but not correctly. it seems as though when a breakpoint is known to occur this sample it instantly jumps to the first step of the next stage without first arriving at the destination. when the rise time is only a handful of samples this will mean the turn-around will not be all the way to the top of the slope --- for a sawtooth wave it means the wave doesn't reach all the way to the top, and the saw is very jagged looking with some teeth reach substantially less high than the rising destination.

realistically this would explain the near-zero 'not producing any output', because the value is at the minimum, and calculated as hitting the peak this sample, so we jump to the release without having ever risen above the end of the past cycle. << solving this issue should solve the ar() issue.

trentgill commented 3 years ago

it also appears that the sample times are off by a factor of 2. it actually seems that the samplerate is only half @24kHz .....