Printable View
I'm not able to fully understand the logic of how empty cells end up specifying chord durations, especially in odd time signatures. For example, in Take Five (5/4) section A, both Ebm and Bbm7 are followed by a single blank cell, but somehow the player translates this to Ebm playing for 3 beats and Bbm7 for 2. How does that work? What if I wanted to play Ebm for 2 beats and Bbm7 for 3?
An authoritative and comprehensive documentation of the beat scheduling logic would be great!
It's just the way the rhythm patterns are designed for each styles.
The only way to play a 5/4 as 2 beats for one chord and 3 beats for the other, is to combine 2/4 and 3/4 time signatures.
It would be nice to have additional 5/4 or other odd meters that is split different ways
Thanks! I was able able to "reverse" Take Five by adding 2 empty cells after Bbm7, as per this sheet.
But some experiments with 7/4 went wrong, whereby the player would get confused and end up playing out of time. I understand these are pathological cases, but it does point to some inherent ambiguity with the way iReal Pro deals with cells vs measures. That's why I am wondering about an offical description of the scheduling logic.
For what it's worth, I'm writing a iReal-to-MusicXML converter (that has different features than the app-provided one) and I am attempting to guess the beat scheduling algorithm.
When I first made iReal Pro it was only meant for notating chord charts. I came up with the cell structure (16 cell per line) and you could use those cells as you pleased, meaning a measure could be 2,3,4....16 cells long.
When a few years later, I added the player function we already had the forums and thousands of songs posted so the player had to work with most charts, no matter how many cells were in each measure.
This is easy when you have 1 chord per measure but any more than that and it can become quite difficult to make a decision.
I used a large number of example songs to try and solve the most common scenarios like 3 chords in a 4/4 measure can be 1 + 1 + 2 beats or 1 + 2 +1 or 2 + 1 + 1.
Resolving this is simple if the measure occupies 4 cells but what if it occupies 5 cells?
My solution was to do some simple math and assign a percentage of the measure occupied by each chord plus any following empty cells.
With these percentages in hand and some simple heuristics I can figure out which of the three possible combinations matches most closely.This example is for 4/4 with three chords. For 4/4 with two chord there are other three different options 2 + 2, 1 + 3, 3 + 1 and this requires all the same steps.
For longer time signatures like 5/4, 6/4, 7/4 the possibilities of combining 2, 3, 4, 5... chords per measure are very numerous so you can see how complicated it gets.
A log of repetitive code was necessary and it still fall over sometimes with very weird charts.
As for 5/4 and why it plays in 3 + 2, the simple answer is that most of the time that's how musicians play it so by defaulting to 3 + 2 I safely cover most of the situations.
This interpretation is not style based, it applies to all styles in the app.
A large majority of iReal Pro charts is written with 4 cell measures and users can easily change a song from 4/4 to 5/4 by only changing a single time signature at the beginning of the song and I wanted to have a reasonable default for this common case.
I can't really change the algorithm to look for when a particular case might mean 2 + 3 because it would result in too many false positives.
The only solution I can think of is to provide some way to indicate in the song chart itself a choice of how the longer meters (5/4, 7/4, 9/4) should be divided.
Being this a fairly obscure feature I wouldn't want to sacrifice any more space in the already crowded editor and further complicate its use for non power users.
On the other hand if it's hidden behind too many menus or even worse, if it requires some magic text or code only discoverable after reading documentation, it would never get used.
I have to think about all this.
Thanks Massimo for taking the time to reply and congratulations on creating an amazingly useful application!
I have written an iReal Pro to MusicXML converter, and I had to "reverse-engineer" the chord scheduler to account for the cases I'm looking at. I ended up writing a simple algorithm that uses the spaces as hints for extending or shortening the chord durations. It's working pretty well, including on some exotic experiments I made.
Very clever work.
How does your MusicXML output differ from the one generated by the app?
> Very clever work.
Thanks!
> How does your MusicXML output differ from the one generated by the app?
Comparing them manually, they are pretty similar in terms of music output, but here are some differences, from the side of my module:
- It is XSD-compliant with MusicXML 3.1
- It generates `measure-style/slash` which indicates that all measures should use rhythmic slash notation
- It distinguishes between "Coda" and "To coda"
- It is batchable and can run on a headless backend or in a browser
Happy to collaborate on anything you might find useful!
Thanks, will keep it in mind.
And another iRealPro deobfuscator hits the net...
Indeed, but what can I do at this point? Cat's out of the bag.
Sorry if I stepped in a sensitive area, but I mean no disrespect nor even competition. I am just pointing to how things can be done better.
In any case, I forgot to mention that the app's MusicXML export also messes up Take Five, by creating measures that are 6 beats long.
Thanks for pointing that out. I'll look into it and see if I can update to the latest MusicXML specs at the same time.