Hi, I'm unable to make ampmidid opcode work...

If I do this:

instr 1

   iMidiVel  =     20

   iDecibels =     40
             print ampmidid:i(iMidiVel, iDecibels)

endin

I get always 0, whatever the ampmidid parameters are set to...

How it works?

Regards,
Mauro

I found it was broken; the manual example did not work correctly. Then I looked at the code and
saw a bug. It should be fixed now in git develop.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 21 Nov 2018, at 12:24, Mauro Giubileo  wrote:
> 
> Hi, I'm unable to make ampmidid opcode work...
> 
> If I do this:
> 
> instr 1
>  
>    iMidiVel  =     20
>    iDecibels =     40
>              print ampmidid:i(iMidiVel, iDecibels)
>  
> endin
>  
> I get always 0, whatever the ampmidid parameters are set to...
>  
> How it works?
>  
> Regards,
> Mauro
>  
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks Victor, now the opcode appears to work but I don't understand its results. From the manual I thought this opcode should translate a MIDI velocity value [0..127] in an amplitude value [0.."0dbfs"] in such a way that there will be a given dynamic range (in decibels) between minimum and maximum velocities. But I noticed various oddities...

1) it doesn't check for velocity range, so you can pass to it a velocity above 127 and it will not complain (but the results will be wrong, of course).

2) if you pass to it a velocity of 127 and a dynamic range >= 32  decibels, it will returns amp values > 1. I would expect it returns always values between 0 and 1 or what you set in the 0dbfs global variable.

3) from the source code it appears there is an hidden third undocumented parameter "iuse0dbfs" that enables the opcode to use the 0dbfs global variable for its calculations, instead of the default hard-coded value of 1.

4) I don't understand why the "else dbfs = 1.0;" you added in the source code was necessary, being that the dbfs variable should be initialized with the "dbfs(1)" at line 101 in ampmidid.cpp.

Regards,
Mauro

Il 2018-11-21 18:30 Victor Lazzarini ha scritto:

I found it was broken; the manual example did not work correctly. Then I looked at the code and
saw a bug. It should be fixed now in git develop.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

On 21 Nov 2018, at 12:24, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi, I'm unable to make ampmidid opcode work...

If I do this:

instr 1
 
   iMidiVel  =     20
   iDecibels =     40
             print ampmidid:i(iMidiVel, iDecibels)
 
endin
 
I get always 0, whatever the ampmidid parameters are set to...
 
How it works?
 
Regards,
Mauro
 
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Maybe the author, Michael Gogins can answer these questions. For 4) all I can say is that it appeared dbfs was always zero in your use case and the result was always zero, so that’s that.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 22 Nov 2018, at 09:14, Mauro Giubileo  wrote:
> 
> Thanks Victor, now the opcode appears to work but I don't understand its results. From the manual I thought this opcode should translate a MIDI velocity value [0..127] in an amplitude value [0.."0dbfs"] in such a way that there will be a given dynamic range (in decibels) between minimum and maximum velocities. But I noticed various oddities...
> 
> 1) it doesn't check for velocity range, so you can pass to it a velocity above 127 and it will not complain (but the results will be wrong, of course).
> 
> 2) if you pass to it a velocity of 127 and a dynamic range >= 32  decibels, it will returns amp values > 1. I would expect it returns always values between 0 and 1 or what you set in the 0dbfs global variable.
> 
> 3) from the source code it appears there is an hidden third undocumented parameter "iuse0dbfs" that enables the opcode to use the 0dbfs global variable for its calculations, instead of the default hard-coded value of 1.
> 
> 4) I don't understand why the "else dbfs = 1.0;" you added in the source code was necessary, being that the dbfs variable should be initialized with the "dbfs(1)" at line 101 in ampmidid.cpp.
> 
> Regards,
> Mauro
> 
> 
> 
> Il 2018-11-21 18:30 Victor Lazzarini ha scritto:
> 
>> I found it was broken; the manual example did not work correctly. Then I looked at the code and
>> saw a bug. It should be fixed now in git develop.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 21 Nov 2018, at 12:24, Mauro Giubileo  wrote:
>>> 
>>> Hi, I'm unable to make ampmidid opcode work...
>>> 
>>> If I do this:
>>> 
>>> instr 1
>>>  
>>>    iMidiVel  =     20
>>>    iDecibels =     40
>>>              print ampmidid:i(iMidiVel, iDecibels)
>>>  
>>> endin
>>>  
>>> I get always 0, whatever the ampmidid parameters are set to...
>>>  
>>> How it works?
>>>  
>>> Regards,
>>> Mauro
>>>  
>>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

