We need a level normalisation convention

[gleb812]

Folks,

NM is MIDI compatible and uses 0..+64 range for unipolar k-rate signals, and -64...+64 for bipolar signals. The audio signals seem to be of the same level.

Since there are lots of options, we should set a convention on levels.

• We can have even 0dbfs = 64
• We can normalise all signals to -64...64 / 0...64.
• On the other hand, it would be harder to combine pch2csd instruments with normal Csound way of coding in case of 64 based scaling
• We can do some re-scaling inside each UDO. But it literally means we have to do kOut /= 64 at the output and kIn *= 64 at the input layer of each UDO.

Any suggestions are welcome!!

[zappfinger]

I'd say : normalize everything in the templates at 0dbfs=1 and let the Python parser handle it...

Richard

On 17/03/18 19:01, gleb812 wrote:

Folks,

NM is MIDI compatible and uses 0..+64 range for unipolar k-rate signals, and -64...+64 for bipolar signals. The audio signals seem to be of the same level.

Since there are lots of options, we should set a convention on levels.

• We can have even 0dbfs = 64
• We can normalise all signals to -64...64 / 0...64.
• On the other hand, if would be harder to combine pch2csd instruments with normal Csound way of coding
• We can do some re-scaling inside each UDO. But it literally means we have to do kOut /= 64 at the output and kIn *= 64 at the input layer of each UDO.

Any suggestions are welcome!!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/16, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZ6pCGN_HJEaJCVrlrPzWaywr1ArNks5tfU-GgaJpZM4Su5uW.

[gleb812]

@zappfinger The problem here is that we should have Clavia's native values inside the patch, e.g. for ConstantValue we should have say +45, so the users can tweak it in Csound just like in NM. So according to this statement, at least the inputs of opcodes should be Clavia-compatible...

[ghost]

@gleb812 I think you should descide on this, as I don’t have enough Csound experience to predict what complications either of the approaches might impose on the further development. I’d go for the simplest to implement one, which, I assume, is making -1…1 or something like that the convention.

[gleb812]

Ok guys. Here is what I suggest...

We will use -1...1/ 0...1 internally. Everything will be scaled to these ranges. Clavia has +12 dB overhead. It allows to have x4 amplification of any Osc output. We will have normal 0dbfs = 1.0 So it means we should add to the Out2 and others Outs something like

a1 limit a1, -4, 4 a1 /= 4

In this case, we simulate 4 times overhead for any oscillator with an amp of 1. And finally we still be under 0dbfs after normalization by 4.

If it sounds good, I will begin to fix all amplitude issues..

[ghost]

I couldn’t understand that. Clavia’s oscillators don’t output at maximum volume by default, right? If that’s the problem, then the UDOs should do that as well. And when the x4 comes in, they output at maximum (i.e. -1…1). Am I missing something?

[gleb812]

@ech2 Yes. Let's make it clear. If you start multiplying an output of any generator in Clavia, the truncation will occur at > 4. It means that if 0dbfs = 1, the Oscs output is always 0.25. It is not really good, since it is much better to live in a -1..1 world). Meanwhile, we cannot do 0dbfs=4.0. It is too weird for me. So MY decision is to have output level of 1, and consider that truncation will occur at 4. Then do all processing and everything, and in the end limit the result with [-4,4]. It imitates 0dbfs=4.0. And since we are at 0dbfs=1.0 we should divide it down by 4. So technically an OscA -> Out2 chain will give a 0.25 amp.

[ghost]

@gleb812 OK, let me try to understand you. You’re saying that there’s +12 dB of headroom available for oscillators. If so, at first glance making them output signals at 0.25 amp looks perfectly fine to me. One complexity though is how to treat these +12 dB when using this signal for modulation. Is this what are you trying to address with the level normalizatoin convention?

I’d say we should do an experiment or a few and look on how the modulation behaves. E.g. we can set the modulation range and see how the signal would modulate a parameter. If an amplified signal modulates at the full range of the parameter, then this is one thing. If the signal goes beyond the range, then this is another one. In any case, the problem boils down to making proper scales in the modulated modules.

If I understood your problem correctly.

[gleb812]

@ech2 well, actually the main reason for posting this issues is the modulation. It is much better to have -1..1 or 0..1 ranges for modulation values. Technically there is no difference, cos everything will be hidden inside in the deep Csound space. actually zak-space. BUT we can assume the situation when some user would like to do some normal Csound coding in our generated csd patches, e.g. somebody would like to insert a Csound filter between OscA and Outs and modulate it with say LfoC. Here it is more intuitively to have -1..1 ranges... You copy me here?

[ghost]

@gleb812 OK, I understand now. For this case, I think, -1…1 range at +12 dB boost is the right choice. Our main goals is to recreate NMG2, then goes hackability. For hacking the code we should encourage tinkering with UDOs, because manual Zak connections is stupidly complex. Of course one can make a new UDO and connect it through Zak with other ones, but… I think a GUI patch editor with the ability to view the code is more appropriate for these things, but we don’t have resources for this at the moment. That’s why, in my opinion, we should make the scaling convention to our lives simpler, and not think too much about potential tinkerers in some distant future.

[gleb812]

@ech2 Ok, then I gonna fix all oscs and add couple of lines to Outs