Kara-Moon Forum

I want a few bars to swell a bit.

According to the docs, Swell takes one or two volumes, and a number of bars. So

Swell 60 100 6

sets the volume to 60, increases to 100 over 3 bars, and decreases to 60 over the next 3 bars. Good.

Cresc 20 100 4

sets the volume to 20, increases to 100 over 4 bars, and stays at 100. Good.

But for

Decresc -10 -40 4

the docs suddenly starts talking about percentages. The above statement is documented to lower the volume with 10% and then lower with another 40% over the next 4 bars. (Numerically: if the volume were 100 it is set to 90, and then lowered to 81,72,63,54).

Apparently, +10 also indicates 10 percent volume increase. Good. Confusing but good.

In the table, volume symbols like p, f, m are related to percentual changes. This should be volume values. fff goes to 180, not 180% of the current value.

I think a future version could improve this by supporting %-values. E.g.

Decresc 80 -40 4

sets volume to 100 and decreases to 40 (80 - 40) over 4 bars, while

Decresc 80 40% 4

would decrease to 48 ( 80 - 40% ).

The reason for the confusion ... is that I'm easily confused :) I think the real reason lays with order in which the function was conceived/written with the first incarnation being "change from 'ff' to 'pp', etc".

In the 2nd phase, we've added numeric values to replace the "pp" etc. They are a "bit" more accurate, but on reflection, I think they are a tad useless. And, note, that the docs say that this is not recommended!

Thirdly, you can do the % changes. And, to me, this does make sense.

The SWELL section should be read as part of of the Cres/Decres section. Perhaps a pointer needed?

I agree that the plain numerics are confusing. Perhaps they should be flagged with warnings? Or even just deleted?

As to the volume table, if memory serves me, the values there are just percentages. 'M' is set to 1.00 (100%), etc. And, you are right that 'fff' is 180%. You'll have to trace though the nest of code to see what all the convolutions do with the value, but as far as I know/remember it works :)

I think, not committed to, the idea that the options should be symbolic (ff, pp, etc), OR percentage with a - or +. And, just numeric would be illegal.

Thoughts?

I should add that all this volume stuff is applied to the original volume (actually velocity) defined in the pattern definition for the given track item. Technically, the volumes should be in the range 0 to 127 (the MIDI range), but we permit large values just to force things for guitar bands :)  So, volume adjustments are %s applied to that initial range.

In general, a numeric volume is taken to be absolute. Volume 60 sets the volume to 60.
A number preceded with a sign is taken to be a percentage. Volume +20 increases the volume with 20%. Likewise Cres, Decresc and Swell.

It would be nice if a trailing precentage sign were allowed. This would be a mere cosmetic change in the cases of +/- values but adds the possibillity to write Volume 80% instead of the much less intuitive Volume -20. Read on.

The volume mnemonics are just another way to write numbers, so they are interpreted as absolute values. Volume mp sets the volume to 70. So the comments in the table are misleading, since they suggest that the mnemonics are percentage values.

Routine calcVolume in MMA/volume.py contains a few errors (due to incremental implementations) so I took the liberty to rewrite it ;) .
The attached version correctly handles +/- prefixes (also with symbolic volumes) and %-postfix.

Note that Volume mp will still set the volume to 70, not adjust to 70%. Changing this would break quite some mma programs I'm afraid. Volume mp% will adjust to 70%. Volume +mp (and Volume +mp%) will increase by 70%.

I didn't check the behaviour of Accent and VolumeRatio.

BTW, Volume range is 0 to 255, corresponding to MIDI velocity values 0 to 127. Volume values greater than 256 are allowed but silently truncated to MIDI value 127. I think it would be nice to have a one-time warning that excessive volume values will be truncated.

BTW: While you can write Tempo *2 you cannot write Volume *2 (which would not make much sense anyway).

Give me a few days to respond to this. I'm really tied up with playing in a local presentation of White Christmas for the next while.

