Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Use the same Sample object for tables of different lenght #293

Closed
leobel96 opened this issue Dec 5, 2024 · 8 comments
Closed

Use the same Sample object for tables of different lenght #293

leobel96 opened this issue Dec 5, 2024 · 8 comments

Comments

@leobel96
Copy link

leobel96 commented Dec 5, 2024

In the examples/08.Samples/Samples_Tables_Arrays/Samples_Tables_Arrays.ino example, 11 tables of the same length are being used. This is a very specific scenario and, when dealing with drums for example, it's almost impossible to have kicks, hats, ... all of the same length. Is there a way of having that NUM_TABLE_CELLS changeable on-the-fly so that the same Sample object can be reused with samples of different length? I guess that it has been made like this so that many operations can be done directly in compilation but, MCU like the RP2040 can easily handle performing those calculations on the fly IMO.

@tomcombriat
Copy link
Collaborator

Hi,

What would be wrong with having several instances of Samples, one for each samples? This class is very small (well, except for the sample is contains) so the overhead in memory compared to swapping the inside data should be minimal (whereas the overhead of having the NUM_TABLE_CELLS changeable would probably have an impact on performances)

@leobel96
Copy link
Author

leobel96 commented Dec 5, 2024

Let's imagine this situation:

  • 1 Sample object playing a Kick from a table of 10 kicks
  • 1 Sample object playing a Snare from a table of 10 Snares
  • 1 Sample object playing a HiHat from a table of 10 HiHats

With the current implementation, given that the tables have all different lengths, it requires me to instantiate 30 Sample objects when, in practice, only 3 can play at a time. On top of that, I cannot have an array with all the Sample objects because, technically, they are different types (if I don't use weird nullptr tricks or a variant with 30 types).

@tomcombriat
Copy link
Collaborator

Indeed, but having 30 Sample objects instead of three will only occur a very small overhead in memory whereas allowing changing the table length at runtime will incur a performance overhead if setFreq is called often (which might not be your case though). It also drops backward compatibility, something we try to avoid as much as possible.

Indeed, you can't have one array of known type with this… But maybe a way to go (if you don't want to have all your samples of the same size) would be to create a struct or a class containing all your Kicks for instance and playing only the one kick you need?

@leobel96
Copy link
Author

leobel96 commented Dec 5, 2024

Indeed, in my case, I wouldn't change frequency often. I think that I'll go for having all the tables with the same length extending the shorter ones with some silence or I'll just create a custom variant of the Sample class on my side. Thank you :)

@tomcombriat
Copy link
Collaborator

Sorry for not a more tailored solution :/. Performances is a must in Mozzi (especially as we are trying to keep everything running on low-end platforms like AVR) and a break in compatibility is not to be taken lightly… That being said, that triggered some internal reflection on my side, thanks :)!

I'm sure you will figure an easy workaround between the different solutions (custom Sample, same size, and swapping between Sample)!

Can I close this?

@leobel96
Copy link
Author

leobel96 commented Dec 5, 2024

Yeah, feel free to close it :)

@leobel96
Copy link
Author

leobel96 commented Dec 5, 2024

Sorry for hijacking this Issue but I have a few more questions/suggestions and I don't think it makes sense to open a new Issue for them:

  1. Are you planning to template the Sample class a bit more to have it accept higher quality int16_t (or, even, int32_t) Tables?
  2. extras/python/float2mozzi.py has some issues and I have a working version locally. Do you mean if I open a pull request?
  3. I found a nice way of converting a large number of wav in batch using the tool sox (easily installable on macOS using brew install sox but other OSes are supported). It could be a good addition to your guide in alternative to Audacity. You can convert an audio file to a 32 bit float simply doing: sox file.wav -b 32 -c 1 -e floating-point -r 16384 file.raw but many more options are available

@tomcombriat
Copy link
Collaborator

No problem at all! Some of this have to be discussed with the others (and hence might deserve an issue) but here is a start:

Are you planning to template the Sample class a bit more to have it accept higher quality int16_t (or, even, int32_t) Tables?

This (and the same for Oscil has been around for quite some time… And I think it makes even more sense for Sample. We will have to commit to it at some point, but so much hour in a day. PR welcome on that! (#133 might be of interest).

extras/python/float2mozzi.py has some issues and I have a working version locally. Do you mean if I open a pull request?

Please do! Some of these have been around for some time and any update is welcome!

I found a nice way of converting a large number of wav in batch using the tool sox (easily installable on macOS using brew install sox but other OSes are supported). It could be a good addition to your guide in alternative to Audacity. You can convert an audio file to a 32 bit float simply doing: sox file.wav -b 32 -c 1 -e floating-point -r 16384 file.raw but many more options are available

Please do also add it as a PR for another script if you think that can be useful for others. Same actually goes for good wavetables if you want to share them :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants