Kara-Moon Forum
March 28, 2024, 12:44:41 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You can go back to the main site here: Kara-Moon site
 
   Home   Help Search Login Register  
Pages: 1 [2] 3
  Print  
Author Topic: Cresc / Decresc / Swell  (Read 13498 times)
sciurius
Sr. Member
****
Posts: 443



« Reply #15 on: December 24, 2019, 08:33:38 AM »

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.
Logged
sciurius
Sr. Member
****
Posts: 443



« Reply #16 on: December 24, 2019, 08:45:27 AM »

Quote
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 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.
Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #17 on: December 29, 2019, 04:24:55 PM »

I'm back and ready to get going on all things MMA Smiley 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.
Logged

My online life: http://www.mellowood.ca
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #18 on: January 03, 2020, 06:44:00 PM »

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 ...
Logged

My online life: http://www.mellowood.ca
sciurius
Sr. Member
****
Posts: 443



« Reply #19 on: January 03, 2020, 08:29:15 PM »

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.
Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #20 on: January 06, 2020, 12:34:40 AM »

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

Code:
if new[0] in "0123456789":
        if not adj:
            warning("Volume: A mnemonic value (M, P), not '%s', is recommended." % new)
        v = stof(new, "Volume expecting value, not '%s'" % new) / 100.
       

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

My online life: http://www.mellowood.ca
sciurius
Sr. Member
****
Posts: 443



« Reply #21 on: January 06, 2020, 12:40:42 PM »

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.
Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #22 on: January 07, 2020, 02:39:53 AM »

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 Smiley
Logged

My online life: http://www.mellowood.ca
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #23 on: January 09, 2020, 12:51:00 AM »

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 Smiley

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?
   

Logged

My online life: http://www.mellowood.ca
sciurius
Sr. Member
****
Posts: 443



« Reply #24 on: January 09, 2020, 08:53:38 AM »

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.

Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #25 on: January 09, 2020, 04:08:25 PM »

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.
Logged

My online life: http://www.mellowood.ca
sciurius
Sr. Member
****
Posts: 443



« Reply #26 on: January 10, 2020, 10:56:31 AM »

Sorry. Shouldn't have used the word 'weird'...
Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #27 on: January 10, 2020, 04:27:19 PM »

No problem Smiley

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

My online life: http://www.mellowood.ca
sciurius
Sr. Member
****
Posts: 443



« Reply #28 on: January 10, 2020, 09:04:14 PM »

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))

* calcVolume.py.txt (0.83 KB - downloaded 169 times.)
Logged
bvdp
Kara-Moon Master
****
Posts: 1436


WWW
« Reply #29 on: January 11, 2020, 02:22:13 AM »

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 Smiley 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!
Logged

My online life: http://www.mellowood.ca
Pages: 1 [2] 3
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.057 seconds with 20 queries.