If I were to hazard a guess, I’d say the C++ initialisers are not being applied. I don’t know the details of the OpcodeBase.hpp 
framework, but this might indicate that something does not work as expected.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 22 Nov 2018, at 09:19, Victor Lazzarini  wrote:
> 
> Maybe the author, Michael Gogins can answer these questions. For 4) all I can say is that it appeared dbfs was always zero in your use case and the result was always zero, so that’s that.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 22 Nov 2018, at 09:14, Mauro Giubileo  wrote:
>> 
>> Thanks Victor, now the opcode appears to work but I don't understand its results. From the manual I thought this opcode should translate a MIDI velocity value [0..127] in an amplitude value [0.."0dbfs"] in such a way that there will be a given dynamic range (in decibels) between minimum and maximum velocities. But I noticed various oddities...
>> 
>> 1) it doesn't check for velocity range, so you can pass to it a velocity above 127 and it will not complain (but the results will be wrong, of course).
>> 
>> 2) if you pass to it a velocity of 127 and a dynamic range >= 32  decibels, it will returns amp values > 1. I would expect it returns always values between 0 and 1 or what you set in the 0dbfs global variable.
>> 
>> 3) from the source code it appears there is an hidden third undocumented parameter "iuse0dbfs" that enables the opcode to use the 0dbfs global variable for its calculations, instead of the default hard-coded value of 1.
>> 
>> 4) I don't understand why the "else dbfs = 1.0;" you added in the source code was necessary, being that the dbfs variable should be initialized with the "dbfs(1)" at line 101 in ampmidid.cpp.
>> 
>> Regards,
>> Mauro
>> 
>> 
>> 
>> Il 2018-11-21 18:30 Victor Lazzarini ha scritto:
>> 
>>> I found it was broken; the manual example did not work correctly. Then I looked at the code and
>>> saw a bug. It should be fixed now in git develop.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 21 Nov 2018, at 12:24, Mauro Giubileo  wrote:
>>>> 
>>>> Hi, I'm unable to make ampmidid opcode work...
>>>> 
>>>> If I do this:
>>>> 
>>>> instr 1
>>>> 
>>>>   iMidiVel  =     20
>>>>   iDecibels =     40
>>>>             print ampmidid:i(iMidiVel, iDecibels)
>>>> 
>>>> endin
>>>> 
>>>> I get always 0, whatever the ampmidid parameters are set to...
>>>> 
>>>> How it works?
>>>> 
>>>> Regards,
>>>> Mauro
>>>> 
>>>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Just dipped into this out of curiosity, with my soon-to-be-updated v 
6.05 of Csound...and the opcode works exactly as described. The output 
value needs to be scaled by 0dbfs. Low values of dB act as a loudness 
limit, so db=20 means that max amplitude will only rise to 0.25 or so. 
Conversely, more usual dB ranges of say 60 or 80 will output max 
amplitude values above 1.0, as shown in the paper - the idea being that 
the 'nominal' midi velocity range (as from a putative slider) is 0 - 100.

The one thought that occurs to me is that in a sense the more idiomatic 
way to implement this in Csound would be to use a function table to hold 
amplitude values, so that users can implement/choose a mapping in the 
score, according to need.

Richard Dobson

On 22/11/2018 09:25, Victor Lazzarini wrote:
> If I were to hazard a guess, I’d say the C++ initialisers are not being applied. I don’t know the details of the OpcodeBase.hpp
> framework, but this might indicate that something does not work as expected.
> ========================
...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Maybe in the version 6.05 of Csound the 0 bug wasn't there. In the v 6.12 it returned always 0.

Anyway, I read that paper but I don't understand the reason to let the returned amp values go beyond 1...  To me the "0dbfs" is a volume limit that I should never exceed, otherwise I would have clipped/distorted sounds, so I created my little formula directly in Csound to achieve the result I wanted:

 iVol = iDynamics * (iMidiVel / 127)^2 + 1 - iDynamics

