< Back to IRCAM Forum

Issues with "onset" in chord-seq

Hello OM Hivemind,

I am trying to make a chord-seq (labeled 1) object in which the durations match the calculated onsets of the pitches (resulting in no rests in the downstream “VOICE” object, labeled 2). I thought this could be done with x->dx but it seems the calculated values aren’t correct. I attach the patch, and would appreciate any advice.

Thanks again for running this forum, I have found it to be tremendously helpful.

Brandon


fibrillator.omp (39.4 KB)

Dear Brandon,

Congrats, you just have found a bug :slight_smile:
Just use true-durations as such:

While i fix the bug. (it is the omquantify voice method which is not working as expected— M bad :frowning:

:slight_smile:
Best
K

Dear Brandon,

I reacted fast. Everything works normaly here on OM version 7.0:

How did you get this result? Are you loading some special libs?

Best
K

It seems that the chord-seq in your screenshot is not the same one that is in the attached patch. Maybe the reason of all this confusion…

Hi Karim,
Thanks for your help! I think I re-evaluated the chord-seq which is why its not the same as in the screenshot. I still have the same issue with true-durations (it just gives me negative numbers for the rests).
I am running OM 6.19, should probably upgrade.

Hi Karim,
I upgraded to OM 7.0 and I still have the same problem with rests. Here’s an updated screenshot.

To clarify, the duration bars in the CHORD-SEQ 4 should extend only to the onset of the next note, so that there is no rest in the CHORD-SEQ or corresponding voice object.
Thanks again for your help!

I’ll also attach the output from “sort-list” (first) and the output from “x->dx” (second), which really doesn’t make much sense.

Dear Brandon,

This is a typical case of incorrect patching:

  1. in your loop you have a om-random function. Meaning that this loop will be evaluated twice, since it is called twice by the chord-seq (once from the sort-list, another from the x->dx).
  2. the reason why the attached patch works and NOT your screenshot examples: the random is from 1 to 1 (in the patch) meaning no random

The solution:
Put the omloop in eval-once mode:

Screenshot_2022-09-24_09-32-08
Best
K

Hi Karim,

Wow, a slightly embarrassing oversight on my part!

Thanks again,
Brandon