note overlapping in pattern joint

[vervethe]

2 pattern join
--------
set 0001   4 4+1 90 ; //here is a existing pattern
set 0010   3 4 90 ;
aria riff $0001
aria riff $0010    // overlap at beat 3 to bar end
C
G
--------
at bar 2 , the note remained from bar 1 is on , 2 pattern's notes overlap. it's not good in generating single tone melody.

  solution 1 :
aria riff 4 4+2 90 ;  //writing new pattern 4 4+2 90 ;   , take away overlapping .
aria riff $0010    
//but,not flexible, waste a lot of time in writing similar patterns

  solution 2 :
aria riff $0001
aria riff $0010    
C
aria cut 2.9  // stop all notes before beat 3 , take away overlapping .
G
//but,not flexible,not simple, waste time in writing cut command .
//and when using random pattern selection ( seqrnd ), it is not known where to insert cut command.




is possible to enhance  overlapping notes processing without writing new pattern or cut command?

suppose , add  "overlaping" option :
aria overlaping cutprev  // the notes remained from previous bar is cut by the notes at current bar
aria overlaping cutnew  // the notes at current bar is cut by the notes remained from previous bar
aria overlaping overlap // keep overlaping ( default )
aria overlaping random //randomizing: cutprev or cutnew
aria overlaping velcut  //velocity compare between the last note remained from previous bar pattern and the first note at current bar pattern ,the smaller is cut by the greater .


suppose ,
--------
aria overlaping cutprev
set 0001   4 4+1 90 ; //existing pattern "4 4+1 90 ;" is commonly used . no need to write "4 4+2 90 ;"
set 0010   3 4 90 ;
aria riff $0001
aria riff $0010  //the note remained from previous bar automatically stop at beat 3 (it's cut by the note at beat 3)
C                      //no need to write cut command , simple and clear!
G
--------

[bvdp]

I think I understand the problem....

