Group Admins

  • Profile picture of Karim
  • Profile picture of Jean

OpenMusic

Public Group active 1 week, 4 days ago

User group for OpenMusic and computer-aided composition. Visit the Forum for discussions.

RQ Library buglist

Author 2 Subscribed Users |
Profile photo of ratox
ratox

Hello colleagues. I am getting back to work with the great quantification library RQ. I don’t know if Adrien Ycart is still there in the team but i hope so cause there are a couple of serious bug that ave popped out which makes very hard to work with the library, which is a pity because the concept is absolutely great and it’s able to realise exact quantifications and very interesting “creatives” one…. hope we can find a way to fix it.

I am using 3 intel mac with OsX 10.11.6, OM 6.12, the bugs are reproducible on all my computers:

The first bug, a graphic one: the red square in the low-left sub-window which should highlight the portion of voice which is selected for alternatives version is now showing as a very thick rectangle which looks like a red-filled one and makes impossible to see the music on which we are operating. I attach a picture (bug1-graphic).

The second bug, even more serious: It seems that RQ does not embed in patch the content of the object. Every time the patch is open (even if the workspace has not been closed, it’s sufficient to close and reopen the patch itself) the objet RQ triggers the calculation, which is time consuming especially in real-world quantifications that takes large amount of time) [Message1]
If you skip the recalculation you get an error and the patch does not open anymore! [message2]

A feature request: Can we make optional (via preference or a flag) the message that warns that the calculation may take long time??! Since it’s segment related, you cannot launch a long quantification batch because the system stops at every segment, and that’s a pain in the bass.

Thanks for the support!

Attachments:
  1. Message2

    Message2.png

  2. Message2

    Message2.png

  3. message1

    message1.png

  4. message1

    message1.png

  5. bug1-graphic

    bug1-graphic.png

  6. bug1-graphic

    bug1-graphic.png

July 16, 2017 at 10:28 #23045
Profile photo of Adrien Ycart
Adrien Ycart

Hi Alessandro,

Thank you for your feedback ! I am not working at Ircam anymore, but I can still try to do some maintenance work when needed. Looks like it is needed here =)

About the graphic bug : this is due to a change in some graphic functions in the latest versions of OpenMusic, I will post a quick fix online when I have time, hopefully in the days to come.

About the second bug : indeed, we did not embed everything in the patch. We tried to do it, but since the table used by the algorithm is huge, the resulting patch was really big too (sometimes more than 20Mo, compared to a few hundred Ko usually). So we decided to keep lighter patches, and recompute everything each time the patch is opened. It might be possible to find a more compact way to store the table in the patch, but 1. even so, it might still be really big, 2. it would require quite a lot of work, which I am not sure I can provide in the near future.
In the meantime, you can make computations faster when reopening the patch. When you have chosen a satisfying transcription, you can set the parameters of the algorithm for this segment only in order to not compute the transcriptions that you do not need : set the tempo value to the one you have chosen, and modify the schema to exclude rhythmic values you do not use. I think that simply setting the tempo value to the one you want should do the trick.

About the feature request : indeed, I hadn’t realised how annoying it can get ! This shouldn’t require too much work, I’ll try to include that feature when I publish a newer version of the library.

I’ll keep you in touch when I do those modifications and publish them.

Best,
Adrien

July 18, 2017 at 18:39 #23130
Profile photo of Adrien Ycart
Adrien Ycart

Hi again,

I actually had time to modify the RQ library today, you can download it at the same place as usual : https://forge.ircam.fr/p/omlibraries/downloads/
I fixed the display issue, and added a flag to show warnings or not.

When you open your patch for the first time, you will still see the warnings : it’s normal.
You can the select in the parameters to display them or not.
If you save your patch, you will never see the warnings when loading the patch again, even if you have ticked “Show warnings”.
You will only see them when running the algorithm through the interface.

Hope that helps ! Let me know if you have other issues.

July 18, 2017 at 21:00 #23131
Profile photo of ratox
ratox

THANKS Adrien, your work is really incredible and from my point of view one of the most simple and useful tools coming from the joint efforts of musicians and developers. It’s giving me hours of happy working, but still a major problem on my side.
I often work with very large raw inputs and i sometimes need to just quantize a small amount (generally the beginning) to understand the parameters i will use for the rest.

But i see there is an error if you just quantize a segment alone, before quantizing all the sequence. TO be clear you can re-quantize a segment only if you have already quantized all the segments with is really time consuming…. the first attempt must be done with the global “quantify” button (and not hitting q)

if you try to quantize directly the first segment you get this error:
– ERROR: RPLACA called with an atom as first argument: nil.
and for any successive segments:
– ERROR: The index 1 is out of range for sequence nil.
– ERROR: The index (x-1) is out of range for sequence nil.

thanks for your precious support!!!

July 24, 2017 at 15:04 #23184
Profile photo of Adrien Ycart
Adrien Ycart

Hi Alessandro,

Thank you for your feedback !
Indeed, being able to quantise certain segments without needing to have first computed the whole sequence would be very useful.
However, it might take some time to adapt the system to be able to do that, there would be quite a lot of things to modify in order to remove all the bugs.
I cannot guarantee I can do that anytime soon.

That being said, I understand that it is useful to run the algorithm on a small segment to test the parameters.
In the meantime, one option to do that is to cut out the beginning (or any other section) of your input chord-seq, and input it in another rq object that will be your “test” rq.
You can do all the tests that you need with this smaller version, and then run the computations on your whole input.

Also, if you are working with a really long input, it might be a good idea to cut it into smaller parts, and quantise them in separate patches. That way, when you close and reopen a patch, it only triggers the computations for one part, instead of computing everything. Once you have quantised your various sub-parts, you can then copy all the resulting voices in a new patch to concatenate them.

Hope that helps !
Adrien

July 31, 2017 at 17:06 #23292

You must be logged in to reply to this topic.

Log in now