The data model for a score contains one or more StaffComponents which in turn
each reference a StaffComponentModel object that wraps a [collection] which
contains Chord objects which also have a [collection] which contains Note
objects. Having the ability to declare the object graph for a whole score or
just a staff in BXML is important and it also looks like what type of Pivot
collection to use in place of the generic placeholder [collection] used by the
StaffComponentModel and Chord objects is important for binding.
What I am thinking of is having a StaffComponent, StaffComponentModel (also
known as a Part in music) and StaffComponentSkin. There is only one type of
StaffComponent that is created for each score staff desired. A StaffComponent
will then reference one of the StaffComponentModel instances that are stored in
a separate map outside of the score. A StaffComponent will also have a
StaffComponentSkin which will be able to layout and paint the music data in the
StaffComponentModel referenced by a StaffComponent in any possible way.
The StaffComponentSkin should be able to dynamically load JSON resource files
to provide user/style properties (to load into it dictionaries) which will be
recipes for different notation types (there are many types of proposed
notations besides the standard notation we all know). Is it possible to use the
same resource file mechanism that localization does for this? Each notation
that would be described by a resource file is very similar in concept. Only,
instead of languages like english or french we have different
languages/notations for the UI that the staff's skin provides. Also, is it
possible to dynamically load/store notation resource files for a
StaffComponentSkin so the LNF for a staff can be changed at any time and be
completely pluggable (as in PLNF)?
There are also Renderer objects and Decorator objects to consider as extensions
to the StaffComponentSkin. With the StaffComponentSkin responsible for the
layout and painting of the data in the staff's StaffComponentModel how would
Renderer and Decorator objects be best utilized? The paint method will paint
many types of symbols and I'm not yet sure if an ImageView is warranted for
each symbol. However, Renderer and Decorator objects could be attached to a
StaffComponentSkin if not to ImageView's for symbols.
Most of what I need to do is map Pivot objects and patterns back to my existing
design. Pivot is a fresh breath of air and the first framework that I feel has
the capacity to make it possible.
Thom
On 2010-09-28, at 6:52 AM, Greg Brown wrote:
>> The MVC pattern in Pivot is well implemented and it is getting me thinking
>> about options for a musical score. My view of a score is that it is
>> comprised of its data, a model object graph and a graphic representation of
>> the data in the graph. There may be a way to align these aspects with the
>> MVC pattern that Pivot uses?
>
> This is exactly what I was talking about in my previous message. :-)
>
>> Presently, the model object graph has just enough objects arranged in a tree
>> to allow any type of score to be formed. The objects carry a lot of data
>> that is put there by editing tools and musical analysers. Possibly the graph
>> could be an extended Component? There are many ways to represent pure music
>> data so having alternate skins (and styles) might be a way to do that as
>> well?
>
> Data models in Pivot are often implemented as collections, Java Beans, or a
> combination thereof. The Sequence interface is used to represent an ordered
> collection of values, and Dictionary is used to represent an indexed
> collection. Classes that implement these interfaces generally fire events to
> notify listeners about changes. Some classes fire events directly (such as
> ArrayList) while others fire them indirectly via an outer class instance
> (such as TabPane.TabSequence). Which approach to use is entirely up to you.
>
> Again, I'm not an expert, but I imagine that a "score" could loosely be
> modeled as a collection of "notes". So, you might be able to do something
> like:
>
> public interface Note {
> ...
> }
>
> public class Score implements Sequence<Note> {
> ...
>
> public ListenerList<ScoreListener> getScoreListeners() {
> // return scoreListenerList;
> }
> }
>
> public interface ScoreListener {
> // Define score events such as noteInserted(), notesRemoved(), etc.
> }
>
> If your model isn't too complex, you might actually be able to use an
> ArrayList rather than creating your own Sequence. ArrayList implements the
> List interface, which already defines a set of sequence-oriented events (in
> ListListener).
>
> Anyways, hopefully this is enough to get you started. There are lots of
> examples of Sequence implementations throughout the code, too (as well as
> Dictionary).
>
>> I have resolved my requirements already but there may be a benefit to
>> refactoring to the MVC pattern Pivot uses?
>
> There is - if you use Pivot's collection interfaces (specifically Sequence
> and Dictionary or a class/interface that extends them), you can use BXML to
> declarative construct instances of your model.
>
> G
>