I had a look at the patch, and I agree that it fixes some issues. However, are we missing some things?

- The initial volume setting for the master and all tracks is 100, which is the same as the 'M' neumonic. I am hesitant to call this 100% since that may indicate that the setting should play things as loud as possible ... and that isn't so. All it means is that when we go though a pattern (say Bass 1 8 90) that the 90 (a MIDI velocity between 0 and 127) is adjusted to 100% of that velocity (and here I go using %s).

- Musically, a setting like +p (add the value of pianissimo to the current value) makes no sense. Either does a neumonic with a trailing %. Yes, you are right that 'P' is just a substitute for 70%, but the manual is quite clear that initial settings should use the neumonic if possible.

- Now, your side, I'd agree that increasing/decreasing a volume should be done in the following manner:

              -  +40  to increase the volume by 40. In this case MP could become MF. Same for -40.
              -  +40% would add 40% of the current volume (or subtract)
              -   40 would set the volume to P.

   So, correct me if I'm wrong, the big difference is the inclusion of the % sign and the effect of +/-? I think you are right here ... the way it's handled right now -40 is assumed to be a % and that is probably dumb. And, in hindsight, I wonder if ONLY mnemonics should have been allowed ... too late now.

Look forward to your thoughts on this!
 
             

I agree that +p and mp% etc. are meaningless. It's jusy a sideeffect from my proposed patch that makes it work ;).


So the mnemonic 'M' is the value 100, not 100%.

IOW,
results in volume 100 (=M), not 70 (=100% of 70).


I though we just concluded that 'P' is a substitute for 70, not 70%...

 
Right. Also:
-  40% would set the volume to 40% of the current value.

Sorry about the format of this reply. I can't seem to use nested quotes properly from here.

- I think that it'll be easy enough to determine that a leading +/- or trailing % is not valid with a mnemonic and flag that as an error.

- 'M' is definitely 100%. Well, it means that the note velocities are to be left at 100% of the values defined in the track pattern.

- Yes, setting volume to 'M' (or whatever) sets the volume to that level. They don't stack.

- Actually 'P' is 40 :) But, it doesn't matter. The setting ends up being an absolute value which other parts of MMA apply to the note velocities.

- 40% _should_ either set the volume to 40% of the current value. Or should it add (or in the case of -40%) subtract) that? In the first,

     Volume F
     Volume 40% /// same as +40%

would set the volume to 60 (somewhere between P and MP if I'm reading the table correctly). Right now -/+40 adds/subtracts 40% of the current value.

Perhaps for clarity it would be best to have:

    40 - set to 40.
    +40 - add 40% of the current volume
    -40 - subtract 40% of the current volume

Are the last 2 the same then, as +/-40%?? I think so...

And, for the final "40%" ... now it get confusing :) Is this 40% of the current volume or the same as either + or - 40?

Finally, the docs say that "F+20" will generate a volume of 20% greater than "F". I think that we achieve this by taking the value of F and adding 20% to it. Do the docs need work for this to be more clear ... all so often, I find, the code is right and the docs are lacking ... much like other things in my life :)
 

Yes. Updated patch attached.


I think you've just hit the nail on the head. While volume values are absolute numeric values, internally they are scale values. That's why I, as a programmer/songwriter refer to values and you, as the implementer, refer to percentages. The preamble of the 'Volume' section of the documentation describes this clearly.

From the aspect of the user, the Volume command (and its associates, cresc/decresc/swell) deals with values. As you wrote:


While mathematically +40 is the same as 40, this does not apply here. 40 means set the current value to 40 (v = 40). +10 means: add 10 to the current value (v = v + 40). 40% means: set the current value to 40% of the current value ( v = 40/100 * v), and +10% means: increase the current value by 10% (v = (100+10)/100 * v).


Which is unfortunate, but this cannot be changed without breaking existing songs.


Yes. And IMHO it would be much better to always use the +/-40% notation since it is unambiguous.