where iDynamics is not expressed in decibels but it's just a value in [0..1] that means:

 0: no dynamics at all (the curve is a flat line always = 1)
 1: max dynamic range (the curve is like "Figure 1" in that paper, apart that its max peak now is always at 1 when velocity is 127)

Regards,
Mauro

Il 2018-11-22 11:32 Richard Dobson ha scritto:

Just dipped into this out of curiosity, with my soon-to-be-updated v 6.05 of Csound...and the opcode works exactly as described. The output value needs to be scaled by 0dbfs. Low values of dB act as a loudness limit, so db=20 means that max amplitude will only rise to 0.25 or so. Conversely, more usual dB ranges of say 60 or 80 will output max amplitude values above 1.0, as shown in the paper - the idea being that the 'nominal' midi velocity range (as from a putative slider) is 0 - 100.

The one thought that occurs to me is that in a sense the more idiomatic way to implement this in Csound would be to use a function table to hold amplitude values, so that users can implement/choose a mapping in the score, according to need.

Richard Dobson

On 22/11/2018 09:25, Victor Lazzarini wrote:

If I were to hazard a guess, I'd say the C++ initialisers are not being applied. I don't know the details of the OpcodeBase.hpp
framework, but this might indicate that something does not work as expected.
========================

...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think the thing about that paper is they they were specifically trying 
to replicate what real hardware MIDI synths do. They show, among other 
things, just how variable in behaviour instruments can be. Of course, 
the numeric range 0-127 is an emergent feature of 7bit values, with 64 
as the "default" for synths with no velocity sensing. To get a synth 
keyboard to generate values even close to 127 you have to whack the key 
pretty hard - I've tried! Fair enough then if synths offer very little 
meaningful change between 100 and  127. And I would not want to wear out 
my keyboard prematurely!  So using a working range 1 - 100 is quite 
reasonable, to enable a connected MIDI input to realise as much of the 
computable dynamic range as possible; in effect the opcode just offers a 
little bit of headroom when players are going all hammerclavier. There 
is no requirement (intractable in practice) for each opcode to stick 
below 0dbfs (all signals are floating-point), only that the final output is.


At least, knowing 6.05 works will help to find what has changed 
adversely in 6.12 etc.

Richard Dobson

On 22/11/2018 11:24, Mauro Giubileo wrote:
> Maybe in the version 6.05 of Csound the 0 bug wasn't there. In the v 
> 6.12 it returned always 0.
> 
> Anyway, I read that paper but I don't understand the reason to let the 
> returned amp values go beyond 1...  To me the "0dbfs" is a volume limit 
> that I should never exceed, otherwise I would have clipped/distorted 
> sounds, so I created my little formula directly in Csound to achieve the 
> result I wanted:
> 
>   iVol = iDynamics * (iMidiVel / 127)^2 + 1 - iDynamics
> 
> where iDynamics is not expressed in decibels but it's just a value in 
> [0..1] that means:
> 
>   0: no dynamics at all (the curve is a flat line always = 1)
>   1: max dynamic range (the curve is like "Figure 1" in that paper, 
> apart that its max peak now is always at 1 when velocity is 127)
> 
> Regards,
> Mauro
> 
..

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.

It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.

Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.

Regards,
Mauro

Il 2018-11-22 13:23 Richard Dobson ha scritto:

I think the thing about that paper is they they were specifically trying to replicate what real hardware MIDI synths do. They show, among other things, just how variable in behaviour instruments can be. Of course, the numeric range 0-127 is an emergent feature of 7bit values, with 64 as the "default" for synths with no velocity sensing. To get a synth keyboard to generate values even close to 127 you have to whack the key pretty hard - I've tried! Fair enough then if synths offer very little meaningful change between 100 and  127. And I would not want to wear out my keyboard prematurely!  So using a working range 1 - 100 is quite reasonable, to enable a connected MIDI input to realise as much of the computable dynamic range as possible; in effect the opcode just offers a little bit of headroom when players are going all hammerclavier. There is no requirement (intractable in practice) for each opcode to stick below 0dbfs (all signals are floating-point), only that the final output is.


At least, knowing 6.05 works will help to find what has changed adversely in 6.12 etc.

