OM - Merge unchanged notes

[gph]

Hi -

Does anyone know an efficient way to merge notes in a sequence when they are the same as the previous note?

For example, in this sequence attached - to merge the first 25 A’s, then merge the next 3 Aquartertone#, etc…

Thanks!

Graham

[haddad]

Dear Graham

Can you send us the chord-seq in question?
Best
K

[gph]

Hi Karim!

Here’s a chord-seq instance pulled from the list. Not the same one pictured in previous post.

Thanks for your help!

All the best,

Graham

CHORD-SEQ Example.omi (2.3 KB)

[haddad]

Dear Graham,

Here is a solution that applies to your chord-seq. However, please notice that there is an approximation factor since your chord-seq if approximated in 1/2 tone will have only one note. So use the optional input in order to filter your repeated notes as desired.

Another issue is in order to tie these notes one must “normalize” the chord-seq rendering it monophonic. If not all durations will be wrong.

Here is the code (to be put in init folder of OM, then restart OM):
chordseq-tie.lisp (933 Bytes)

Here is the patch:
Patch 2.omp (7.6 KB)

Hope this is what you where looking for.
Best
K

[gph]

Wow! Thank you Karim. You’re a legend as always!

That’s what I was trying to do exactly. I’ll now try to learn from your code so I can be better at this in the future.

Thanks again.

All the best,

Graham

[demey]

hello Graham The object chseq->poly ( Repmus library) should be appropriate … of course the approximation is crucial to connect equivalent midi cents notes ; I didn’t check what’s happening with the velocity … would it take the first , the strongest , the latest , an average ?
best Thierry DM

[haddad]

O yes! of course. Forgot about that. (Thank you demey)
While asking about velocities, my simple function takes into consideration the first occurring note velocity.

Best
K

[gph]

Aha! Thank you Thierry! That’s brilliant. Thank you for your help. Much appreciated.

[anders]

Arguably the solutions above are simpler and more directly to the point, but it’s tempting to use a perhaps more scary approach, modelling a real massacre!

Besides, generally when structure needs to be changed, as the list of chord-seqs here, recursive functions often come handy.

The example here is a recursive bloodbath, where each input chord is potentially a cannibal:

- if the next innocent trespasser (next one in the input list) shares
      the same bloodtype (here: same mc), it's swallowed with hair & hoof,
      the greedy cannibal growing as much fatter as the ldur of its prey,
      leaving no traces of its prey

- if not, it hangs itself up (consed onto output), passing the
      battlefield on to the next cannibal coming along (ie. the next input
      with different bloodtype), and the massacre goes on until there's
      nothing left to eat (ie. input is nil)

One possibly useful thing might be that such an algorithm easily can be adapted to other kinds of input, just changing the two helper-functions: #'same-bloodtype-p (check if yummy…), and #'cannibal (how to eat…) - possibly passed as ‘funcall-able’ lambda-functions to the main bloodbath scene.

main engine, “bloodbath”:

and the 2 helper functions:

same-bloodtype-p:

cannibal:

eat adjacent chords.omp (10.2 KB) bloodbath.omp (15.0 KB)

[haddad]

@anders, Love your analogies. Makes programing even more fun!
Thanx
K

[gph]

Whoa @anders ! That’s great. I love the bloodbath! Thanks!

[demey]

brillant Anders

• excuse this late answer -
  … the question how durations and velocities are been preserved is elegantly solved !
  véritablement un patch d’école ( to be studied ;-))

best
Thierry De Mey