Enable fading of samples in the Sample Track #5616

thmueller64 · 2020-08-08T16:58:40Z

This PR introduces a way to conveniently apply fades to samples like in other DAWs. This is a work in progress and if there is interest in the feature, I will continue to work on this to get it ready to use. I can also think of some possible extensions:

It is planned to add crossfading

More flexible fading function (Bezier Curve)

Current State:

Original State:

LmmsBot · 2020-08-08T17:05:28Z

🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩

Linux

Linux (AppImage): lmms-1.3.0-alpha.1.72%2Bg6b8df1b-linux-x86_64.AppImage (build link)

macOS

macOS : lmms-1.3.0-alpha.1.72%2Bg6b8df1bbc-mac10.14.dmg (build link)

Windows

Windows 32-bit: lmms-1.3.0-alpha-msvc2017-win32.exe (build link)
Windows 64-bit: lmms-1.3.0-alpha-msvc2017-win64.exe (build link)

🤖

{"platform_name_to_artifacts": {"Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://12504-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.72%2Bg6b8df1b-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/12504?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "macOS": [{"artifact": {"title": {"title": "", "platform_name": "macOS"}, "link": {"link": "https://12505-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.72%2Bg6b8df1bbc-mac10.14.dmg"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/12505?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "Windows": [{"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/dwsumo97n1vv1e81/artifacts/build/lmms-1.3.0-alpha-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/37649975"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/nyg8t4j0be3qpf2v/artifacts/build/lmms-1.3.0-alpha-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/37649975"}]}, "commit_sha": "e44d5bb43a3d8bb5259c39ddb165c5310c6f6588"}

RoxasKH · 2020-08-08T17:11:37Z

Seems great.

I feel like there are some graphic glitches on the left, also imo it needs a solid line in addition to the lightup thing imo.

Like in bitwig

Or reaper, ecc.

thmueller64 · 2020-08-08T17:20:54Z

True, there are glitches. You can also see those at the top. I'd have to move the lines a slight bit inside the widget I suppose. The widget should not be considered final, though.

BaraMGB · 2020-08-08T18:06:45Z

Big up!

Spekular · 2020-08-10T14:33:54Z

src/core/Track.cpp

@@ -708,7 +708,6 @@ void TrackContentObjectView::paintTextLabel(QString const & text, QPainter & pai
 		elidedPatternName = text.trimmed();
 	}

-	painter.fillRect(QRect(0, 0, width(), fontMetrics.height() + 2 * textTop), textBackgroundColor());


I disagree with this change. We need this to ensure text stays legible, especially since we allow clips to be colored. I think you should either let the rectangle display on top of the fade curve, or adjust the fade curve's height so that it doesn't share any space with the rectangle.

I changed it now. With the text, it looks a bit strange when not zoomed in. Maybe the fade handles should only be displayed when zoomed in close enough?

I think it looks great now while zoomed in! I'll have to test it out before I can give an opinion on different zoom levels, I'll try to do that tomorrow.

I think it looks fine zoomed out, it's easy enough to see the duration of the fades. That being said, the boxes representing the handles seem to be drawn too low, with a regular height clip you have to press above the box in order to adjust the fade.

ryuukumar · 2020-08-11T09:30:44Z

Love this feature. I would like to request one thing though, and that is to make the color darker instead of lighter where the curve is cutting off the clip. It makes it seem like the cut off volume is highlighted (thus in focus), but it would make more sense to have the active area be the highlighted/in focus one (thus the non-active area would be darker).

RoxasKH · 2020-08-11T11:07:35Z

Love this feature. I would like to request one thing though, and that is to make the color darker instead of lighter where the curve is cutting off the clip. It makes it seem like the cut off volume is highlighted (thus in focus), but it would make more sense to have the active area be the highlighted/in focus one (thus the non-active area would be darker).

I completely agree. Every other DAW, darken the color instead of brightening. For example bitwig, you can see it in the image i posted before

RoxasKH · 2020-08-17T09:50:59Z

Great job. I'd make it a little less dark, and also would be great if in the future there will be the possibility to choose the curve of the fading. If you watch bitwig one you can get what i mean, we only have 1 possibility of fading, while would be cool to have the possibility to choose between a straight line, or a curve in both direction. FL achieves that using a point in the middle of the line. Moving that point up or down will choose the shape of the line.

MaciejMalczyk · 2020-08-17T11:17:37Z

I tested this PR and when sample is not long enough fading marker cannot be grabbed. Instead sample moves through timeline.

https://drive.google.com/file/d/1A5LRGgYVgs7lDgJypMpWpCqGGRh0r0zV/view?usp=sharing

thmueller64 · 2020-08-17T13:59:22Z

Great job. I'd make it a little less dark, and also would be great if in the future there will be the possibility to choose the curve of the fading. If you watch bitwig one you can get what i mean, we only have 1 possibility of fading, while would be cool to have the possibility to choose between a straight line, or a curve in both direction. FL achieves that using a point in the middle of the line. Moving that point up or down will choose the shape of the line.

I'm working on that. Will most likely be something like a bezier curve.

thmueller64 · 2020-08-17T14:02:36Z

I tested this PR and when sample is not long enough fading marker cannot be grabbed. Instead sample moves through timeline.

https://drive.google.com/file/d/1A5LRGgYVgs7lDgJypMpWpCqGGRh0r0zV/view?usp=sharing

I cannot open this, but I know what problem you are referring to. The areas for grabbing are 1/32 of the widget width and will thus vanish when the widget is too small. I will fix that.

superpaik · 2020-10-12T11:09:55Z

I find the feature very interesting! Is it finished? I tested it and works but it's not saving the fading in the project file.

thmueller64 · 2020-11-14T17:54:25Z

Unfortunately, this feature is far from being finished. The fading positions are not saved in a project file yet.

IanCaio

I really like this PRs work so far! I gave it an initial review, still not a complete one. There are code style issues to be fixed, specially about indentation (you probably used space-indenting on your editor). Some other smaller ones like variable naming and spacing. As far as the logic goes I still didn't find any issues, but I didn't dig deep enough yet.

When you merge master/rebase, double check one method mentioned in the review (SampleBuffer::visualize), since Github isn't accusing a conflict but there were changes to this method recently. I've seen it happen before that one PR overwrites changes from another one by accident, so be watchful with that one.

I'll be coming back to this PR to another more thoughtfully review!

include/SampleBuffer.h

IanCaio · 2020-11-25T12:57:01Z

include/SampleBuffer.h

@@ -48,6 +48,86 @@ class QRect;
 // may need to be higher - conversely, to optimize, some may work with lower values
 const f_cnt_t MARGIN[] = { 64, 64, 64, 4, 4 };

+
+class ControlPoint


Should we have a separate header for that and CubicBezier? Maybe one for each is a overkill but we could get them both in a single separate header. I can see it being reused in other places like AutomationPattern for example!

Good point. In the meantime I've noticed that @PhysSong has been working on Bezier curves for automation tracks in #4674. Maybe we can work on the Bezier header together?

I'm not sure if he is actively working on it at the moment, but as long as the Bezier header is done in a way that makes it usable by any other class that need to calculate Bezier curves it should be fine!

include/SampleBuffer.h

src/core/SampleBuffer.cpp

IanCaio · 2020-11-25T19:38:45Z

include/SampleTrack.h

+	bool m_leftCorner = false;
+	bool m_rightCorner = false;


Suggested change

bool m_leftCorner = false;

bool m_rightCorner = false;

bool m_moveLeftCorner = false;

bool m_moveRightCorner = false;

As far as I understood from this first review, those are used on the mouse events for dragging the corners right? Maybe call them m_moveLeftCorner to make it consistent with the other members like m_moveLeftP1 for example, also making their function clearer.

Yes they are used for that. I'll rename those.

thmueller64 · 2020-11-25T21:24:44Z

Thanks a lot for the initial review @IanCaio and @Veratil. I'll look into it tomorrow. This PR is far from being finished however, it is just a draft for the basic concept I've put together. I think it won't be possible to get this PR ready before the refactor deadline as many things are still missing (crossfading, saving the fades in the project, performance issues for very long samples).

Veratil · 2020-11-25T21:32:25Z

... many things are still missing (crossfading, saving the fades in the project, performance issues for very long samples).

Add in saving and then we can add in the other stuff (in later PRs)? 😁

IanCaio · 2020-11-25T22:01:30Z

Thanks a lot for the initial review @IanCaio and @Veratil. I'll look into it tomorrow. This PR is far from being finished however, it is just a draft for the basic concept I've put together. I think it won't be possible to get this PR ready before the refactor deadline as many things are still missing (crossfading, saving the fades in the project, performance issues for very long samples).

Not a thing! We can still try to merge it before the refactor begins: there are other things in motion before we can start it, so there's a little time. Even if it doesn't have all the features you want to include, if it's usable and stable we could review, merge it and continue working on it after the refactor to add the things missing.

As for the performance, I'll have to look better into it. The easiest and simplest solution is probably a look-up table for the values of the curve. There are other alternatives that will probably require some more rewriting, i.e.: actually applying the fading to the samplebuffer data instead of multiplying during playtime. That would require us to have a copy of the original frames that are faded for when we drag the handles again. If the performance load isn't huge we can maybe leave this for after the refactor as well.

src/core/SampleBuffer.cpp

thmueller64 · 2020-11-27T20:11:12Z

As for the performance, I'll have to look better into it. The easiest and simplest solution is probably a look-up table for the values of the curve. There are other alternatives that will probably require some more rewriting, i.e.: actually applying the fading to the samplebuffer data instead of multiplying during playtime. That would require us to have a copy of the original frames that are faded for when we drag the handles again. If the performance load isn't huge we can maybe leave this for after the refactor as well.

The problem is that we have to find the value of the Bezier curve for a specific sample. The Bezier curves are parametrized with a value t that is in [0, 1]. So for every sample x we have to find the t that corresponds to it. Using Newton's method for finding the roots is very fast, because we can essentially warm start the algorithm with a cached value. When benchmarking this I've noticed that no more than a few iterations are needed. The problem is that i don't know how to constrain the solution to lie in [0, 1], so for now I've set (the very inefficient) bisection as the default for root finding.

@PhysSong: As you have already worked on Bezier curves, do you know a better solution?

You notice the performance impact when you apply the fades to a whole song loaded as a sample. It is only impacted when moving the fades though. There is no issue while playing.

Veratil

Mostly style review, one or two comments about other issues.

include/SampleTrack.h

include/Track.h

src/core/SampleBuffer.cpp

src/tracks/SampleTrack.cpp

IanCaio · 2020-11-27T22:47:51Z

The problem is that we have to find the value of the Bezier curve for a specific sample. The Bezier curves are parametrized with a value t that is in [0, 1]. So for every sample x we have to find the t that corresponds to it. Using Newton's method for finding the roots is very fast, because we can essentially warm start the algorithm with a cached value. When benchmarking this I've noticed that no more than a few iterations are needed. The problem is that i don't know how to constrain the solution to lie in [0, 1], so for now I've set (the very inefficient) bisection as the default for root finding.

I still need to read a little bit more on Bezier curves and on how it's implemented in the code. When you mentioned performance issues I thought those were related to the Bezier curve points being calculated during play time (SampleBuffer::play) instead of previously stored in a lookup table. When I get the time I'll finish reading that article you linked about Bezier and get deeper on the logic of the calculations here to see if I can help figuring this one out.

You notice the performance impact when you apply the fades to a whole song loaded as a sample. It is only impacted when moving the fades though. There is no issue while playing.

Well, it's still an issue but much less critical if the performance is only impacted when setting the fades instead of when playing the samples. If we don't figure it out until the refactor we can merge it as is, documenting the need to optimize it, and figure it out after the refactor (since it won't affect the user as negatively as playtime performance issues).

By the way, I think the conflicts I mentioned showed up after the last commit.

Veratil

Other than the unneeded virtual keywords as Dom said in Track.h for leaveEvent and mouseMoveEvent, code style looks good. 👍

src/core/SampleBuffer.cpp

PhysSong · 2020-11-28T12:29:42Z

Regarding the Bezier curve: there are several method to calculate/approximate the value.

Subdividing the Bezier polygon: suggested in Bezier curves for automation tracks #2381 (comment)
Linear interpolation method: converges faster than bisection in most cases, but converges slowly when the derivative is very small at the target point
Solving the cubic polynomial exactly: involving cubic root and might be computationally expensive

Also, I think Newton's method is not good for some cases where the derivative goes to zero.

Veratil

Curious about opinions on these

src/tracks/SampleTrack.cpp

PhysSong · 2021-01-29T08:03:15Z

@thmueller64 Are you still working on this?

thmueller64 · 2021-01-30T11:22:00Z

@PhysSong thanks for the reminder. I have implemented linear interpolation in the meantime which didn't noticeably improve the performance. I found that the real bottleneck lies in redrawing the waveform. When I turn off drawing, moving the fades works seemlessly without any delay. Performant drawing of the audio waveforms like in other DAWs has to be addressed seperately in my opinion.

Veratil · 2021-01-30T17:21:12Z

I found that the real bottleneck lies in redrawing the waveform. When I turn off drawing, moving the fades works seemlessly without any delay. Performant drawing of the audio waveforms like in other DAWs has to be addressed seperately in my opinion.

Agreed. We also need some comments about where things are done, and not being familiar with that side of the codebase, it took me a while to realize that the drawing was done in src/tracks/SampleBuffer.cpp in the visualize function.

I think the best way to speed up drawing would be to cache the base waveform, then calculate modified data if a fade touches it. Right now it looks like there's no caching and it's recalculated each time. This is a lot of overhead waste.

IanCaio · 2021-01-30T19:24:11Z

Agreed. We also need some comments about where things are done, and not being familiar with that side of the codebase, it took me a while to realize that the drawing was done in src/tracks/SampleBuffer.cpp in the visualize function.

Just a heads up, that's one of the things I think we should fix on the refactor. SampleBuffer::visualize go against the decoupling GUI from core paradigm we've been wanting to follow. I think we should figure out a way to remove it from that class and add to another one (not sure if it would be an overkill to have a SampleBufferView class)

thmueller64 · 2021-01-31T09:56:31Z

I think it has to work even without caching. For example, when you turn the amplification knob in the audio file processor on a sample of like 2min+, you have to update every value with a simple multiplication. On my hardware, the waveform plot also struggles to catch up in time and is very unresponsive.

Veratil · 2021-01-31T21:48:56Z

I think it has to work even without caching. For example, when you turn the amplification knob in the audio file processor on a sample of like 2min+, you have to update every value with a simple multiplication.

You're right, we definitely need to figure out a better way to speed up the waveform visualization. My cache idea I think is better overall for UI responsiveness when not changing any dependent variables, rather than real-time updating. With many sample buffers and constantly calling the visualize function to calculate the same thing over and over again just makes things slow.

On my hardware, the waveform plot also struggles to catch up in time and is very unresponsive.

With my cache idea this will still slow down for you unfortunately. We can still look to find some calculation savings though for this loop. Figuring out what is constant during the loop and what can change could speed up some parts.

Declare functions virtual for SampleTCO, remove rectangle clashing with fades Add fading for sampletracks. Add von Hann window as fading function and make it the default. Fix formatting issues. Fix build issue on macOS. Dark shading, border adjustments, reinclusion of text. Fix build issue on Windows. Better clicking behavior. Prevent moving of handles into border. Add cubic Bezier as fade function. Menu for choosing fade style. Apply suggestions from code review Co-authored-by: IanCaio <[email protected]> Change naming of variables Apply retab to replace spaces Apply suggestions from code review Co-authored-by: Kevin Zander <[email protected]> Apply retab to replace spaces Update src/tracks/SampleTrack.cpp Co-authored-by: Kevin Zander <[email protected]> Removed unnecessary virtual keyword Update include/Track.h Co-authored-by: Hyunjin Song <[email protected]> Update src/core/SampleBuffer.cpp Co-authored-by: Hyunjin Song <[email protected]> Enable saving the fade positions and the fading shape Double check that fades and control points lie in [0, 1] Update src/core/SampleBuffer.cpp Co-authored-by: Hyunjin Song <[email protected]> Fix format and further conflicts.

include/SampleBuffer.h

include/TrackContentObject.h

Veratil · 2021-02-05T22:39:02Z

src/core/SampleBuffer.cpp

 		auto x = xb + ((frame - first) * double(w) / nbFrames);
 		// Partial Y calculation
-		auto py = ySpace * m_amplification;
+		auto py = ySpace * m_amplification * fade;


I've been thinking about how to speed up some of the recent loop calculations in some of the PRs I've seen. The compiler should already see that some of these values are the same each loop and optimize it, but just in case we can help out even more.

This line for instance, if we pull ySpace * m_amplification out of the loop, then we can save a multiplication every loop (in case of bad optimization).

Additionally for the x line above, can we pull out double(w) / nbFrames to save heavy division? I know this will process left to right, so it could change the result if we did the division first.

I created a separate issue for the whole drawing concept #5908 . I hope it is OK if I resolve this for now and defer the discussion to the issue.

src/tracks/SampleTrack.cpp

Veratil · 2021-02-05T23:04:52Z

src/tracks/SampleTrack.cpp

 }


+void SampleTCOView::enterEvent(QEvent *e)
+{
+	if (e != nullptr) { m_inside = true; }


Can e be a nullptr? I guess if called manually, but I don't think it will ever be nullptr when Qt generates it.

Probably not. I think it is good to check anyway, to be on the safe side.

Well the reason I bring it up is because the event is called only if raised, so e will never be nullptr. The only time it will be is if we were to call it manually without.

src/tracks/SampleTrack.cpp

Co-authored-by: Kevin Zander <[email protected]>

Co-authored-by: Kevin Zander <[email protected]> Co-authored-by: IanCaio <[email protected]>

thmueller64 · 2021-02-07T10:14:51Z

@Veratil I did some crude profiling of the visualize function to see where we need to optimize. It turned out that most of the time is spent in drawing the waveform with drawPolyline.
Those are the results I got with some simple std::chrono time measurements:

Before for loop: 0,017852
In for loop: 0,078132
After for loop: 0,904016

So we have to figure out a better concept there. Reducing the number of points drawn for example. One standard approach would be to take the maximum of the samples per pixel. This is done in Audacity for example: https://manual.audacityteam.org/man/audacity_waveform.html

Veratil · 2021-02-07T16:49:36Z

Good find! We can do that in another PR. 👍

LostRobotMusic · 2024-04-06T16:19:53Z

I drastically improved sample drawing speeds in #5927 by around 5x-10x, so the changes in this PR should be viable now.

However, the fade shapes provided are incorrect for the purpose of crossfading between uncorrelated audio signals. Using them will result in a 3 dB dip in volume partway through the fade. Nearly every DAW gets this wrong and LMMS shouldn't be one of them. I explain this in a video here: https://youtu.be/-5cB3rec2T0

Taking the square root of any constant-gain crossfade will result in one that is constant-power. I recommend doing this with the raised cosine fade so there's no slope discontinuity at the highest point in the fade. I also heavily recommend making this the default shape, as is currently the case in REAPER and should be the case in every DAW.

You can verify it was done correctly by fading between two white noise sources and verifying that there isn't a 3 dB dip in RMS in the middle of the fade. You can also verify this by ensuring the power (square) of each fade function adds up to a flat line, as shown:

Spekular reviewed Aug 10, 2020

View reviewed changes

IanCaio requested changes Nov 25, 2020

View reviewed changes

Veratil reviewed Nov 27, 2020

View reviewed changes

src/core/SampleBuffer.cpp Outdated Show resolved Hide resolved

Veratil requested changes Nov 27, 2020

View reviewed changes

Veratil reviewed Nov 28, 2020

View reviewed changes

PhysSong reviewed Nov 28, 2020

View reviewed changes

src/core/SampleBuffer.cpp Outdated Show resolved Hide resolved

Veratil reviewed Nov 28, 2020

View reviewed changes

src/tracks/SampleTrack.cpp Outdated Show resolved Hide resolved

src/tracks/SampleTrack.cpp Outdated Show resolved Hide resolved

Veratil reviewed Nov 28, 2020

View reviewed changes

src/tracks/SampleTrack.cpp Outdated Show resolved Hide resolved

thmueller64 force-pushed the feature-sample-fades branch from b46aa02 to 4434840 Compare February 5, 2021 19:38

thmueller64 added 2 commits February 5, 2021 21:22

Apply codefactor suggestions.

9ec1725

Undo some unintentional changes from rebase

525f2d7

thmueller64 marked this pull request as ready for review February 5, 2021 21:53

Veratil reviewed Feb 5, 2021

View reviewed changes

thmueller64 and others added 2 commits February 7, 2021 10:47

Apply suggestions from code review

84a3fea

Co-authored-by: Kevin Zander <[email protected]>

Apply suggestions from code review

e44d5bb

Co-authored-by: Kevin Zander <[email protected]> Co-authored-by: IanCaio <[email protected]>

RoxasKH mentioned this pull request Feb 20, 2023

Few feature requests for LMMS #6653

Closed

allejok96 mentioned this pull request May 3, 2023

Better Sample Track support #1471

Open

29 tasks

RoxasKH mentioned this pull request Sep 17, 2023

Fix the clicks heard during instrument note-off . #3086

Closed

Spekular mentioned this pull request Oct 23, 2023

Guitar plugin and stretching samples suggestion #6948

Closed

Enable fading of samples in the Sample Track #5616

Are you sure you want to change the base?

Enable fading of samples in the Sample Track #5616

Conversation

thmueller64 commented Aug 8, 2020 • edited Loading

LmmsBot commented Aug 8, 2020 • edited Loading

Linux

macOS

Windows

RoxasKH commented Aug 8, 2020

thmueller64 commented Aug 8, 2020

BaraMGB commented Aug 8, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryuukumar commented Aug 11, 2020

RoxasKH commented Aug 11, 2020

RoxasKH commented Aug 17, 2020

MaciejMalczyk commented Aug 17, 2020

thmueller64 commented Aug 17, 2020

thmueller64 commented Aug 17, 2020

superpaik commented Oct 12, 2020

thmueller64 commented Nov 14, 2020

IanCaio left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thmueller64 commented Nov 25, 2020

Veratil commented Nov 25, 2020 • edited Loading

IanCaio commented Nov 25, 2020

thmueller64 commented Nov 27, 2020

Veratil left a comment

Choose a reason for hiding this comment

IanCaio commented Nov 27, 2020 • edited Loading

Veratil left a comment

Choose a reason for hiding this comment

PhysSong commented Nov 28, 2020

Veratil left a comment

Choose a reason for hiding this comment

PhysSong commented Jan 29, 2021

thmueller64 commented Jan 30, 2021

Veratil commented Jan 30, 2021

IanCaio commented Jan 30, 2021

thmueller64 commented Jan 31, 2021

Veratil commented Jan 31, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thmueller64 commented Feb 7, 2021

Veratil commented Feb 7, 2021

LostRobotMusic commented Apr 6, 2024 • edited Loading

thmueller64 commented Aug 8, 2020 •

edited

Loading

LmmsBot commented Aug 8, 2020 •

edited

Loading

Veratil commented Nov 25, 2020 •

edited

Loading

IanCaio commented Nov 27, 2020 •

edited

Loading

LostRobotMusic commented Apr 6, 2024 •

edited

Loading