Richard Dobson

On 22/11/2018 11:24, Mauro Giubileo wrote:

Maybe in the version 6.05 of Csound the 0 bug wasn't there. In the v 6.12 it returned always 0.

Anyway, I read that paper but I don't understand the reason to let the returned amp values go beyond 1...  To me the "0dbfs" is a volume limit that I should never exceed, otherwise I would have clipped/distorted sounds, so I created my little formula directly in Csound to achieve the result I wanted:

  iVol = iDynamics * (iMidiVel / 127)^2 + 1 - iDynamics

where iDynamics is not expressed in decibels but it's just a value in [0..1] that means:

  0: no dynamics at all (the curve is a flat line always = 1)
  1: max dynamic range (the curve is like "Figure 1" in that paper, apart that its max peak now is always at 1 when velocity is 127)

Regards,
Mauro

..

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Or, if you like the overall shape of the velocity curve, you could use a 
scalar modifier. For example, using a reasonable maximum ampmidid db 
value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit 
sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below 
digital peak - safe, and pretty much ideal for output.

Richard Dobson

On 22/11/2018 12:52, Mauro Giubileo wrote:
> I understand your reasoning, but you have to consider that not all MIDI 
> keyboards have real weighted keys, and that usually they have a setting 
> to change the velocity response curve, so the results can be quite 
> different for different keyboard models and different settings.
> 
> It's not so rare as you think that a keyboard could make a velocity 
> value beyond 100. For example, with my cheap MIDI keyboard 
> (semi-weighted keys) at default I can easily get values between 90 and 
> 110 and if I bang it a little more hard, 127 is not so difficult to get.
> 
> Anyway, I don't like that a conversion from MIDI vel to amplitude could 
> go beyond the 0dbfs global variable and my csound synth generates a 
> distorted sound, so for now I will stick with my formula that prevents 
> this possibility.
> 
> Regards,
> Mauro
...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, rescaling the output returned by that opcode to make it in a safer range is another option.

Regards,
Mauro

Il 2018-11-22 14:59 Richard Dobson ha scritto:

Or, if you like the overall shape of the velocity curve, you could use a scalar modifier. For example, using a reasonable maximum ampmidid db value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below digital peak - safe, and pretty much ideal for output.

Richard Dobson

On 22/11/2018 12:52, Mauro Giubileo wrote:

I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.

It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.

Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.

Regards,
Mauro

...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I will look at the code and see what the problem is. And I will fix it
or introduce a new variant of the opcode if it does not behave as I
intended, or as you require.

For what it's worth, I have used the following Csound code to rescale
MIDI velocities to usable amplitude values:

i_midi_dynamic_range = i(gk_Sweeper_midi_dynamic_range)
i_midi_velocity = p5 * i_midi_dynamic_range / 127 + (63.5 -
i_midi_dynamic_range / 2)
; Adjust the following value until "overall amps" at the end of
performance is about -6 dB.
i_level_correction = 58
i_normalization = ampdb(-i_level_correction) / 2
i_amplitude = ampdb(i_midi_velocity) * i_normalization
k_gain = ampdb(gk_Sweeper_level)

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Thu, Nov 22, 2018 at 10:33 AM Mauro Giubileo
 wrote:
>
> Yes, rescaling the output returned by that opcode to make it in a safer range is another option.
>
> Regards,
> Mauro
>
>
> Il 2018-11-22 14:59 Richard Dobson ha scritto:
>
> Or, if you like the overall shape of the velocity curve, you could use a scalar modifier. For example, using a reasonable maximum ampmidid db value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below digital peak - safe, and pretty much ideal for output.
>
> Richard Dobson
>
> On 22/11/2018 12:52, Mauro Giubileo wrote:
>
> I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.
>
> It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.
>
> Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.
>
> Regards,
> Mauro
>
> ...
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Michael, it would be nice if we could have a parameter to make the curve range from 0 to 0dbfs, like the simple formula I posted before does. Being that in the source code there is that undocumented parameter, maybe we could use that to set this behavior. I think that if the user specifies that he wants to use the 0dbfs value, then we can expect that he doesn't want to get values beyond 0dbfs.

Another parameter that would be very nice is the "hardness" level of the velocity curve.