Just 40% of the volume. There is no increment/decement (+/-) specified.


No problem, since this is no longer valid after applying my patch :).

Seriously, I think that mixing mnemonics and numbers is confusing.

And if it were made to work it would be legacy '+20 means +20%'. Do you think it should work?
It is never used in any of the standard libraries.

I think this is very close. Just had a quick look and nothing is standing out as a problem ...

Just by way of further clarification, here is how I look at all this:

 1. The velocities in the pattern are like the absolute volumes generated by a real instrument. So, a "real" instrument will have a limited upper/lower volume ... an acoustic guitar can only play so loud, etc. In a groove these velocities are used to set relative volumes between various tracks.

2. In addition to (1), we use TRACK Volume (NOT velocity!) settings in tracks to fine tune the relationship of the volumes between instruments. And, this is handy so we can use the same pattern in different contexts without having to redefine them.   

3. Finally, we use the Volume setting (along with Cres/decres, etc) to adjust how far we have adjusted the big knob on the front of the amp :)

4. Somewhere between 1, 2 and 3 we also apply things like Accent and Rvolume :) (humanize).

Damn, but there are a lot of concepts here :) And then there is the whole MIDI track/master volume thing! Plus, the output of the MIDI controller and the setting of the big knob on the front of the amp!

Okay, this IS NOT well tested ... but I think it will work :) Attached is a drop in replacement for the calcVolume() in volume.py

It should permit the following:

   value          == set volume
   +/-value     ==  inc/dec existing volume
   +/-value%  == inc/dec existing volume my percentage
   
The value can be a number or a valid mnemonic (100 or m, etc).

To further complicate, any value and be set as value +/- value[%] (M+100, M-10%, etc)

Some existing libraries and songs may be broken by this patch, but I'm hoping that is minor. And the result should be worthwhile!

Please, give this a test run on your files and let me know.

Best of the season to all of you!

Indeed :)

    Volume 70
    Volume +20%

sets the volume to 77 (rounded from 77.2) instead of 94.

    Volume 60+20%

sets the volume to 0 (rounded from 0.008)

I also think that, as you pointed out earlier, volumes like +p and +p% do not make sense and should not be allowed.

I did like my version better ;).

WARNING: Stupid feature ahead...

To a musician, volume +p and volume +f would make sense. For example volume +p would mean to step one down the scale, e.g. p would become pp, ff would become f, and so on. This would be easy to implement if the steps were spreaded equally over the 0..200 range. Then +p would just mean: one step down (not up!).

I think I was tired yesterday :) Good thing that today is here to rework (and TEST!) this bit of code. Will post more later.

Okay ... not well tested at all.

And, yes, we always tend to like our out code better :) Speaking of our own code ... I'm slowly (very slowly) adjusting to the concept that writing more clear code is way more important than writing fast and/or small code! I remember when I started this terrible hobby I was writing applications in 6809 assembler. Spent hours optimizing a small routine to save 1 or 2 bytes of code. And, probably because I was young(ish) and dumb I thought it was fun. Hard to put those lessons aside.

Here is the next version. I think the +/- and % stuff is now right :) I actually tested it and
 
    Volume 70
    Volume +20%

now sets 84. this is 70 + 20% of 70. Not the 94 you have in your message ... I'm assuming you didn't test :)

Instead of not permitting things like +pp etc I am printing warnings. Does that make sense? Could easily change them to errors.

One thing I've not done is to error/warn the syntax of 20+33 ... which is probably just so dumb I can't be bothered :)

Please feel free to hack on this. I'm gone for about a week and won't be doing any coding!!!

And this is still WRONG. Sorry ... but it will need to wait :)

I do not want to be obnoxious, but what is the advantage of your method over mine?
It adds 'Volume 10+20' but even you find that stupid.

I stopped spending time on trying to make programs small and fast several decades ago. I prefer being able to understand what I wrote when I need to maintain code.

