Monday, December 31, 2018

MMA 16.06.c ... get it now

This is the last 16.06 that will be posted. Next month I will be releasing 19.01. So there!

In the meantime could you please grab this version and test it out. Let me know if there are any bugs. Enhancements will be put in a queue and probably not addressed until the next cycle.

Get it at:

    https://mellowood.ca/mma/downloads.html#developer

And to all ... have a great new year!

Monday, December 24, 2018

Happy Holidays, Christmas, music and MMA

Hope all of you are having a great holiday break!

This can be a pretty wonderful time of year ... make time to enjoy it all. Especially time with family and loved ones.

I've had a lot of fun the last little while playing some accordion (yeah, my first instrument) and did a nice gig at a seniors home yesterday with some fellow musicians. Turned out great.

In the MMA department, I'm still hacking away at it. I'm hoping to get a new release out shortly. Just not decided if it'll be the last ever 18.xx or the first ever 19.xx. Stay tuned. And, I'm getting more and more excited about using plugins to expand MMA instead of expanding the core ... again, stand by for more details.

Best to all,

Bob.

Monday, July 23, 2018

Truncate

I just found a minor bug in the TRUNCATE code. It didn't accept an integer argument for the Side= option. The underlying code all worked, but the test to see if the argument was legit was wrong. Fixed.

While looking at this, I wondered if we could expand the code and permit the lengthening of a bar ... for example, I had a song in 4/4 time which had a couple of 5/4 bars. I had been using Truncate to generate a 1/4 bar, followed by a 4/4 to create it.

Well, the short story is that I can't really figure out how to do it and make it useful. Here are some of the problems I ran into:
  • Expanding to a single multiple (4/4 to 8/4) isn't too bad. But, if the code is to be robust, it should work for goofy stuff like 10/4 as well. I could limit to doubling, but read on.
  • When selecting which patterns to re-create and move into the new slots it becomes difficult to decide which ones to use. A facile implementation might take (for my 4/4 to 5/4 case) patterns in the first beat and copy them to the fifth .... and this is the exact opposite of using Truncate with a 1/4, 4/4 pattern. So, should we copy an existing sequence and insert at the left? Insert what?
  • It becomes even sillier when patterns not-on-the-beat are involved.  

 So, unless someone smarter than me can come up with a algorithm for this, I'm going to continue to suggest "use a single short bar followed by a long one" advice.

Got a great idea? Let me know.

Tuesday, April 24, 2018

Mea Culpa

Isn't it just plain annoying when you end up wasting most of an afternoon trying to find a bug in your code when there is no bug? Just happened to me ... and the really annoying part is that I've don't something very similar in the past! Guess we don't always learn from past mistakes?

I was trying to import a MIDI file into a MMA file using MidiInc and a START offset. At first it all seemed to work just fine, but the imported stuff was starting at the wrong point. How come?

The funny thing is that if I didn't use the offset and had the creator of the Midi file adjust things to what I needed, it worked.

Well, to make a long story short enough to blog about:
  • I have a .mmarc file which initializes my keyboard to a known state,
  • The initialize includes a "beatadjust 1" after doing a bunch of ChannelInits,
  •  I, next, imported the MMA generated Midi file into graphical notation programs.
Are you seeing the problem? Things are out of sync! Bar lines are in the wrong location!

But, I'd forgotten about the initialization and figured it was deeply buried bug in my beautiful MMA code. The upside is that I did find a bug when using a START offset, and that is now fixed.

The solution was pretty simple: In my directory which had the test MMA and Midi files in it I just created an empty file called "mmarc". And all worked. Maybe I've created too many options? Too late to change it all now....

Hey, if there are no bugs we'd never have to do new releases!





Friday, March 30, 2018

French Translation

Christian, one of our French speaking users, has been busy the last while translating the MMA manual to his native language. And, in true open source style, is sharing his work with all of us. 

It is free to download from his archive at:

    http://linuxmao.org//tiki-list_file_gallery.php?galleryId=29 

Christian is asking for you help. If you can do some proof reading it would be a great help. Please contact him directly via: cg.clarinette35@laposte.net

Tuesday, March 20, 2018

MMA is over 15 years old

I was just looking at some files and noticed that the first beta release of MMA was posted in February 2003. That means that we missed celebrating the birthday of our adolescent program.  But, considering that this is the first day or spring, please raise a glass of your favorite fruit wine to our friend.