In my little formula:

 iVol = iDynamics * (iMidiVel / 127)^iHardness + 1 - iDynamics

to make the velocity curve "harder", I just have to use a bigger value for the iHardness value.

To better explain what I would like to have, I made an editable graphic where you can see how my little formula behaves. Check this link:

https://www.desmos.com/calculator/fvxupgp4ef

In that graph you can change the 'd' parameter to alter the dynamic range and the 'h' parameter to set the hardness level.

Regards,
Mauro

Il 2018-11-22 16:53 Michael Gogins ha scritto:

I will look at the code and see what the problem is. And I will fix it
or introduce a new variant of the opcode if it does not behave as I
intended, or as you require.

For what it's worth, I have used the following Csound code to rescale
MIDI velocities to usable amplitude values:

i_midi_dynamic_range = i(gk_Sweeper_midi_dynamic_range)
i_midi_velocity = p5 * i_midi_dynamic_range / 127 + (63.5 -
i_midi_dynamic_range / 2)
; Adjust the following value until "overall amps" at the end of
performance is about -6 dB.
i_level_correction = 58
i_normalization = ampdb(-i_level_correction) / 2
i_amplitude = ampdb(i_midi_velocity) * i_normalization
k_gain = ampdb(gk_Sweeper_level)

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Thu, Nov 22, 2018 at 10:33 AM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

Yes, rescaling the output returned by that opcode to make it in a safer range is another option.

Regards,
Mauro


Il 2018-11-22 14:59 Richard Dobson ha scritto:

Or, if you like the overall shape of the velocity curve, you could use a scalar modifier. For example, using a reasonable maximum ampmidid db value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below digital peak - safe, and pretty much ideal for output.

Richard Dobson

On 22/11/2018 12:52, Mauro Giubileo wrote:

I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.

It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.

Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.

Regards,
Mauro

...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have examined the ampmidid source code and performed some of my own tests.

The opcode has one bug. It assumes that the default 0dbfs level is 1,
but in reality it is 32768. Taking this into account, the opcode
behaves as documented.

I have corrected this bug.

I looked at your online graph. Very nice, and very clear. I will
implement your formula as a separate opcode. What is the clearest and
most obvious name that you can think of for this new opcode?

Best,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Thu, Nov 22, 2018 at 11:35 AM Mauro Giubileo
 wrote:
>
> Hi Michael, it would be nice if we could have a parameter to make the curve range from 0 to 0dbfs, like the simple formula I posted before does. Being that in the source code there is that undocumented parameter, maybe we could use that to set this behavior. I think that if the user specifies that he wants to use the 0dbfs value, then we can expect that he doesn't want to get values beyond 0dbfs.
>
> Another parameter that would be very nice is the "hardness" level of the velocity curve.
>
> In my little formula:
>
>  iVol = iDynamics * (iMidiVel / 127)^iHardness + 1 - iDynamics
>
> to make the velocity curve "harder", I just have to use a bigger value for the iHardness value.
>
> To better explain what I would like to have, I made an editable graphic where you can see how my little formula behaves. Check this link:
>
> https://www.desmos.com/calculator/fvxupgp4ef
>
> In that graph you can change the 'd' parameter to alter the dynamic range and the 'h' parameter to set the hardness level.
>
> Regards,
> Mauro
>
>
>
> Il 2018-11-22 16:53 Michael Gogins ha scritto:
>
> I will look at the code and see what the problem is. And I will fix it
> or introduce a new variant of the opcode if it does not behave as I
> intended, or as you require.
>
> For what it's worth, I have used the following Csound code to rescale
> MIDI velocities to usable amplitude values:
>
> i_midi_dynamic_range = i(gk_Sweeper_midi_dynamic_range)
> i_midi_velocity = p5 * i_midi_dynamic_range / 127 + (63.5 -
> i_midi_dynamic_range / 2)
> ; Adjust the following value until "overall amps" at the end of
> performance is about -6 dB.
> i_level_correction = 58
> i_normalization = ampdb(-i_level_correction) / 2
> i_amplitude = ampdb(i_midi_velocity) * i_normalization
> k_gain = ampdb(gk_Sweeper_level)
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> On Thu, Nov 22, 2018 at 10:33 AM Mauro Giubileo
>  wrote:
>
>
> Yes, rescaling the output returned by that opcode to make it in a safer range is another option.
>
> Regards,
> Mauro
>
>
> Il 2018-11-22 14:59 Richard Dobson ha scritto:
>
> Or, if you like the overall shape of the velocity curve, you could use a scalar modifier. For example, using a reasonable maximum ampmidid db value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below digital peak - safe, and pretty much ideal for output.
>
> Richard Dobson
>
> On 22/11/2018 12:52, Mauro Giubileo wrote:
>
> I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.
>
> It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.
>
> Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.
>
> Regards,
> Mauro
>
> ...
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sorry Michael, I missed your post...

