Sotonye Atemie

> I think it would be better to do the sample workflow/performance improvements first and then sample buffer can be done as a different pr at a later time. This...

> Oh i see. Btw does this pr fix the abnormal memory / cpu usage on sample track. Indeed. I put a milestone video that shows me putting 18 sample...

> i tried out this build and found some issues. > > 1. the sample track colour seems broken > 2. the theming is broken while using custom themes >...

> Why are you setting the minimum length of a clip to one bar again? This was intentionally changed in #4933 to allow e.g. the use of sample tracks for...

The ambiguity between sample sharing and sample caching is somewhat problematic. While the samples are infact shared (no duplicates of the same ``SampleBufferV2`` derived from a file or Base64 are...

> Note for the failure with MinGW: https://stackoverflow.com/a/33159746 I think it's because the experimental ``filesystem`` implementation doesn't support the generic format observer functions for MinGW (GCC 7.3.0). The linux builds...

> Also, I'm thinking it would be better to use move semantics for returning the `std::string`, but I'm not too versed in that aspect and how to make it work...

> What would be the reason to elliminate Qt methods? FWIR, this is only useful for the GUI, which uses Qt anyways? FWIW, my sample caching PR utilizes Base64 encoding/decoding...

I made some tweaks to this implementation [here](https://github.com/Veratil/lmms/pull/8). Took me a while because I was constantly refactoring it and trying to get something compact. Both functions should be functional and...

> Also changed the current Qt-based encode/decode namespace to `lmms::gui::base64`, and kept the new in `lmms::base64`. This way we can adjust things to the new functions as needed. Why not...