Sample Rate dependancies

#1

Axoloti is fixed to 48k sample rate.
Im wondering, what code is dependent upon this, and how hard-coded it is.

my thoughts are:
oscillators - presumably the driving phasor depends upon sample rate. or at least its 'tuning reference'
i.e. the dials/MTOF, all set the phasor to a frequency which gives the expected output.

filters - highest frequency, would need to be nyquist which changes (SR/2)
is there anything else that needs to be adjusted due to nyquist?

control rate dependancies - anything which assumes control rate is 3000, since its SR/16
(lfo rates, and things like any tempo calculation based on KR)

other dependancies?

Im thinking, excluding the UI elements... then oscillators tuning, is mainly the midi mapping. filters, I guess you could just turn down the cutoff? control rate dependancies I don't think these are too problematic.

I guess my main concern would be things, where they are calculated, assuming a nyquist of 24k, and so will alias, before they reach 'patch control' to be adjusted.

the reason this becomes interesting is when using generated code for other things e.g. a VST would need to run at the host rate, which many run at 44.1kHz (which is really inconvenient for downsampling cheaply)

Changing Axoloti's Sample Rate?
Clds and Lmnts objects
#2

Don't most (all?) modern DAWs and vst systems allow for setting the sample rate of a song? That means at least on one side of the rig can match sample rates.

Also, won't sample rate only be important if you're using digital in to your Daw host?

#3

Sorry I am not a developer, but I have a few thoughts I'd like to share anyway. If you find it irrelevant, you can delete it, but I am going to take the chance :wink:

A few thoughts on higher control rates:

For example Micro Q synth has got different modulations rates. Micro Q consists of 2 different mod matrixes, one is normal speed, which i think is krate control rate 3000(or 2600hz if I remember correct). It has got another modmatrix called "fast mod", which updates at much higher rate, same as FM input for oscillators on synths. Difference between FM in regular synths and Micro Q's fast mod is that on Micro Q you can modulate all parameters using FM's fast modulation capabilities, not only the pitch of and oscillator as on regular synth.

This makes Micro Q very capable of making really great drum sounds. To me, the best synth for drums percussion etc.. And this is only when using fastmod(FM) matrix. Using normal speed mod matrix doesnt do that job.

So in term of usablility of higer control rate objects, it is there.

I just tried finding the webpage I have this info from, but cannot find it atm. Long time since I looked at it. But I think it was from Waldorf mailing list, many years ago. Actually I think Blofeld has got only the fast mod control rate. It is also capable of making really good drums.

If you got acces to a Micro Q, then try and make a sound and set the same amount of modulation for the same parameter in Fastmod and Normalmod matrixes and hear the difference.

This is just my personal thoughts on the sample rate:

Sample rate is to me what defines the depth or detail of the sound. To me personally when making track, I think that using 96khz sample rate sounds much more deep/detailed than 44.1. Not said that 44.1 is not good, but 96 khz is just "deeper". When I think of sample rate I always get this picture in my head:

Imagine if you are a painter and you have 44.100 strokes with a brush to finish the painting. Then imagine if you have 96.000 stroks with a brush to finish a paint. Which picture can be most detailed? The one with 96.000 strokes of course.

(This could be taken to a philosophical level, with discussion about is a picture actually better because it is more detailed? Is it a good/bad painter, etc.......... But that is another level and doesnt really have anything to do with what I am trying to say.) So.....:

I am just trying to describe how I look at sample rate. And with 96.000 strokes you can paint a more detailed picture than you can with 44.100 strokes. And that is the same with sample rate. 96.000 samples makes a more detailed sound than 44.100 samples does.

So sample rate can be important in many ways. If you have a oscillator which is 44.1 khz and one 96khz, the one 96khz will probably sound more detailed(Fat or whatever people call it :wink:)

#4

I understand what sample rate does and why it's important, I was noting that it needn't be an issue if the daw/vst system is capable of changing it's sample rate. Either way, support for different sample rates I am sure would be welcome. :smile:

#5

