Hi everyone. I’m thinking of overriding the Csound orchestra sampling rate for plugins. It would avoid confusion for users who notice re-pitching of their instruments when they use them in sessions with contrasting sample rates. It shouldn’t make any difference to Csound instruments so long as they use the sr keyword when querying the sampling rate. If anyone has any strong objections let me know.
Sampling rate override
I like this idea… hopefully it doesn’t break too much of my stuff, I’m pretty sure I haven’t hard coded sample rates anywhere.
I assume in standalone mode cabbage will still default back to a user set sr? Or will it assume a default and negate the need for us to declare sr at all?
It will actually use the current sample rate taken from the audio settings. It would be difficult to override this with the Csound one. I think it’s a good move as it will force people to make their instruments sample rate agnostic.
That’s a much more logical solution. I like it!
In which case it’s probably best for me to update the template files so they don’t even list a sampling rate.
Agreed.
How difficult would it be to generate output (probably console) listing the requested sr vs. the actual sr?
For example, if I render a very old cabbage instrument that has sr=22050, but it defaults to 44100 in the new system… could we see some sort of error or warning that this has change has happened?
t wouldn’t be that tricky, but you would need to use a csoundoutput console in your plugin, which means extra work for the user. Might be better to put this info into the plugin’s log file.
Sorry… I’m not sure we’re talking about the same thing (or I misunderstood your reply). I meant for this to be a function of cabbage itself. If the rendered file requests an sr different from what is actually going to happen, report it to the console.
edit: Ok, I think I see what you’re getting at. When exported that message would not be visible without an output widget. I guess I was mostly focused on testing and debugging in a non-exported state.
In principle I like the idea of making more settings within the Cabbage audio settings.
There are a couple of things I wonder about though. At the moment, diskin and soundin will resample their sound file if the header sr doesn’t match. This means you won’t get any unexpected transpositions if you decide to alter sr, which is quite nice. Will diskin and soundin still be able to respond in this way if Csound loses direct control of sr?
On the other hand, a process that uses a sound file loaded into a function table, such as convolution, depends on sr matching that of the sound file(s). If sr is altered, transposition will occur. For this reason it could be argued that it is useful to be able to specify a specific sr for a specific csd.
Could a solution be that, if no sr is specified in the Csound orc header, Cabbage can use the sr specified in its own audio settings; but if sr is specified in the csd, then that takes precedent. At the moment in standard Csound code, leaving out sr prompts a default of 44100.
Sorry not to be giving an unreserved thumbs up but I’m just trying to anticipate potential problems.
I’m pretty sure they will. Csound will still have a sample rate set, it just might not be the original one set in the orchestra.
This sounds like the best solution I think. Only I don’t think there is currently a way of finding this info out using the Csound API. I would need to parse the header section myself, which should be Ok, although more prone to error than if Csound could report it. .
I’ve implemented this now. Cabbage will only override the sampling rate, based on the host rate, if the user hasn’t specified a sampling rate in their header section (as per Iain’s suggestion). I’ve updated the template code too so that it no longer has an sr=44100 defined. Those of you who don’t want your instruments re-pitching in a host can simply remove the sr declaration. I will give it some testing tomorrow and release new binaries soon.
1 Like
For an instrument I recently wrote I found that it was off tune by a factor 1.0884. The number immediately let me find out why: Because I did not use the canonical Cabbage template there was still a sr=44100 in it. I made a small test file for this:
<Cabbage>
form caption("Untitled") size(400, 300), colour(58, 110, 182), pluginid("def1")
keyboard bounds(8, 158, 381, 95)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1
instr 1
kEnv madsr .1, .2, .6, .4
aOut oscils p5, p4, 0
outs aOut*kEnv, aOut*kEnv
endin
</CsInstruments>
<CsScore>
f0 z
</CsScore>
If I run this and play an a4 it will produce 479Hz for any DAC I choose with -odac. If I run the same file through csoundQT it plays 440Hz. Of course, I can either change to sr=48000 or simply delete that line. (Which only leads me to the problem that sr/2 as Nyquist frequency does not work anymore.)
Now I have two questions:
-
What is the safest way to create code or VSTs which can be used by others without this happening accidentally? (I see a problem with users having sound drivers with different sr defaults.)
-
Is there any way to change the sr to another value, e.g. 96000, on purpose? (If I understand it correctly, sr=96000 sets the value of sr to 96000 within the Cabbage script, but the sound driver is still called with a sampling rate of 48000 because of the override. Indeed I found a downshift by an octave which does not happen if I run from csoundQT.)
If you remove the line sr = 44100 I think the sample rate will be equal to whatever host the plugin is running in?
+1 this is the best approach.
I tried it from Reaper. It works also if I change the sample rate in Reaper between 44100 and 48000, and also for rendering to high sample rates as 192k. I also noticed that the sr/2 still works. Even if I remove the line sr=44100 sr is still defined to the actual sample rate.
By omitting any sample rate assignment in your Csound code, Cabbage override Csound’s default sampling rate with that of the host. So you should always leave out sr=... in your Csound code. That way users are free to use whatever sampling rate they wish, without having to update their Csound code accordingly. 