Also, most manual micro-optimizations tend to be premature and prone to errors. Compilers do a much better job on optimization. A clean design and proper implementation most of the time leads to small and fast programs anyway. I have had the privilege of getting programming classes from the famous E.W. Dijkstra.

Anecdote: A friend of mine taught programming classes. After the necessary basics he let the students write a simple program. The next day they would continue expanding the program, but he gave all the students a program some of the others wrote instead of their own. They learned the importance of clear code and commenting the hard way. Very effective.

I'm back and ready to get going on all things MMA :) Will sort out the volume issue over the next few days! Promise! Hope to get a beta (last 19!) out around new year and get the first 20.xx out early in 2020.

I have applied your latest patch. All seems to work fine, just a matter of fixing the CHANGES and docs.

Only question I have is this:    should Volume +20 and Volume +20% do the same thing? Yes, I know that's what the docs say, but this might be an opportunity to fix it? Not sure what the advantage would be ...

Yes, this is an opportunity to fix it -- if you dare risk the breakage.

Alternatively, why not add a warning that this is deprecated and will be removed in a future release? This will give the users a chance to detect and correct.

I suggest that we add a warning to detect absolute numeric settings. I think this does it:


However, not sure where (or if) we should worry about the +/- with/without a % sign. What do you think?

I can't comment without the complete source.

But I'd rather take a step back first to ask an important and relevenant question:

What do you want do accept as legal values for a volume?

AFAIC:

• A number, or a mnemonic
• A percentage
• Plus/minus percentage
• Deprecated: plus/minus number (will be interpreted as plus/minus percentage

I don't see the need for number/mnemonic plusminus number/percentage, e.g. 70+10. Do you?

Once we agree on the desired syntax the implementation is trivial.

I will post tomorrow or the next day with a detailed list on this.

The fix in my last mail applied directly to the patch file you sent me. Unfortunately or trees are out of sync :)

The current settings need to be "tweaked" to make the whole thing
a bit more logical. So, let's start off with the simple setting.
Currently we permit this to be done via the VOLUME directive with
a parameter of a mnemonic name or the "percentage" value associated
it.

    Volume MF

or

    Volume 110

My first suggestion is to print a warning for the later. Probably
the warning should be a "caution, using a symbolic name is recommended".
And, if we find that we're upsetting anyone we could include a "NOWARN"
in the line, but I don't think it is necessary.

Currently we permit dumb things like "m+20" and even "66-10" as a volume.
This is confusing and should just be eliminated. This will effect some
existing library files, and I don't mind adjusting those if needed.
Mind you, using something like "pp-10" is useful to get a volume setting
a little less that "pp" ... but when reading this I for one never seem
to know if this is 10 less than pp or 10% less (according to the manual
it is 10%). It might be time to bite
the bullet and fix these. Doing a quick scan I only found a few usages
in stdlib/softshoe. If we are voting, I'd vote to kill the option.
And, if someone really, really wants a setting 10% greater than "pp"
just do it in 2 lines:

   Volume pp
   Volume +20%

or, calculate the setting by hand and use the numeric :)

Inc/Dec is common. Currently, a leading +/- will inc/dec the
existing setting by the % value. Honestly, this is, again, confusing.
However, it's used it quite a bit of existing code so I suggest we
print a warning with either "deprecated" or "suggestion". Don't know
which. OTOH, we could say that -/+value subtracts/adds the value to
the existing setting. But, now we are back to the confusion between
absolute and percentage. So, let's not do this!

In the end we should strive to have users always use the % sign.

Am I missing anything else?
   

I think you have it covered mostly. It matches the suggestions I did in my previous posting.

One thing, though: I think that setting the volume to a number is perfectly sane, at least as sane as setting it to some weird mnemonic.

Weird mnemonic? Sorry ... don't know what you mean ... unless it is the "M" which is not standard music notation.