Thank you very much for the new opcode you made (ampmidicurve)!

Il 2019-05-26 19:00 Michael Gogins ha scritto:

I have examined the ampmidid source code and performed some of my own tests.

The opcode has one bug. It assumes that the default 0dbfs level is 1,
but in reality it is 32768. Taking this into account, the opcode
behaves as documented.

I have corrected this bug.

I looked at your online graph. Very nice, and very clear. I will
implement your formula as a separate opcode. What is the clearest and
most obvious name that you can think of for this new opcode?

Best,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Thu, Nov 22, 2018 at 11:35 AM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

Hi Michael, it would be nice if we could have a parameter to make the curve range from 0 to 0dbfs, like the simple formula I posted before does. Being that in the source code there is that undocumented parameter, maybe we could use that to set this behavior. I think that if the user specifies that he wants to use the 0dbfs value, then we can expect that he doesn't want to get values beyond 0dbfs.

Another parameter that would be very nice is the "hardness" level of the velocity curve.

In my little formula:

 iVol = iDynamics * (iMidiVel / 127)^iHardness + 1 - iDynamics

to make the velocity curve "harder", I just have to use a bigger value for the iHardness value.

To better explain what I would like to have, I made an editable graphic where you can see how my little formula behaves. Check this link:

https://www.desmos.com/calculator/fvxupgp4ef

In that graph you can change the 'd' parameter to alter the dynamic range and the 'h' parameter to set the hardness level.

Regards,
Mauro



Il 2018-11-22 16:53 Michael Gogins ha scritto:

I will look at the code and see what the problem is. And I will fix it
or introduce a new variant of the opcode if it does not behave as I
intended, or as you require.

For what it's worth, I have used the following Csound code to rescale
MIDI velocities to usable amplitude values:

i_midi_dynamic_range = i(gk_Sweeper_midi_dynamic_range)
i_midi_velocity = p5 * i_midi_dynamic_range / 127 + (63.5 -
i_midi_dynamic_range / 2)
; Adjust the following value until "overall amps" at the end of
performance is about -6 dB.
i_level_correction = 58
i_normalization = ampdb(-i_level_correction) / 2
i_amplitude = ampdb(i_midi_velocity) * i_normalization
k_gain = ampdb(gk_Sweeper_level)

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Thu, Nov 22, 2018 at 10:33 AM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:


Yes, rescaling the output returned by that opcode to make it in a safer range is another option.

Regards,
Mauro


Il 2018-11-22 14:59 Richard Dobson ha scritto:

Or, if you like the overall shape of the velocity curve, you could use a scalar modifier. For example, using a reasonable maximum ampmidid db value of 90, midiv=127 results in an amplitude of 1.42 (near as dammit sqrt(2)). Scaling this by 0.5 gives you 0.71, approx RMS peak, 3dB below digital peak - safe, and pretty much ideal for output.

Richard Dobson

On 22/11/2018 12:52, Mauro Giubileo wrote:

I understand your reasoning, but you have to consider that not all MIDI keyboards have real weighted keys, and that usually they have a setting to change the velocity response curve, so the results can be quite different for different keyboard models and different settings.

It's not so rare as you think that a keyboard could make a velocity value beyond 100. For example, with my cheap MIDI keyboard (semi-weighted keys) at default I can easily get values between 90 and 110 and if I bang it a little more hard, 127 is not so difficult to get.

Anyway, I don't like that a conversion from MIDI vel to amplitude could go beyond the 0dbfs global variable and my csound synth generates a distorted sound, so for now I will stick with my formula that prevents this possibility.

Regards,
Mauro

...

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here