Yeah the VST/Host is an example... not the only use case.
(though some daws allow per project, some don't ... e.g. ableton is not per project, and id say its fairly modern :wink:)

so the post was not really about if different sample rates are useful or not (I think evidentially its 'nice to have', and useful in some scenarios).

more what things are affected by it? where is the code that would have to change?

please bare in mind, axoloti is, correctly (imho) focused as a high performance system on a cost effective platform, so in no way is multiple sample rates a requirement (or necessary) for this, I'm just thinking out loud as where these 'assumptions' are... and where the impact are.

#6

indeed, my original post wasn't whether it was good or bad, just whether it would affect a daw situation if the axoloti doesn't have digital out? With the impact being that the user would possibly have to resample.

#7

I think it depends on 'your' daw, and also IF the user is willing to switch sample rates for one VST.
Id say generally the answer to that is some users will be reluctant, as they are restricted by hardware (either their audio interface or their pc/mac) , I can't think of a VST that restricts you to a certain sample rate, thats not a challenge to name one, Im sure there will be one out there somewhere :wink:

... but as I said, just one use case, its more about implications...

#8

Is it not a trade off for efficiency ?
Do we not need to give consideration for the highest frequency used ?
If we say we intend to use a frequency of 10khz, at a sample rate of 48khz, this is 4.8 samples per cycle.
Sure we are not likely to use 10khz but it shows the lack of sampling you have to work with.
But then half this at 5khz is 9.6 samples per cycle, is it enough ??
What is the best bang for your buck.

#9

As far as i've seen MTOF and MTOFEXTENDED are used in all those cases where a link is needed between "real world frequencies" and "microcontroller world frequencies": oscillators, filters, lfos and envelopes.

There's probably some user generated code which does not take advantage of these functions, maybe that has to be reworked for different sample rates.

@grimmreefer
I think you're getting something wrong: the fatness of a sound is defined by low-mid harmonics. High harmonics define the clarity or crispiness of it, however if you pass some signal through a spectrum analyzer you'll see that high-end harmonics have a really smaller amplitude, compared to low-end. The 18th harmonic of a sawtooth wave for example has a 30 db attenuation with respect to the first (this means it's 1000 times smaller)
If you put such sound into a mix, the beneficial crispiness of a higher sample rate simply vanishes.

However, in the digital world, any frequency bigger than fc/2 will produce spurious harmonics (the effect you generally want to create with a sample/hold effect), therefore all frequencies above that limit have to be filtered.
Since filters have a finite slope, meaning that if you set a lowpass to 300 hz some frequencies above 300hz will eventually leak, you'll have to set the cutoff below fc/2 in order to limit the generation of such spurious harmonics.
Having a bigger sample rate does not give you simply more headroom to work with, it allows you to mangle the sound more easily without generating unwanted tones or noises.

You can definitely program a bass synth with a digital 44100Hz synthesizer

#10

I did write "or whatever people like to call it". I said I dont use those words, many others do. BUT sample rate at 96khz does give more headroom and a more detailed sound than 44.1 for example. And that is my point. A 96khz oscillator(For example is Nord G2 internally running 96khz) will therefor also give a more detailed sound.

Please read my post again if in doubt. I actually pointed out this very precisely that I dont say 44.1 is bad. I said that 96khz produces a more detailed sound.

#11

"Just over" 2 samples per period is sufficient to fully represent a sine wave. Here's a good demo and explanation: http://www.xiph.org/video/vid2.shtml
For audio in- and output, in my opinion, 44.1 or 48kHz is adequate. But for audio processing or generation, this depends on the context, using up- and downsampling, this can be independent from the input/output samplerate. Simulating an analog system in the digital domain, even when in- and output are only audio bandwidth, may involve relevant higher frequency intermediates. For example, a longwave radio transmitter/receiver involves megahertz frequencies.

That said, can we please stick to the original development topic here: resolving code dependencies on the currently fixed 48k samplerate? You're invited to open topics about the impact of samplerate in other categories on this forum.

I think there are two modifications to be made, MTOF and MTOFEXTENDED, and then unit representations in the UI. The first is relatively easy to solve, I think it is best to have a 44.1kHz tuning table as well as a 48kHz tuning table. For power-of-two multiples of 44.1kHz and 96kHz the same tuning table can be re-used.
There are other places where there will be an impact, for instance delay length, or any implicit filter coefficients, the impact of switching from 48kHz to 44.1kHz will cause a bit duller sound, and in case anything is not well bandlimited, could cause quite a different sound too. Bandlimiting is not just inside the objects or not, it's also how they're applied in a patch.

#12

...from my experience (with my +40 ears...) its always the BITS that make things DOPE,
rather than the KHZ...
sure 96khz will sound better than 44.1 khz,
but a 24-bit dynamic range does sound A LOT better than a 16-bit range...
it*s all about them TRANSIENTS...and that NOISE

#13

Thanks @johannes, interesting video, will check out there others too.
And apologies for any unintentional off topic direction.
I guess what I wanted to ask is the affect on the Axo with multiple or higher sampling rates, I've seen live performances on devices running at about 35Khz sampling, and no affect to the sound, well not that I could hear anyway, but would pointless for recording etc.. This is why i thought it was about trading off efficiency on the Axo itself.

#14

I'm interested in working on this if I'm capable! I do some work as a trainee PHP programmer (pretty handy being able to work from home, all my gigggin work cancelled due to Corona). I'm relatively new to it but have just completed a project searching the codebase for functions we wish to faze out and replacing them with a more object oriented approach.

To me this seems like a similar job, searching codebase for dependencies, making the required changes, testing the system for further issues and battling each one till it all works. Seems more like reverse engineering (which I'm good at) than proper programming (in which I'm no expert).

I've downloaded Axoloti Master and located #define SAMPLERATE 48000 . A search for SAMPLERATE brings up quite a lot of results leading me to believe that much dependent code should hopefully take account when SAMPLERATE is changed.

I thought krate would be specified as SAMPLERATE/16 but that doesn't seem to be the case so I guess it's hard-coded with the string "3000" (haven't found it yet). I'd obvs need to find these sort of issues and resolve them with conditionals and variables based on SAMPLERATE (though, thinking about it, krate wants to stay at 3000 not SR/16). Doing this it should be possible for a user to choose the samplerate they would like and have all relevant code account for this in tuning, timing, aliasing/nyquisty stuff.

So questions is, does it sound like I'm on the right path or am I sounding like I've missed some key point or am about to get way over my head?

Certainly won't achieve this without help, for instance I've never compiled something like this before. Have searched "compliling firmware" in the forum and the results aren't encouraging. Is it a case of "if you have to ask how to compile you should stick to the php?" or can someone point me in the right direction?

#15

How is the correct sample rate of 48000hz generated? as you can't set the PLL to generate exactly that sample rate from a 8Mhz oscillator crystal?