After (more)

[sciurius]

Did you grab/process the right file? the first few lines of the file I posted read:

Aaargh! I had a file 'patch.txt' in my download location so this one was downloaded as 'patch(1).txt'... I just overlooked it.

124,125d123
<     stuff = []
<     elns = []
127c125,129
<     nn = gbl.barNum
---
>     barNum = gbl.barNum
>     # Gather all the AFTER events for this point
>     # in the MMA file into stuff[] for pushback

Works like a charm (but please post context diffs, they are easierand more safe to process).

[sciurius]

Yeah ... I suppose so ... but why? If you want to do it right away why not just do it? I'm confused

It makes automatic generation a tiny bit easier. And I like the symmetry.

But no big deal...

[bvdp]

I've been thinking about the BEFORE and looking at AFTER code. So, I have a few ideas ... before coding I'd love some feedback.

 1. Right now the way AFTER maintains it's stack is pretty dumb. It has a bunch of AFTER events in a list.

 2. When we see if there is a pending event we scan the list for matching time values,

 3. If any are found, they are processed, etc.

 4. Our list is maintained by parsing it again and deleting any events completed based on the timestamps. Lot's of stack recreates.

Above is simplified ... but, I'd like to suggest a few changes:

 1. Add a event-done flag to reduce the reliance on timestamps. When an event is processed, just toggle the flag.

 2. Don't recreate the list to often. I think that we could have a rebuild-needed flag in the module which signals that the stack is getting pretty dirty. Probably just base this on the number of event-done items and check this from time to time. Maybe if event-done > 50% of stack size?

 3. Add a option flag: place=[before, after] with after being the default (I don't like before/after, better word?).

 4. With place==after we do just like we do now, and ignore <before> events.

 5. Add a check at the start of <must be a chord to process> code in parse.py. This will check for place==before events and process them.

Nothing too dramatic here. But, let me think a bit more and do some coding later.

Thoughts?

[sciurius]

Ok, some thoughts...

Redesign the code only when it is required for maintentance and flexibility. Performance is not an issue for MMA.

Sorting the list on time values may be helpful. So you only need to inspect the first element and then apply (=pop) all elements with suitable timestamps.

An option flag place=[before/after] looks confusing to me. The command is already called After. Saying After ... place=before... reminds me of the stupid LOGOUT  /YES=NO command (I don't recall if this was on RSTS/E, RSX or VAX/VMS).

The need for Before disappears when execution of After would apply to chord statements only. For example:

Code:

After Count=1 Print Foo
  1  C
Print Bar
  2  D

This would print Bar Foo instead of Foo Bar, since the Print Bar statement does not contribute to the 'number of bars processed'.

Feasable? Or just insane?

[bvdp]

I've reworked the code a bit ... more to make it more clear to me than anything else And, a bit more future/feature proof. A diff is attached (with context!).

As to changing the check point ... could you try this (not tested here). Both are in parse.py:
   1. Out-comment the call to MMA.after.check() at line 113.
   2. Insert a call to MMA.after.check() at line 202 (right before "if action.isdigit....)

Now, it "should" only work before processing a chord line. I HAVE NOT TRIED THIS!

The problem is that it will never trigger after a chord line now

[bvdp]

Just noticed a minor bug ... the REMOVE option isn't working properly. Simple fix for tomorrow

[sciurius]

Patch applied and everything seems fine.

I haven't tried the check point change.

As for the progress from my side: I'm now quite successful at extracting percussion patterns from (arbitrary) MIDI files and turn this into MMA code. This code can use the Rhythm plugin, or be generated to use native MMA Sequences.
Patterns can be inserted before the chords, or all at once at the beginning using After statements.

I've attached examples for your amusement. All examples should sound identical. The patterns are extracted from a MIDI file generated by iRealPro.

See https://github.com/sciurius/mma-plugins/blob/master/rhythm/midi2mma.pl for the conversion program.

[bvdp]

The need for Before disappears when execution of After would apply to chord statements only. For example:

Moving the call around in parse would accomplish that. BUT, then if there was no chord, the command would not be run.  I think we may still need a BEFORE command (which I really don't like since it complicates a long list of main options and means a bit more code to keep consistent ... ) or, my preference, an option for AFTER. I think that it's more of an issue in coming up with an agreeable option name: AtChord=True (default false) or something? Then, in the main parse loop we'd just add a call when a chord was found. I will try that later and see what happens (it's a rainy day here).

[bvdp]

I went to the github page to grab the needed plugins. I'm being very dumb, maybe, today ... but  I see no way to download or sync it.

[sciurius]

I assume you want to download the Rhythm plugin?
https://github.com/sciurius/mma-plugins/blob/master/rhythm/plugin.py
Then click on [Raw]
Then use right-click Save Page As...

[sciurius]

BTW, the file 'native.mma' does not require the Rhythm plugin.

[bvdp]

I assume you want to download the Rhythm plugin?
https://github.com/sciurius/mma-plugins/blob/master/rhythm/plugin.py
Then click on [Raw]
Then use right-click Save Page As...

Of course Like I said ... dark gloomy day here

The samples you posted work just great! (Note: you do need to be running python3 for the plugin to work). Glad to see you are having a lot fun!

I did some quick work testing my idea about "before" and it'll get quite complicated quite fast. I think I'll leave it for now.

[sciurius]

Note: you do need to be running python3 for the plugin to work

Good catch. Actually it is good it crashed since it revealed another Python2 incompatibility, making the generated MIDI sound different for the python2 and python3 cases...

Fixed on Github.