I'm trying too figure out how the glissando is represented in the musescore data structure.
It looks to me like a note as a boolean property indicating that it ENDS a glissando.
But I don't find any other clue?
How can i find the note which begins the glissando? Is it simply the previous note in that voice? If the previous chord contains multiple notes, which one is the glissando beginning?
Does musescore support glissandos which span notes? such as the following hand drawing?
Glissando are stored in Note. In the spannerFor and spannerBack. My understanding is that in theory they could do what you draw but for the moment, MuseScore doesn't let you create it. You should be able to create "parallel" glissando like in the attached picture.
2015-05-07 11:39 GMT+02:00 Jim Newton <[hidden email]>:
I'm trying too figure out how the glissando is represented in the musescore
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
Mscore-developer mailing list
=?UTF-8?B?Q2FwdHVyZSBkJ2XMgWNyYW4gMjAxNS0wNS0wNyAxMi4yMS4zNi5wbmc=?= (37K) Download Attachment
Thanks, that gets me a lot further. It looks like the spannersFor container contains spanner (objects or pointers?) some of which have type glissando. Also each spanner object knows its startElement, endElement, and anchor type which might be NOTE. In the case that the anchor is NOTE, and the start and end elements have element type NOTE, then I can get the pitch from the endElement, and midi-render the gliss.
Not sure if I need to check the types of the start and end elements and also the type of the glissando anchor?
That's the plan anyway.
I need to have a discussion in the forum about the correct way to play a glissando.
In reply to this post by lasconic
Just for completeness, as I am the one guilty of this glissando implementation: yes, lasconic description is correct.
This implementation allows (should allow?) to correctly store and draw a glissando from whichever note of one chord to whichever note of whichever other chord following the first, even in another staff.
Currently, there is no UI to change the default start and end note proposed when the glissando is created, though.
Note: The bool you quote about being the end of a glissando is purely instrumental: it is a property of a whole cord (not just of the end note), as the chord at the end of a glissando needs to make decisions about left-side spacing and this spares to scan each time the properties of each note of the chord.
Hi Maurizio, Can you explain to me the relation between several classes.
I'm having some debugging problems and an overview of the intent might help me.
The class GlissandoSegment -> LineSegment -> SpannerSegment -> Element
Glissando -> SLine -> Spanner -> Element
My situation is that I've added a new property the the Glissando (with a QT interface to edit the property).
However, when I select a glissando in the score GUI, and change this property, I see that the SpannerSegment::setProperty method is called, which explicitly calls Element::setProperty.
This results in a qFatal being called in element.cpp inside Element::setProperty().
Do you know whether I need to set up parallel properties between GlissandoSegment and Glissando?
Or how is this supposed to work?
Kind regards and thanks for the help.
Element: all visible (and several non-visible) elements of a score derive ultimately from the class Element; we can think of this as a requirement of the MuseScore infrastructure.
Spanner: it is a class for all the elements which may span across a time span: examples coming to my mind are: Volta, Slur, pedal indications and so on. IIRC, it is an abstract class.
SLine: it is an implementation of Spanner for spanners with a visible line.
Glissando: it sub-classes SLine and qualifies a glissando as a Spanner as, in general, a glissando may cover more than one system (for instance between the last note of a system and the first note of the next system).
The other hierarchy is parallel but separate:
SpannerSegment: it is one portion of a Spanner; a spanner covering more than one system is usually split in two (or more) segments, one for each system. Note that SpannerSegment's are the elements actually visible in a score.
LineSegment: implements SpannerSegment for segments of an SLine.
GlissandoSegment: sub-classes LineSegment for the individual segments of a glissando.
Selection of Spanner's is tricky; it took me a while to understand all its implications.
Basically, when you select (or believe to select) a Spanner, you actually select the SpannerSegment you physically clicked on. So, any property change is routed (by the Inspector framework) to the SpannerSegment class (or, in case, to a sub-class of it).
If the property actually refers to the Spanner as whole, like for instance the STRAIGHT/WAVY property of a glissando, the relevant segment class (GlissandoSegment in this example) shall route the property change to the 'parent' Spanner class (or sub-class, Glissando in the above example).
So, it mostly depends on the kind of property you added: if it is specific for each segment of the glissando, it should belong to GlissandoSegment and be managed by it; if it applies to the glissando as a whole, then the various methods of GlissandoSegment dealing with properties should route the relevant property get/set to the Glissando class.
I do not have the code at hand right now, but I believe that, if you look at the GlissandoSegment::setProperty() and ::getProperty() functions, you should see some practical example of this.
Hoping it may help,
|Free forum by Nabble||Edit this page|