Michal, I’m glad you caught on my OMPitchfield reference, it’s a great OM library. Just in case, I have attached a Reference manual for OMPitchfield 2.0, its latest version. I hope it’s useful.
OMPitchField 2.0.pdf (167.8 KB)
Hi.
At any rate, coming back to my original question: quantizing and concatting polys…
Could you send an as simple as possible example which breaks?
Or even better, one example of a concat of 2 multi-seqs which does not work, and another of a quantification which gets messed up. Thanks.
If anyone else is reading this thread i’d be interested in patches using omquantify (explicitly or implicitly, like in conversions to voice/poly), where parallell voices get skewed and separated from each other. This is most likely because of a bug. I have reasons to beleive i’ve got a fix, but need more testing before pushing.
-anders
Hi Anders,
I am at disposal for some testing, but, please, I am not sure I have exactly understood the question, can you give me some example or supplementary explanation?
Ciao
Fabio
Hi Fabio, thanks for being willing to help.
The problem is that omquantify doesn’t always return a complete final measure, as can be seen for instance in OM-tutorial 27, or the examples presentd here, where despite the asked for measures all being (4 4) or (4 8), omquantify may return a shortened measure as the final one.
This yields troubles where parallell voices are concatenated, as in two or more polys, where if one voice has a different measure than the parallell measure in the other voice (because of the error above), they get skewed in the output.
Wow, what a horrible attempt at an explanation! But check the attached patch for an example which hopefully can iluminate.
I’ve got a fix which seems to work without introducing other errors. But since omquantify is so pervasive in OM, it’d be nice to test as much as possible before plunging a new version in. Thanks again!
-anders
test concat polys 2.omp (63.8 KB)
Just to try to be less confusing, it would be very helpful if you had some examples which break with the current omquantify… 
Hi,
I have downloaded your patch, and if I evaluate last poly object the result shows some different tempos in different voices (for example 3/4 and 4/4) and final incomplete (opened, to say) measures. I enclose a screenshot.
I had tried to resolve om-quantify bug adding a 0 duration at the end, or a very long negative (pause) number. So doing sometimes you had a final closed bar. Anyhow, this has been a difficulty I had to resolve also in programming my library. I enclose a second screenshot from a my library example. Here I add a 0 duration, the result is correct if you eliminate last 3/4 measure…
Ciao
Fabio
Hi Fabio, thanks for the feedback. Could you please check your library code after evaluating this code, and see if it behaves as you would expect?fix-for-quantification.lisp (4.4 KB)
Hi Anders,
I apologize for my question: please, tell me if I have adopted the right procedure. I am not sure about how evaluate your code… sorry.
I have put your ‘fix-for-quantification.lisp’ file into my workspace, both into workspace folder and then into user folder, but the result is always the same (‘opened’ bars wrong musical notation). Then I have tried to evaluate your code inside a new buffer of a lisp editor, evaluated everything, but nothing changes.
I am testing on a Linux OM version. If necessary I can test on OsX, too.
Ciao
Fabio
Hi Fabio, thanks for testing.
To check if the fix is applied you can check with something like the attached screenshot. The returned measures should be a (4 4) measure with the tree (1 1 -2) in it, ie: (1 (((4 4) (1 1 -2))))
If instead you get (1 (((3 4) (1 1 -1)))) it means the patch isn’t applied.
If you get the first (correct) result, than there’s something else which is wrong. Which is good i guess, because it helps isolate bugs. In that case, perhaps you could provide a patch, and a link to the lib you’re referring to?
Thanks!
-anders
Hi Anders,
It runs: I have evaluated your example returning wrong result; then I have imported your fix in a new buffer and evaluated all your code; last I have re-evaluated your example obtaining correct result.
Ciao
Fabio
Hi Fabio. You mentioned you also had to do a workaround in a library you have programmed:
“…Anyhow, this has been a difficulty I had to resolve also in programming my library…”
does the proposed change to omquantify fix the issues you had with your library?
Just to try to be more precise, i’m looking for other examples which don’t work well, or need ad-hoc workarounds, using the current omquantify.
Hi Anders,
I have evaluated your code, but unfortunately it seems not to work in my library example. I enclose a screenshot. To obtain a ‘closed bar’ I must add a 0 to proportion sequence, and of course not to take in account last 3/4 bar.
Ciao
Fabio
Do you have a link to the library you’re referring to?
Hi,
Yes, I apologize for not giving it you. Here is:
https://sites.google.com/site/fdsdbmascagnienglishversion/code/fdsdb_xxth_ct-for-open-music
I have tested omquantize with simple durations like (250 250 500 1000), but the result is the same: I have to add a 0 at the end for closing the bar, even if a 3/4 supplementary measure is added.
Ciao
Fabio
Hi Fabio. Thanks for the link to the lib!
I’m a bit confused. The image you sent with the call on demultiplied-rhythms, with the proportions '(1 2 3) and total duration 8, returns the expected duration (8) for all 4 levels of ‘demultiplied rhythms’, no?
Oh, i see there’s another error/bug here, not always starting up a new measure when it should. Great, let’s find where this gets messed up.
Thanks for providing a nice test-suite with the demultiplied-rhythms function!
Hi Fabio. There was another bug lurking here, stopping before the required durations were ‘used’ - as in the left image, where it should instead return the total duration, with a rest-padded measure if necessary, as in the one on the right:
Could you please try with the attached code, and see if your use-cases are ok? Thanks!
-anders
fix-for-quantification_v2.lisp (4.3 KB)