Friday, March 9, 2018

New developer version 16.06.b available

Harmonies are done! And a new developer version is now available. Get it at:

    https://mellowood.ca/mma/downloads.html#developer

The biggest change is the addition of interval harmonies. These can be quite useful, but be careful ... they can be quite ugly as well.

I've changed the syntax a bit from the discussions here by forcing all interval harmonies to include a single ":" in their name. See the fine documentation for details.

In addition, there are a number of bug fixes (as always) and a number of documentation improvements.

Have fun. And don't forget to let me know if any of this is useful, your suggestions for improvement, neat grooves you have written, and any bugs you might find.

Saturday, March 3, 2018

Harmony, revisited

One of these days I will learn to leave things alone :) But what would the fun in that be?

I have dumped the Perfect4 harmony out.

And replaced it with a comprehensive set of interval harmonies. So, now, in addition to the OpenAbove, etc. chord based harmonies that have been in MMA just about forever, we now have an interval notation:

      S[octave]Interval

The octave modifier can be any value between -4 and 4.

The interval can be any of Unison, MinorSecond ... PerfectFourth ... etc. And, of course, these can be shorten to Min2 ... Per4, etc.

The leading S is supposed to signify that this is an interval, not chord based. I'm not sure I like S, but using an I is just ugly and confusing with the digit 1. So, I'm suggesting S for "scalar".

I think I might also include a "C" option: just indicate the exact number of half steps to use. Again, I'm not sure about "C" since someone might think that it means "chord". Hmmm, maybe "H" for halfsteps?

I've run a few tests and the harmonies generated this way really don't sound as bad as I thought they would ... some, of course, are awful. But, some are quite pleasing.

A beta release is coming soon. Promise :)

Wednesday, February 28, 2018

CopyTo is gone ...

Got COPYTO all working and even wrote up some docs.

But, then I decided that we really didn't need yet-another-command! So, it's gone.

But, don't despair. The functionality is still there. Instead of a new command COPY has been enhanced with a TO keyword. And, to keep things consistent, a redundant FROM keyword as well. So, now we have:

    Track Copy Other-track   ... copies Other-track over Track
    Track Copy From Other-track ... same
    Track Copy To Other-track   ... copies Track over Other-track

And, my tests here in Western Canada (where the snow just never seems to end) indicate that it all works.

Back to the documentation cellar when the whips and chains await. Standby for the announcement of a new beta!

Saturday, February 24, 2018

Harmony works ... and a new command


I've done a bit of testing with the perfect-4 harmonies. Delightful!

And, today, I added a COPYTO command. This is the reverse of COPY and will be quite useful, especially in Begin/End blocks.So, now when creating a track, you can duplicate it at ease. For example:

   Begin Chord
      Octave 5
      Articulate 80
      .... lots more stuff
      Copyto Chord-Quiet
   End

And, alas, Chord and Chord-Quiet will be identical. Now, make some mods to Chord-Quiet and we're off to the races. And, yes, in case you are reading along with the manual in hand, you could have done the same previously by doing:

    Chord-Quiet Copy Chord

But, that is outside of the begin/end block and just looks awkward.

I'll be putting up a beta copy (16.6.b) on the website later this week. Just gotta find some time to finish the docs ... I'm really too damned busy for an old retired fellow these days. Between a few music students, my sax/piano/voice duet, a sax trio, community band, and pit orchestra for a amateur musical ... well, you get the idea. Life is grand!



Sunday, February 18, 2018

Perfect fourths, part 2

I've been doing a bit more study and it's finally gelled in my little mind: There is a difference between a fourth and a perfect fourth! And for harmony we really need to look at PERFECT FOURTHs ... and these are easy. Just a matter of adding 5 semitones. This achieves a very "modern" feel and (for a computer program like MMA) is very easy to figure out.

So, over the next few days I'll add this as a additional harmony option.

Saturday, February 17, 2018

We're secure now

Different browsers as well as Google are really promoting the idea that ALL websites should be "secure". Typically, this means that a little lock will show up in the address bar of your browser.

So, all my pages at www.mellowood.ca now show the lock.

