data structure for glissando

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

data structure for glissando

Jim Newton
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?

Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

lasconic
Administrator
Hi,

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.

lasconic

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
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?

<http://dev-list.musescore.org/file/n7579311/Scan.png>



--
View this message in context: http://dev-list.musescore.org/data-structure-for-glissando-tp7579311.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
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.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

=?UTF-8?B?Q2FwdHVyZSBkJ2XMgWNyYW4gMjAxNS0wNS0wNyAxMi4yMS4zNi5wbmc=?= (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

Jim Newton
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.
Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

Maurizio M. Gavioli
In reply to this post by lasconic
lasconic wrote
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.
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.
Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

Jim Newton
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.
Jim
Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

Maurizio M. Gavioli
Jim Newton wrote
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
In general:

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.

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().
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,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: data structure for glissando

Jim Newton
Yes this helps me understand better.  Some of what you said, I had already figured out by reading the code.  The bigger picture, I hadn't yet understood.
Thanks.