But, it's more complicated What happens with the actual note duration is that it is determined by:

 - the duration set in the pattern,
 - the value of articulate (by default it's set to 70% of the requested length),
 - the value of rtime, which moves the start of the note around

What I think you are requesting is a command to stop a note when a pattern overlaps. You show this in your first solution. Simple.

But, you want to specify start points (offsets) and forget about the duration ... just let the note sound until the next pattern starts a new note. In many ways, the Plectrum tracks work that way.

So, if we were to extend the Aria pattern (and others as well?) to permit this ... the questions are:

 - does it apply only to a single note, or all notes in a chord (and don't forget harmony as well)?
 - does it apply to the new offset (start point), or do we back up and make the note in the pattern being stopped a set value?
 - what happens with a pattern like:

        aria set  foo  1 2 90; 2 2. 90; 4 4 90;

when the pattern has overlapping notes inside a bar? Or are you suggesting that the option only applies on barlines?

 - would this apply to all track types or only arias?

 - Riffs only, or patterns as well?

Hey, probably more questions from me that you wanted But, I think it's a good topic!

Just a minor point, but why are you using riffs rather than defining a pattern? Riffs are designed as a "one off" thing, to replace a pattern.

Look forward to more on this,

Bob.

[bvdp]

Just occurred to me that there is another situation where you idea would be useful. Take this simple example of a sustained chord (think background strings):

Begin Chord-Sus
    Voice strings
     Articulate 100
     Unify On
     Sequence 1 2 90; 3 2 90;
End

Variations of this are used in the library. If the chords change on 1 and 3, all is fine. But, if a chord changes on 2 or 4 (or on a part beat), it gets ignored until the next 1 or 3 beat.

I'm not sure if your idea and this are related ... but it would be nice to be above to have pattern which changes on chord changes. So, in the above you could simply have a pattern:

     sequence 1 1 90;

and, in the following chord lines, have the appropriate changes:

    C G7 C Dm   /// change the notes 4x
    C                  /// one long chord

However, I don't see a way to do this right now. MMA goes though and generates midi data for every point in the pattern, not in the chord. So, with "1 1 90" it only does this once and grabs the C chord. If the pattern is "1 2 90; 3 2 90" it does it at beats 1 and 3 ... it never looks at what is happening at beat 2 or 4.

Just thinking out loud, I'm wondering if a special pattern control (lets call it "dynamic") could look at a chord line, see where the chords change (in the above it'd be 1,2,3,4 and 1) and then take a pattern like "1 1 90" and expand the pattern out? And if that is possible, would it solve the OPs problem?

I've got to do some other stuff around here (not computer related), but I'm going to think about it.

Comments?

[alexis]

Hi all,

The issue you're dealing with here reminds me this post : http://www.kara-moon.com/forum/index.php?topic=6748.0
This was about how we can handle harmonic rhythm changes in MMA. I think this is roughly the same issue, but described differently.

With your "dynamic pattern control", my "harmonic rhythm" issue could be mostly solved at the same time.

Just a thought.

Alexis

[bvdp]

Yes. I was thinking of you, Alexis, when I penned that

I don't think it will be a global solution, but might be quite cool in several situations. Mostly when we have "long" patterns.

As always, it seems that the syntax of it all is a bigger issue that the code. But, right now I see 2 possible ways to get this working:

 1. Have a new keyword (Dynamic, or whatever ... doesn't really matter). If encountered (and this is a track thing), it would create a pattern based on the existing pattern. So, you might have something like:

  chord-sus Sequence  1 1 0 90 0 90 0;
  Chord-sus dynamic

or

 2. chord-sus Dynamic Sequence ....

or

  3. chord-sus sequence dynamic 1 1 0 90 0 ....

(I think I like (3) ... no new keywords in the jump tables).

In all cases, this sets a flag. Now, when we come to the code which generates a bar of midi date we can create a pattern on-the-fly. So, with a chord line:

    C D C D

a sequence like "1 1 90" will become "1 4 90; 2 4 90; ..."

And, the chord line:

   C D@3.5

would generate "1 2.5 90; 3.5 1.5 90".

I have to gel this idea for a bit. For chords, it's fairly easy But, what if the original sequence is "1 2 90; 3 2 70" (the writer wants a quieter chord for the 2nd half of the bar). MMA will have to some intelligent guessing to figure it out? Or just restrict to full measure patterns?

And what happens with bass, walk, etc. tracks? Guess we could write code for one track at a time as see how it goes.

I've got a few other things I'm working on right now: I want to finish off some code for grace notes in solo tracks (it's mostly working); pitch bend support (mostly working) and a command to add arbitrary code to the start of a track when it's created (no code written at all). A new beta will be released, hopefully this year, and then we can start to look at this issue a bit more seriously.

More thoughts on this will be appreciated! Keep the ideas coming.
 

   

[alexis]

Yes. I was thinking of you, Alexis, when I penned that

I'm flattered you thought of me!

1. Have a new keyword (Dynamic, or whatever ... doesn't really matter). If encountered (and this is a track thing), it would create a pattern based on the existing pattern. So, you might have something like:

  chord-sus Sequence  1 1 0 90 0 90 0;
  Chord-sus dynamicMore thoughts on this will be appreciated! Keep the ideas coming.

or

 2. chord-sus Dynamic Sequence ....

or

  3. chord-sus sequence dynamic 1 1 0 90 0 ....

I think, dynamic should be... dynamically disabled, so, I would suggest this syntax:
Chord-sus dynamic on
Chord-sus dynamic off

I have to gel this idea for a bit. For chords, it's fairly easy But, what if the original sequence is "1 2 90; 3 2 70" (the writer wants a quieter chord for the 2nd half of the bar). MMA will have to some intelligent guessing to figure it out? Or just restrict to full measure patterns?

Don't know yet...

And what happens with bass, walk, etc. tracks? Guess we could write code for one track at a time as see how it goes.

AFAIK, it should be easy to generalize to bass tracks, too. Let's try chord tracks as a start.

I've got a few other things I'm working on right now: I want to finish off some code for grace notes in solo tracks (it's mostly working); pitch bend support (mostly working) and a command to add arbitrary code to the start of a track when it's created (no code written at all). A new beta will be released, hopefully this year, and then we can start to look at this issue a bit more seriously.

OK, great!

Alexis

[bvdp]

Just a heads up ... I've started writing a bit of code for this. I have the structure set and it's just a matter of doing the actual generators. Here's the scoop:

1. A new command "AutoPattern". For now, it's "on" or "off" (defaults to off). It's saved in grooves and can be different for each bar in the sequence.

2. If "auto" is set, when a bar is processed we generate a different pattern based on the current one.

Now, things get tricky and I have to put on my thinking cap! Each track type has a new function to generate this on-the-fly pattern. I'm concentrating on Chord right now and the idea is that the new pattern will:

 - have start offsets and durations based on the placement of the chord changes.
 - have volumes based on the current pattern (when figuring this out, I just take the volumes out of the existing pattern which would be used at the new offset).

So, in rough terms, if the existing pattern was:

    Chord Sequence {1 1 90}

and the chord pattern was

    C / D /

the new pattern would be

    1 2 90;3 2 90

In the next bar, assuming a chord pattern of

    C D E F

the pattern would become:

    1 4 90 ; 2 4  90 ; 3 4 90} ; 4 4 90

If anyone has more thoughts on this, let me know as soon as possible.

And, a great new season to all!

[bvdp]

Okay guys (and gals). I've been playing with this feature for awhile now ... and the sad news is that I think it's just plain dumb. Of course, it could well be that it's me that's dumb ... or I just don't understand the problem.

First off, here's what I've cooked up. A new command "autopattern" which can be toggled on/off. The idea is that instead of the predefined sequence (defined in a groove) being used MMA figures out a suitable pattern based on the location of the chord changes. So, if you have a chord line like:

    Am   /   B7+  B7

the sequence generated is:

    1 2 90;   3 4 90;  4 4 90;

Note how we skip over the 2nd slot since it's not a chord change, just a placeholder. Also, being a clever guy, MMA takes the volume lists from the existing groove and copies that for the auto created one.

And it works for triplets and changes off-the-beat.

But, I think it's just total BS to be trying to do this. What you are asking is that MMA figure out a sequence based on chord patterns ... and music just doesn't work that way. Play the same piece with different people (or the same people on  different nights) and you'll get chord changes at different spots ... does that mean patterns should change as well? (An argument could be made for pattern changes just to keep life not-boring, but that is a different thing completely.)

Now, it's probably my fault for not writing a good enough tutorial/manual ... but this kind of stuff is so easy to do in MMA already!

If you want to change a sequence for a single bar, just use a RIFF. To duplicate the above example:

    Chord Riff  C134

Should work just fine. Or, if you want to avoid the predefined patterns, roll one up. Not a big deal?

Plus, if you "sort of" like a groove, but want minor changes:

 1. Use the AllGrooves command to change things like voicing, etc.

 2.  Make major changes at the top of a song file:

Groove Foo
   Begin Chord
      ....
    End
DefGroove Foo

Now you have a new "foo" groove which is useable in your song.

3. Create a new file completely and put it in your local library. Feel free to copy (or just include!) the ones from the stdlib and modify.

Now, if I'm totally misunderstanding all this ... feel free to put me on the true road. But, for now I think I'm going to dump "autopattern".