Iteration 52 is out

The new version of Zong! contains an updated layout engine. It was not extended yet, but we cleaned up the code and gave it a more functional style. There is also a big map showing all classes involved in the layouting process:

In the next two iterations we will improve both the layout engine (features like cue and grace notes, multi-staff beams) and the MIDI output (tempo, transposition, repetitions, voltas, dynamics).

Java Tip #5: Shorter singleton calls

If you are using the Singleton pattern, you often have code like this:

Object myValue = MySingleton.getInstance().getSomeValue();

Can this be shortened? Yes! Like in Java Tip #3, we can use public static methods and static import. But then, we do not see at a glance what getInstance() is actually returning, and if we use multiple Singletons within our class, we would have a naming problem. The easy solution: rename the getInstance() method to the (camelCase) name of its class. Now we can write:

Object myValue = mySingleton().getSomeValue();

Welcome, developers!

The last days I have replaced the old, quite complex Ant build script by a much simpler configuration file written in Java, that is based on Xenoage Build, a quick & dirty extension to Ant. I did this, because I really had problems in Ant when having multiple subprojects with different dependencies on each other. I think, the lines 34 to 58 in the new config file describe this dependencies much nicer than the old Ant script.

Additionally, I have added a tiny tutorial how to set up Zong! in Eclipse. Following these three steps, you can run and debug Zong! within two minutes on any operating system.

Developers are welcome! If there are other things we can do for you, please don’t hesitate to tell us what you need.

Iteration 51 is out

After many weeks of work, Zong! p0.4.51 is finally out. Although there are no new features which are interesting from a user’s perspective, there are two important changes which are essential for the future development of the project:

• The core has been completely replaced. While it was based on mutable Java classes and operations using many side effects before, the core is now completely functional. It is now much easier to test and maintain, and undo/redo is now a trivial task. The new core wouldn’t be possible without the excellent work of the pcollections project, which I can really recommend for Java projects of any kind.
• The musicxml project replaces proxymusic. While this is also a great library which I can recommend to all Java+MusicXML projects, we had problems with the Reflection techniques it is using (applets must be signed then), JAXB’s not-so-optimal XML-to-Java conversion and its speed (on my machine proxymusic needs about 2 minutes to load all official MusicXML 1.1 and MusicXML 2.0 samples, while our new musicxml library needs about 5 seconds). The two projects do basically the same, but proxymusic is automatically generated from the MusicXML schema, while our library is written by hand, which is really a very boring task, but finally it was worthwhile.

The goal for the next iterations is to rewrite the layout engine so that it fits to the functional core. Then, we can continue to improve the layout engine and support more music notation features. We also plan to offer a web service that converts MusicXML to PDF (and possibly other formats).

Java Tip #4: Switch comments

During testing, you often want to make things simpler. For example, if you want to test your new printing routines, you might want to see only the print preview instead of getting real printouts. You can switch between two code blocks by using the following pattern and by simply inserting or removing a single character:

//*
show_only_preview();
/*/
real_printing();
//*/


When removing the first slash, the second code block becomes active:

/*
show_only_preview();
/*/
real_printing();
//*/


Java Tip #3: Shorter code with static factory methods

Java code can look much cleaner and shorter when using static factory methods combined with import static. These are methods, which return a new (or reused) instance of a class. Let's say we have a HashMap which should use instances of KeyClass for the keys and a tuple of ValueClass1 and ValueClass2 as its values. Instead of writing lengthy code like

HashMap<KeyClass, Tuple<ValueClass1, ValueClass2>>
  myMap = new HashMap<KeyClass,
      Tuple2<ValueClass1, ValueClass2>>();

you could just use

HashMap<KeyClass, Tuple<ValueClass1, ValueClass2>>
  myMap = map();

Therefor, we need to create a static factory method named map somewhere with the following code:

public static <T1, T2> HashMap<T1, T2> map()
{
  return new HashMap<T1, T2>();
}

And then, when filling the HashMap, you can again make use of factory methods. Compared to

myMap.put(myKey,
  new Tuple2<ValueClass1, ValueClass2>(
    value1, value2));

the following code is much shorter:

myMap.put(myKey, t(value1, value2));

Nice, how easy tuples (or triples, or quadrupels, ...) can be created in Java! Remember, that import static is needed to make it really short. We do not want to write Tuple.t(...) everywhere where we instantiate a tuple, but really only t(...). This is nearly as short as in the programming languages which support tuples natively.

One other example, where we always use those methods, are fractions. Instead of new Fraction(1, 4); we always use fr(1, 4). Actually we made the constructor private, so that programmers must use the factory method. This leads to much cleaner code. One real example from Zong!: Instead of

new Chord(new Note(new Pitch(1, 0, 4)),
  new Fraction(1, 4))

we just have to write

chord(note(pi(1, 0, 4)), fr(1, 4))

Downloads: Fraction, Tuple2, Tuple3

Java Tip #2: foreach with index (2)

Time for another Java Tip. Last time I described the problem of losing a loop counter when using the foreach loop. I mentioned, that I have two solutions for this problem. Here is the second one:

I created a class named It (short for “iterator”). It is a Iterable Iterator (funny, but true: Not all Iterators are Iterable in Java…) which allows you to wrap any collection and use it within a foreach loop. Moreover, it contains the method getIndex() which returns the current value of the loop counter. For quick creation, there is the it factory method which you should import statically.

Here is an example:

It<Foo> fooIt = it(fooList);
for (Foo foo : fooIt) {
  //for each foo in fooList...
  foo.doSomething();
  //if you need the current index:
  System.out.println(fooIt.getIndex());
}

You can also write similar iterators, like ReverseIterator for an iterator which begins with the last element and ends with the first one. Enjoy

Downloads: It, ReverseIterator

Java Tip #1: foreach with index

When you are working with Java some hours each day, you soon develop an own programming style and collect some ideas how to make your code nicer. From time to time, I’ll present some of my most favorite ideas here.

Today, let’s look at the foreach loop. I guess, you often use code like this:

for (int i = 0; i < list.size(); i++) {
  Element e = list.get(i);

Not really nice, is it? As Java programmers we are used to read and understand such code quickly, but there must be a better way, since what we want to say is only “For each element of the list…”. But hey, we have the foreach loop since Java 5:

for (Element e : list) {

Very nice, isn’t it? Unfortunately we have lost the index of the current element now, which was stored in the variable i before. For this, I’m using two solutions. The first one is using a custom iterator, which I will explain in a later Java Tip. The second one is using an index together with foreach, that runs over a Range (use import static of the Range.range method):

for (int i : range(list)) {
  Element e = list.get(i);

Though we do not get a one-liner, we get rid of the increment at least. The Range class is also very useful for other cases, for example when counting from 1 to 10:

for (int i : range(1, 10)) {

Downloads: Range

1229 errors left to solve for iteration 50

Although it was a little quiet in this blog during the last weeks, this doesn’t mean that we aren’t working hard on the next iteration. Haydn (Iteration 50) is really a hard nut to crack! Currently we are completely replacing the core of Zong! which allows to store and manipulate musical data. While this core part was heavily relying on side effects and mutable data, we are now moving to a core that contains only immutable, persisent data structures and embraces a much more functional style.

The idea to do that arised when I was learning Clojure. Although we do not use Clojure (yet), since it is still too complicated to call from the Java side, it is always a good idea to learn new languages and to gain insight into different programming concepts. This makes you even a better programmer in the language you are coming from! But now, what are the advantages of a functional core?

One good reason is the testability. Since there are no side effects, it is much easier to understand and debug the code. The same input always results in the same output, without influence of outer effects. Another reason is concurrency: Persistent data structures are thread safe by design, and it is never necessary to create defensive copies of your objects, because it is guaranteed that they can never be changed. But the biggest advantage from a user’s point of view is undo/redo functionality. While we wracked our brains how to undo side-effect based actions up to now, it is now trivial to undo each action: Just remember the root object before performing the action. This is brain-dead easy!

Unfortunately, Java was not designed for using immutable objects, so the code for implementing these classes is not as nice as it could be like when using Clojure for example. Neverless it is possible and often results in much nicer code when using these classes. We decided to use the pcollections library and it does a great job so far! Although it is still quite unknown, I am sure that it will get more attention soon, because the advantages of persisent data structures are really groundbreaking in my eyes.

How does the persistent core works? Basically, we have a tree of musical classes with the Score class as its root. It is immutable (nothing can be changed), so no backward links are possible. This is kind of a problem, since for example a chord belongs to a slur and a slur contains chords. This can not be directly modelled with immutable data structures. Therefor, we have a big hashtable at the root which save all Globals (beams, slurs, ties, attached elements like dynamics, musical positions of each element for very fast lookup, and so on). The staves, measures, voices and its element are represented in a tree structure like one would probably expect it.

Let’s say we want to add a note to an existing chord, which is beamed. Therefor, we create a new score, based on the old one (and of course sharing as much data as possible, which is never a problem since everything is immutable ). When “changing” a chord, we also have to “change” its voice, then the measure the voice belongs to, then the staff the measure belongs to, and so on, up to the root. After that we have to update the Globals since our chord now has a new reference of course. This sounds more complicated at first, but the hierarchy of the elements in the tree is quite flat, and we are not using (much) more memory than we would need for the side-effect based solution. Remember: While it is more efficient to work with side effects when performing some action, it may be a nightmare to undo it again! This is absolutely trivial using persistent data structures: Just remember the Score instance, perform your changes, and if you want to undo them again, just take the old Score instance. Cool, isn’t it?

The changes are so radical, that I’m already working for more than 50 hours to integrate them into the other Zong! projects. There are still 1229 compile errors to solve… But I’m sure that the new core will bring Zong! a very big step forward – also because we solved the tremendous undo/redo problem by the way.

Tracker moved to new server

The exams are over – now it’s time to work on Zong! again. Since today, the bugtracker runs on our new homeserver and we also moved the private git repository to there. Thanks again to Phil for hosting them the last months (or even years)!

We are amazed how many people are interested already in this early stage of the project. Thanks to all the contributors that have sent us ideas, code and example files so far. I hope I’ll catch up soon and integrate them. If anyone would like to join the project, don’t hesitate to contact us