It means that you can rest assure that the transmission between my host (currently I use  http://namecheap.com/?aff=100587 is not scrambled or hijacked. Well, probably. But, really, it's not that important since I don't have any forms on the site asking for your private information, etc.

But, this should keep Google happy for a day or so. Especially since I also made the site "mobile friendly". What's next?

Friday, February 16, 2018

Harmonizing in 4ths

I've been wondering about adding some additional harmonizations to MMA. But, I'm really pretty much stuck ... so, help :)

Right now MMA does pretty simple harmonizations based on the current chord. As a simple example, if you have a C major chord and a G note MMA will pick a C or E (or both) for harmony. It's a bit more complicated since MMA has a concept of "open" and "close" harmony and "above" and "below". But, it's not very complicated.

Now, if we look at harmonizing on fourths life gets more complicated (and fun). This doesn't rely on chords, but, rather, on scales. MMA has a scale attached to each and every chord, so it should be simple? Not so much.

A simple harmonization in 4th might start off like this:

  • We have a C major chord
  • Associated with this scale is a C major scale (c,d,e,f,g,a,b)
Now, for a melody note 'F' we'd probably add in a 'B' harmony note. Why 'B'? Because it's 4 degrees away from the 'F'. And if the melody note is 'A', we'd use 'D' (scales just wrap around).

Getting a bit more complex, if the chord was a C7, then associated scale would have a 'Bb' note. So, for a melody note 'F' we'd pull a 'Bb' out for the harmony.

For MMA to do this, the harmonization function would need to know the scale as well as the chord. Not a problem.

Now, what if the melody note is not in the scale? Assuming the same C major chord and scale, what would you do with a 'F#' note? Well, I don't know either. Here are some of the decisions MMA would need to make:

  • Is the note a F# or is it a Gb? And the routine really can't tell since it's being passed a MIDI value. And the MIDI values for the two notes are the same. We might be able to make our guess more educated by looking at the key signature, but that will probably not be much help.
  • Since the note is not in the scale, we'd have to guess at the harmony. We might be safe is grabbing a value below (in this case F) and doing the harmony based on that. Or, should we use the 'G' to use as a count base? 
  • One option is to not generate a harmony note at all if the note isn't in the scale. But then you'll end up with harmonic "holes". 
  • Choosing the wrong base note will generate harmonies which aren't correct.
One solution for the writer of a melody is to stick in the desired note manually (in SOLO tracks harmonies aren't generated if there is more than a single note at a position). But, harmonies are also used in BASS, ARPEGGIO, and other tracks; and, you can't stick notes in there.

So, I've got a few choices: 
  • Just leave well enough alone;
  • Get some really cool advise from users;
  • Make arbitrary decisions which might be wrong.
Not sure what to do just now. Helpful suggestions will be appreciated.
Leave a comment here or shoot me an email.

Friday, February 9, 2018

Everything is so fast

I just noticed that I've not posted here for way too long! Sorry, but life does seem to eat up time.

I've been wondering lately if it'd be worthwhile to do some major modifications to MMA to permit multiple files on the command line. In the back of my mind a little voice was saying that it'd run faster if we only did the python initialization stuff once.

Well, time to test it! And, the little voice was right. But, to such a small degree that I've decided that the added complications really aren't going to be worthwhile.

My test was simple: I surrounded the call to the main parser and MIDI generators with timer. Then, I ran MMA from the command a number of times with different sized files using the Linux time command.

The result? Most files took a total of about a tenth of a second to read, process and compile (my range was 0.080 to 0.188 seconds). Not very long. And, the time to initialize seems to be around 0.050 seconds. So, on a large source file we might reduce the total processing time from 0.200 seconds to 0.150 seconds. And, this saving was applied to, say, 100 files we'd save a grand total of 5 seconds.

I just did a test of my personal files. 1171 MMA files compile on my computer (Intel I5-4570 @ 3.20Ghz) in 2:35 minutes. About .132 per file. And, if we applied the 0.05 saving to each file we'd save less than a minute. Actually, much less since there would be more processing time in parsing the very long command line and resetting all of the necessary variables, clearing out memory, etc.

I think we just wasted more time just doing/reading this blog than we'd ever save. If you need to process files more quickly just get a faster CPU.

So, unless someone presents a compelling reason to change MMA's "one file at a time" behavior I am going to leave this idea alone.




 I've been pretty neglectful in keeping this blog up-to-date. Lots of excuses ... but, I'll try to do a bit better! There is a new b...