|
|
|
05-14-2021, 05:53 AM
|
#1
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
resolved: if multipl env points exist at AI endpoint, envelope ignores last points
this bug presents itself when you're making simple LFO patterns using AI and duplicating them across the project.
here, i have 2 AIs that contain the same points. the first track's AI, however, is extended a bit longer than the 2nd AI.
since all of the envelope points in the AI are inside the AI bounds, (visibly so), the user would expect both of these AI to behave in the same way.
however, they do not - in the 2nd AI, the last point gets truncated and is never sent to the pan envelope. watch the resulting audio below: the reasynth audio remains panned hard to one channel, despite the AI ending with a visible and editable envelope point.
Last edited by mccrabney; 02-16-2023 at 04:37 AM.
|
|
|
05-14-2021, 06:03 AM
|
#2
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
note that gluing behaves as expected here: that sneaky point that's ignored by playback gets "heard" by the glue:
(edit, disregard that ^ - gluing AI actually just assumes the bypassed background envelope, which is its own issue)
the workflow issue here is that users must either A, force their AI to be longer than they need to be, or B, zoom in on their AI in order to prevent 2 points from existing on the same AI endpoint. note, if we adjust the LFO so that the lowest envelope point exists even a tick before the final "return to 0" envelope point, the AI behaves as expected:
this is a workaround, but it's pretty inconvenient and twitchy.
Last edited by mccrabney; 02-15-2023 at 07:55 AM.
|
|
|
05-14-2021, 06:05 AM
|
#3
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
note too that 2 points seem to be able to exist at the AI start, no problem - despite the point NOT being visible here.
|
|
|
05-14-2021, 06:54 AM
|
#4
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
this bug report came about as i grab snatches of AI by using Razor Edits.
watch the pan display readout on the left. here, i duplicate a razor edit selection of a pan envelope. note that in the top track, at the edit cursor, the track pan reads 99%L. that's great, that's expected - it's where the envelope point is, visibly.
now, look at the bottom track - 99%R, despite all points having been moved/copied.
i understand that this is a tricky issue, because no matter what you're going to have either AI start/endpoints existing at the same moment, and you're going to have multiple envelope points existing at the same moment. i also know that fixing this bug will potentially change old projects for people, which is dangerous - but arguably less dangerous than having envelopes indicate one result but produce another.
Last edited by mccrabney; 05-14-2021 at 08:01 AM.
|
|
|
05-19-2021, 01:00 PM
|
#5
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
here's another view of this - in this case, i've enabled the background envelope and attached it to the edges of my AI.
here, i create an AI with a start and endpoint at the AI bounds.
i then create a ramp, placing an envelope point at the end of the AI.
this new point seems to be interpreted as the "last" AI point, and snaps the background envelope down.
however, if you extend the AI, the new 0% end point slips behind the previous 100% end point, and the background envelope snaps back up to 100%.
at the end of the gif, i return the AI to its original size and then move this lost envelope point around, to no effect. if this is indeed the "last" envelope point, as extending the AI would suggest, then the expected behavior would be that this endpoint would control the attached background envelope/chase value.
am i underthinking it, or could a fix to this be that simple? let the last envelope point in the AI be what has the final word?
|
|
|
06-15-2021, 03:57 AM
|
#6
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
bump.
we cannot trust the AI to use the last envelope point value to inform the parameter, and this is a problem. we're not yet truncating the envelope point -- it's visible -- but its value gets ignored in favor of the 2nd to last envelope point in AI bounds.
Last edited by mccrabney; 06-15-2021 at 04:38 AM.
|
|
|
08-11-2021, 04:20 AM
|
#7
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
bump. what you see is what you don't get. this is wrong - i have to edit AI to be longer-than-grid/necessary/intended just to contain this visible, in-bounds point, which causes problems when moving it later
|
|
|
02-15-2023, 07:46 AM
|
#8
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
bump, as far as i can tell this one is the last of the AI issues! incredible progress on all of these, thanks so much
maybe an easy way to handle this is an option that prevents two envelope points from occupying the same time location? similar to "Options: Prevent mouse edits of single envelope points from moving past other envelope points"
|
|
|
03-01-2023, 01:25 PM
|
#9
|
Human being with feelings
Join Date: Jan 2007
Posts: 496
|
It would be incredibly helpful if in "only automation item" mode Reaper would draw a faint line outside the actual AI items, showing the chased value.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 09:00 AM.
|