< Back to IRCAM Forum

A question about generating irrational time signatures

Hello everyone,

I’m working with a voice (imported MIDI from a Bach chorale) in 4/4 time signature that I’ve chopped into various irregular time signatures using tree2ratio -> mktree with a sequence of new time signatures.

Everything was going well until I decided to change the denominators of the time signatures to multiples of 3 or 5, creating these so called irrational time signatures. I expected this process to preserve the rhythmic figures while simply altering the tempo for the duration of each measure. However, the result was not as expected:

As you can see, there’s no apparent tempo change. Is there a way to achieve what I want? I’m aiming for an effect similar to using the pulsemaker function with different denominators. I hope I’ve explained myself clearly. Thank you in advance for any tips or suggestions!

1 Like

Hi zeracosaitam1,

can you please provide the patch?


Hello Karim! Sure, here you go:

bach manipulation.omp (1.9 MB)

Dear zreacosaitam1,

I don’t understand the result of your measure changes? Can you explain.

The patch:
bach manipulation 2.omp (2.1 MB)

Another bothering thing, is in the fragmentation function (red patch), you have a big big code inside, so it takes a lot of time to output a result. One advice, break your code into small pieces, first it becomes more clear, then you will gain some calculation speed.


Hi Karim,

Yes, the measures change because of the added silences within the fragmentation patch (the idea was to have added silences, in fact currently they have to be tied notes or the patch breaks i don’t know why). I implemented this in-between asking you the original question, so it adds some confusion—sorry about that. The idea was to add a degree of separation between each measure’s repetition (à la Bernhard Lang). Thus, somewhere inside the patch, the original measure value (defined by the two lists outside the patch) is merged with the value of the added silence to form a new time signature.

I didn’t know that not abstracting sections of patches impacted performance. I thought it was just a visual thing. I think I got used to big patches in part because I find it annoying to debug omloop patches since you can’t evaluate inside them (that’s why I’m currently obsessed with ‘mapcar’ :face_with_hand_over_mouth:). I always thought my patches were so slow because of my old computer :sweat_smile:.

Will have all of this in mind as I continue. Your solution works great, thank you very much!