Define fpp_t and f_cnt_t to be of size_t

[sakertooth]

Defines fpp_t and f_cnt_t to be of size_t. Most of the codebase used fpp_t to represent the size of an array of sample frames, which is incorrect, given that fpp_t was only 16 bits when sizes greater than 32767 are very possible.

There were discussions about using std::size_t, but I left it as size_t so that it can be adopted a bit easier in the code, and not end up in a situation where we mix up std::size_t and size_t.

[Rossmaxx]

A few minor suggestions. The style changes seem to be too much so feel free to just resolve what I pointed out and neglect the rest

Also, you added mingw-std-threads back in. Minor oversight.

[sakertooth]

Also, you added mingw-std-threads back in. Minor oversight.

Not an oversight, I just don't know how to fix it. This branch does not have mingw-std-threads, surely. It is up to date with master already.

[Rossmaxx]

Delete the submodule folder manually and commit

[sakertooth]

Oh nevermind you're totally right, I added it in somehow 🤔.

[Rossmaxx]

That seems to be the reason for ci fail too

[sakertooth]

Also, I'm not going to worry about style for this PR. For these kind of PRs that span across many files, its far too time consuming to format each of the changes.

[Rossmaxx]

Also, I'm not going to worry about style for this PR.

Alright then

[DomClark]

There were discussions about using std::size_t, but I left it as size_t so that it can be adopted a bit easier in the code, and not end up in a situation where we mix up std::size_t and size_t.

They're the same type, just a different name, so there's no concern about mixing them up. I'm also not sure how using plain size_t makes it easier to adopt (besides being five characters shorter, but programming isn't about minimising the character count) - all it does is give us something we need to change yet again in the future, which sounds like more work to me.

A smaller change, simply redefining fpp_t and f_cnt_t would have been fine too, given that we want to replace most of these with std::span in the future.

[sakertooth]

They're the same type, just a different name, so there's no concern about mixing them up. I'm also not sure how using plain size_t makes it easier to adopt (besides being five characters shorter, but programming isn't about minimising the character count) - all it does is give us something we need to change yet again in the future, which sounds like more work to me.

I figured that developers currently are more familiar with specifying size_t rather than std::size_t, and catching the use of size_t instead of std::size_t in each new PR might be a lot of work. In that case, inevitably, the code has a high chance of having both size_t and std::size_t, and I like it more when a codebase is consistent in its choices and how its being read.

A smaller change, simply redefining fpp_t and f_cnt_t would have been fine too, given that we want to replace most of these with std::span in the future.

Yeah, this is easier to do. I will do that instead and define them as std::size_t (size_t). 👍

[sakertooth]

A smaller change, simply redefining fpp_t and f_cnt_t would have been fine too, given that we want to replace most of these with std::span in the future.

I just realized we already have some code now that uses size_t instead of fpp_t or f_cnt_t for frame count, so replacing it throughout the codebase might actually be more ideal for consistency and readability, and then more ideal obviously would be to use std::span later. Since this PR has some specific changes to make the code compile though, replacing it throughout the codebase here would mask those specific changes as it would blow up the diff, which should be reviewed if possible.

[Rossmaxx]

You still didn't remove the submodule 😅

[sakertooth]

You still didn't remove the submodule 😅

I did. It's not here anymore.

[sakertooth]

Also, I'm not going to worry about style for this PR. For these kind of PRs that span across many files, its far too time consuming to format each of the changes.

Nevermind, since I'm not worrying about replacing fpp_t and f_cnt_t with size_t across the codebase, it's fine to consider style. These variables can slowly be phased out over time in other PRs.

[zonkmachine]

@sakertooth I bisected master and these changes causes the issue where LB302 is silent when first launched. Just drag an LB302 into a new project and press the instrument keys. Silent. Add a note in the project and press play. Sound. Now you can press the gui keys and there will be sound from the LB302. Something isn't initialized properly.

Issue noticed by @bratpeki here: #7484 (comment)

[sakertooth]

@sakertooth I bisected master and these changes causes the issue where LB302 is silent when first launched. Just drag an LB302 into a new project and press the instrument keys. Silent. Add a note in the project and press play. Sound. Now you can press the gui keys and there will be sound from the LB302. Something isn't initialized properly.

Issue noticed by @bratpeki here: #7484 (comment)

Thanks @zonkmachine for letting me know. I'll take a look today.