Sorry. Shouldn't have used the word 'weird'...

No problem :)

Are you going to do the final patch on your code for inclusion then?

Attached a total redesigned calcVolume. I used regexp matching to show you how powerful this is and that it makes code easier.

Two remarks:

* you need to add "import re" somewhere to the start of the module
* method setVolume needs a small fix to get the debug message right (reported values are already percentages):

    if MMA.debug.debug:
        dPrint("Volume: %s%%" % (100*volume))

Super. I will give it a go tomorrow ... getting late here. No problems with using re, it's already being imported in some other modules. BTW, I really try to avoid using re, probably 'cause I'm not a perl programmer :) Plus, I tend to get confused by the options/settings and then get afraid that some obtuse input is going to cause the end of the world. And, yes, I should use it more!

Did you attach the correct replacement? When I grab this I end up with a function called  calcVolumeAA() and no references to re.

I have applied the debug patch. Thanks.

Oops, sorry for that! Correct version attached.

I'm on the edge here ... but when re.compile() is used this way, I _think_ it is compiled each time the enclosing function is called. Is it not better to have code like this:

    volumeRe = re.compile( ....
    def calcVolume(new, old):
         volumeRd.match(...

While we're discussing regular expressions ... I have to ask what does r'(?P<mn>[ofpm]+)$' do? :)

Yes, you can take the re.compile out of the subroutine since its content is static.

The patterns consists of two parts, concatenated by '|' . So either the first part matches, or the second part, or nothing.

If the first part matches, group 'val' gets a value, and maybe 'pre' and 'post'.

If the second part matches, group 'mn' gets a value.

As you may guess, r'(?P<mn>[ofpm]+)' specifies a regex that matches any sequence of o f p m (which covers all valid mnemonics, and more). If it matches, match group 'mn' gets the value of what was matched.

The final '$' means that the pattern is to extend to the end of the string, i.e., must match the string completely from start to end. Note that the '$' applies to the whole rexegp, not just to the second part. Using parentheses for clarity the pattern is ( first | second ) $ , not ( first | second $ ) .

HTH

Thanks for the lesson :)

I will take the re.compile out of the function. I'm sure that if we compile a million or so songs this will make a marked difference :)

Did a mass compile of my existing songs ... and the first thing I have noticed is that the patch doesn't like uppercase volume names. I think that, since most things in MMA are case insensitive, there is no reason not to accept both "F" and "f", etc. You?

Might be easiest just to add a line to the top of the function: new = new.upper() and change the regex. That way we can dump the other conversion as well.

While I have never seen a music score with MP or FFF, the fix is easy: add re.IGNORECASE as second arg to the re.compile:

volumepat = re.compile(
                       # opt. +/-, numeric value, opt. %
                       r'(?P<pre>[-+])?(?P<val>[\d.]+)(?P<post>%)?'
                       + '|' +
                       # mnemonic
                       r'(?P<mn>[ofpm]+)$',
                       re.IGNORECASE )

Reason for upper or lower case for symbolic values is just because we are trying to keep MMA case insensitive.

Note, also, that more than one symbolic value is not standard music: 'off' and 'm'.

Problem/error with the code is that it accepts things like '80+20%' but doesn't do anything with it ... accepts it as 80. 'FF-20%' is flagged as an error. Can you fix that.

I have gone though my 1000+ files can fixed all the volume settings without the % signs. Damn, I didn't know there were so many :) Working on the docs right now.

Best,

Sure.

volumepat = re.compile(
                       # opt. +/-, numeric value, opt. %
                       r'(?P<pre>[-+])?(?P<val>[\d.]+)(?P<post>%)?$'
                       + '|' +
                       # mnemonic
                       r'(?P<mn>[ofpm]+)$',
                       re.IGNORECASE )

Great. We're having nice cold weather here (-10c) ... great time to have a nice fire in the stove and cuddle up with the .re reference :)

The new version works like a dream. Thanks.