Bug in Cursor.next()?
How to increment cursor? I'm stuck with this in a few days! Can't find a way to programmatically enter notes/rests and other elements instead of using cmd(). I also need a way to get current measure (in a case when cursor walk through several measures) and get elements under cursor. The problem is that It looks like the next() method of the Cursor didn't work as it should. If I do so:
cursor.setDuration(1, 4); cursor.addNote(60); cursor.next(); cursor.addNote(62); cursor.next(); cursor.addNote(64); cursor.next(); cursor.addNote(65); cursor.next();
the cursor behavior identical to Cursor's nextMeasure() method. It doesn't adds the notes one after another.
But, ok, there is a solution:
cursor.setDuration(1, 4); cursor.addNote(60); cursor.addNote(62); cursor.addNote(64); cursor.addNote(65);
But the cursor don't incrementing in this case. You can check it by log segments and measures (in a case of "multimeasure" selection) - they are always the same. It's impossible to get segment/element under the cursor on the next position, because the position is always the start of the selection or the start of the next measure. Is it a bug in next() or don't I understand something basic? Is there another way?
Comments
Shout in a black hole...
Is there another place, where somebody answers on questions about plugin development?
In reply to Shout in a black hole... Is by Ales Tsurko
Please keep in mind that we're all volunteers here, having to wait 1 day (even up to a week) can hardly be considered shouting in a black hole. Occasionally you might get a faster response via IRC, but most people on there also roam the forums regularly. Posting here and having a little patience is all you need.
Now on to answering your questions:
Is Cursor.next() different from Cursor.nextMeasure()
Yes it is. The difference is very notable if you're not also changing the score you're looping over. The colornotes.qml plugin delivered with MuseScore for example makes use of cursor.next() to look for the next chord it should work on.
Cursor.next() moves to the next segment from the cursor and sets the internal input position to that new segment
Then why isn't your code working as you'd expect?
I think a misunderstanding/bug exists with the Cursor.addNote() function. As you yourself found out (https://musescore.org/en/node/94621) you don't want to call Cursor.next() after Cursor.addNote() as it seems to move the input position to the next measure.
Here's what I found out after looking into the code the past hour:
-> Cursor.addNote() already moves the internal input position of the score to the next segment BUT it seems to not (correctly) update the internal segment reference of the Cursor
This could explain why:
1. You're not reading back the internal incremented input position of score, as Cursor isn't fully up to date
2. You still skip a segment too far after wrongly being tricked into needing Cursor.next() as this one somehow does start from the correctly incremented position and moves you one further.
Please do file this as a bug, so someone (probably myself, given the just performed research) can patch up the internal reference state of Cursor after addNote as well as update the plugin documentation for addNote clarifying it already moves to the next input position. We'd probably also update the example plugins as part of that bugfix then.
Hopefully you now understand that not receiving an answer within a day doesn't mean someone isn't looking into it.
In reply to Please keep in mind that by jeetee
Thanks a lot!!! As for my comparison, it's based not on the one day waiting here, but on the past experience. I just thought may be there is another place (some mailing list, for example). Also on long wait it's easy to assume that nobody would answer at all. Sorry, I just wanted to draw attention, because the answer is so important for me, that it's critical in my project. I tried to make a full algorithmic composition toolset, that's I needed a way for programmatic generation and replacement of pitches, durations, dynamics and may be articulations.
In reply to Thanks a lot!!! As for my by Ales Tsurko
FWIW, I think you'd find music21 better suited for algorithmic composition; it's really designed for that sort of thing more than the MuseScore plugin architecture is. music21 could then generate a MusicXML file that MuseScore could read.
In reply to FWIW, I think you'd find by Marc Sabatella
There is a lot of algorithmic composition tools. I prefer AC Toolbox and Open Music, for example. But noone of those are represent a musical form as a whole with a rich interactive GUI (except of what Open Music offers via maquettes). I wanted to make just GUI based, without any sort of programming. I mean making tools for MuseScore, that's not programm algorithmic compositions via plugins API, but making GUI tools for generating pitches, rhythm and dynamics with different algorithms. Also it would be very cool to select some measures, generate something using one of a tool, then recompose it by hand or combine different approaches. In my workflow also it would be better to have all in one place. Currently I'm generating some movement using AC Toolbox or Open Music, then export it to XML, then import it in MuseScore where is my main composition which I half-to-half compose using algorithms and manually. It would be great to do it all just in MuseScore, especially during the fact that MuseScore itself is a great composition tool and score editor.
In reply to FWIW, I think you'd find by Marc Sabatella
I looked at music21 (being written in Python and having MusicXML export, I could have used it for my MML export) but there’s a rather unfortunate problem:
It’s not in Debian because there was a licence problem never cleared up: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598670
This is apparently about the musical scale files. His post to debian-legal (not quite the appropriate forum, but a start) inquiring about the copyright status of such files went unanswered.
If there’s someone (music lawyer?) who can comment on whether such a scale is copyrightable in the first place (and not mere fact), and (this is probably more regular software licencing-related) whether the notation of that in *.scl files is copyrightable (I myself can say with very high certainty that it isn’t) and whether there are any collection rights on the archive (possibly https://en.wikipedia.org/wiki/Sui_generis_database_right if not copyright, and he seems to be based in The Netherlands, which makes this a valid possible concern, but I’d just ask Manuel Op de Coul directly, after the other concerns have been cleared up) we could restart the Debian packaging process (which includes legal review).
In reply to Please keep in mind that by jeetee
I think that cursor.addNote may potentially give even worse problems. See #92856: Plugins cannot really substitute underlying chord/rests
In reply to Please keep in mind that by jeetee
Bug reported as #100181: cursor.addNote doesn't update internal segment reference
In reply to Bug reported as #100181: by jeetee
Thanks!