Serge's World

I have been learning to play violin for a little over 2 years now, and have been focusing on the fundamentals with a bit of venturing into folk styles. For myself, I do find the folk styles, especially Irish traditional music, more fun to play than classical. As an adult starter, I also find the folk tunes more accessible than the classical repertoire.

Anyay, while learning, I have tried to collect folk tunes online, but managing the tunes has become a bit of a problem. I started searching for a decent Android app that could act as my music library, so I could have the music on my phne, or a tablet. Not finding a solution I liked, I decided to build my own.

Thus was born The Folk Tune Library. This Android app has a built-in library of over 2200 public domain folk tunes from around the world.

Earlier this year I decided to experiment with writing a Xamarin app, out of which The Musician’s Multitool was born. You can read about that here.

It was fun to be able to code in C#, which is a language I am far more comfortable in than Java. However, the fact that it was not native Android development meant that the resulting app was incredibly slow, especially in loading, and the package size was very bloated.

Another thing I wanted to try, was to integrate low-latency audio packages in the project, using C++, in order to improve some of the audio latency issues I had in the Xamarin version, which would be much harder to do in Xamarin.

Due to these factors, primarily, I decided to rewrite the application in Java, making it a native Android app.

I have recreated pretty much the exact same look and feel of the app, as well as all of the previous functionality as before, but the app runs much faster, and is more stable than before.

It actually takes far less time, at least for me, to create the same app in Java, as compared to Xamarin, so I think that moving forward, I have no reason to keep on using Xamarin.

I also renamed the app to Pocket Music Theory, which is also now the Google Play store.

[UPDATE: The Musician’s Multitool has been rewritten from scratch. For more details see the Pocket Music Theory post].

For a while now, I have been wanting to experiment a bit with using Xamarin as a platform for developing mobile applications. While .Net has been my primary dev environment for years, all the Android apps I have written so far have been in Java, and so was a bit apprehensive about changing that paradigm.

So, deciding to take that plunge, now, after a number of months of slogging away during my evenings, and on the weekends, I have a new app that I am ready to share.

The Musician’s Multitool is now available on the Google Play store. [UPDATE: This app is now deprecated, and replaced with Pocket Music Theory on the Google Play store. ]

So, what is this app all about then?

The Musician’s Multitool is a collection of tools useful for musicians, partly driven my own needs as an amateur musician.

The following features are available in the app:

• Interval, scale and chord finders - allow you to look up intervals, scales and chords, along with a music staff showing the relevant notes. These notes are also playable.
• Modulations - provides a dictionary of common modulations between keys.
• Musical instrument ranges and tunings - shows the ranges of various musical instruments and various common tunings for an array of string instruments
• Terminology and notation dictionaries - are reference guide for reading and understanding music
• Circle of Fifths - renders the relationships between major and minor keys.
• Metronome - provides a fully customisable metronome.
• Virtual Piano - covers the full range of a piano.
• Chromatic Tuner - this tuner allows the adjustment of the reference pitch
• Spectrum Analyzer - gives a view of the audio input as a waveform on an oscilloscope, as well as a frequency range graph.

Writing the app in Xamarin was interesting, and the app allowed me to touch a significant portion of the various features of app development, from figuring out how to play audio, to styling lists well, to drawing custom graphics, and creating custom controls.

This was a fun adventure, and I am hoping to add even more to the app over time, but for now, I hope you enjoy.

I made a bit of a breakthrough recently in my family tree, which led to an interesting story. It turns out that my great(12)-grandmother - Josina Francisca van Vlasselaer - was burned at the stake for witchcraft.

Josina Francisa van Vlasselaer was born in Kampenhout, Flemish Brabant, Belgium around 1540. She was married to Aert van Beethoven, and the couple had four children, namely, Mark, Hendrik, Jan and Anna.

Josina was arrested on 5 August 1595, by order of the mayor Jan-Baptist van Spoelberch in Kampenhouton suspicion of witchcraft, and was sent to a Brussels prison. She had been accused of making a pact with the devil by some villagers, because on four separate occasions a horse had died in the village near a place where she had passed by. After she got arrested, more accusations were raised against her, such as a cow that had given sour milk, and a horse that had urinated blood and died of colic. She had denied all the accusations, but after being tortured on the rack, eventually gave in. Her interrogators also asked her about any other witches that she knew, and gave the name of her neighbour, Anna Verstande, up. She was then condemned to being burned at the stake. The night before her execution, around 13th September 1595, Josina tried to commit suicide by swallowing potsherds, but this attempt failed.

Aert, Josina’s husband could do nothing to help his wife, and petitioned to keep half of their forfeited property. This was allowed, although he had to cover the cost of the arrest, interrogation, torture and burning.

So, what does this have to do with a musical genius? Well, Aert van Beethoven and Josina van Vlasselaer were also the great-great-great-great-great-grandparents of Ludwig van Beethoven (1770-1827). Yes, that Beethoven - the great classical composer.

This also means that Beethoven and I are also distantly related cousins - 6th cousin, 7x removed, to be precise, and we share this rather juicy story hiding in our ancestries.

The full line of descent for Beethoven and myself is then as follows: Serge Julien Meunier -> Robert Jacques Raymond Meunier (1945-2004) -> Jacqueline Marie Francoise de Winter (1919-2016) -> Jeanne Leonie Moyson (1895-1966) -> Francoise Marie Moyson (1877-1940) -> Jean Baptiste Moyson (1838-1901) -> Josina Peeters (1797-1866) -> Petrus Peeters (1771-1814) -> Petrus Peeters (1745-1774) -> Johannes Peeters (1707-1776) -> Guilielmus Peeters (1680-1747) -> Marcus Peeters (1635-1702) -> Anna van Beethoven (1597-1662) -> Mark van Beethoven (1568-1640) -> Josina Francisca van Vlasselaer (1547-1595).

Ludwig van Beethoven (1770-1827) -> Johann van Beethoven (1740-1792) -> Lodewijk van Beethoven (1712-1773) -> Michiel van Beethoven (1684-1749) -> Cornelius van Beethoven (1641-1716) -> Marcus van Beethoven (1601-?) -> Hendrik van Beethoven (1572-1652) -> Josina Francisca van Vlasselaer (1547-1595).

A lot of my genealogy posts have focused on my South African ancestry, however, this story concerns my Belgian heritage.

My great-grandmother, Jeanne Leonie Moyson, was born in Brussels on the 9th of July, 1895, as the illegitimate daughter of Francoise Marie Moyson, and no father listed on the birth record. Two years later, Francoise Marie had another illegitimate child, which she named Fulgence Joseph Moyson, who was born in Dest on the 17th May, 1897.

These are the only children that I am aware of, even though she married Fulgence Joseph Delaloy in Moelbeen-Saint-Hean on 19th of March 1906.

At this point, I had reached a dead end, concerning who the biological father of the two children were. I could trace Francoise Marie Moyson’s ancestry back for several hundred years, and found a lot of details about Fulgence Joseph Delaloy, as well, but as for who the father was, I had no idea.

Until, I got a message from Jean Paul Delaloy, who was a DNA match with me.

This was exciting. Before this, I had no blood relation to Fulgence Joseph Delaloy, so how could we have a DNA match?
Read More »

It has been a while since I posted some whisky updates. Over the last winter, I have enjoyed a few new whiskies, while enjoying relaxed evenings out with my wife. It will probably be a while before this happens again, due to the lockdowns with the Corona virus.

Scapa Skiren Single Malt

From the Orkney islands, this oak-aged whisky had a gentle alluring nose with hints of fresh citrus, followed by a fruity aftertaste with a bit of a herby note. It as silky smooth, and enjoyed it very much.

Aberfeldy 12 Year Old Single Malt

Hailing from Perthshire, the Aberfeldy was immensely enjoyable, with a fruity taste with dashes of spiced honey. This was a perfect whisky to sip while relaxing on a terrace during the evening, watching the people going by.

Yellow Spot 12 Year Old Single Pot

This one is the only Irish whiskey on this list, and it delivered. It had a fresh sharpness to it, following by a soothing and warm draw.

Chivas Regal 18 Year Old Blend

Normally, I tend to favour the single malts, however, this old classic is exceptional. The taste was reminiscent of bitter fuge with vanilla, with a woody palate. It is definitely on my favourites list.

Oban West 14 Year Old Single Malt

I have left one of the best for last. This West Highland whisky has a gentle sweet citrus flavour underlying a woody and peaty richness. All of the above whiskies were great, but this one stood out for me.

I posted a while ago about some new findings in my maternal line ancestry, and had mentioned Aletta Frederica Bender. Since then I have uncovered quite a bit more about her, and how she fits into my family history.

What we already know

To recap briefly, up to this point, the earliest maternal line ancestors I had known were Frederick Bender and Annie Truter. They had the following children.

• Sarah Elizabeth Bender (c1860 - 1919) = James Reid
• Johanna Jacoba Bender (1864 - 1935) = Abraham Michael Reid (1864 - 1932)
• Maria Frederika Bender (1866 - 1940) = Henry Charles Jackson (1865 - 1914)
• Abraham Andreas Bender (c1870 - 1922) = Maria Magdalena Thomas
• Charlotte Maria Bender (1874 - 1953) = ?? Herbert (1879 - 1940)
• Frederika Maria Bender (1879 - 1940) = Frederick John Gietzman
• Aletta Frederika Bender (? - 1952) = Edward William Steele (1860 - 1923)
• John D

Since I had published that article, I found more documents providing more clues to this part of the family. Frederick and Annie were married at the Wesleyan Methodist chapel in Somerset West on the 1st June 1859. The marriage certificate also lists their full names as Frederick Johannes Bender and Johanna Jemima Truter.

Previously, I had also mentioned the baptism of Johan Frederik Bender, born on the 8th of August 1836 in Stellenbosch, to Aletta Frederica Bender and a foreigner named Charles, but could find no plausible link to the Benders in my family tree.

But now, the trail would seem to run cold. There are no further direct references to either of these two individuals. However, I have a new theory…
Read More »

Software development is not an easy profession, with many aspects which can be really challenging, but often the most difficult things to get right are not difficult abstract complex algorithms, but rather, it’s often the seemingly easy stuff that gets you.

So here is my list of things that are deceptively hard in programming.

Caching

For web development in general, caching is vital for applications to keep running, especially for high load applications.

In principal caching is not that hard. Backend requests should have a caching layer on top, and within the code itself, it is often advisable to cache frequently used data in caches, such as Redis, instead of having to fetch it each time from slower sources, such as databases.

However, the complexity comes in with how much to cache, and for how long. If you don’t cache enough you can get performance problems, but if you cache too aggressively, you can end up with stale data, which causes a whole different set of problems.

Finding the correct balance in caching is never trivial.

Threading

Multithreaded applications have been around for decades, and like caching, the principals of threading is something that any decent programmer will know how to do, but it does have a few subtle gotchas.

The biggest challenge with threading is finding the optimum number of threads to spawn. For a given server size, if your application is running too few threads, then it is not using the machines full potential, but conversely, too many threads may use 100% of resources, but may have much more overhead managing the threads and have many processes that are blocking.

With each additional running thread, the overhead increases, and once full resource utilization is reached, that starts to become a big problem.

The trick is to find the right amount of threads to get the best performance, but the difficulty here is that every application is different. The number of ideal threads can vary based on what the threads are doing. If the threads spend a lot of time waiting on external resources, you can get away with more threads, while if threads are doing very resource intensive work, then fewer threads are ideal. This is really the hard part of threading.

Scaling

In the modern era of cloud-based applications, scaling has become very important. You need to have sufficient instances of your application to meet the demand of requests. Scaling applications is easy on platforms such as Azure or AWS, but once again, finding the right sweet spot makes it hard - if you run too many instances, you are wasting money running servers you don’t need, while if you underestimate your needs, your applications starts failing (essentially suffering something similar to a DDOS attack).

The complexity does not end there though. Not all resources are equally scalable. A website could be scaled easily, but that may depend on resources such as a Redis cache, or a SQL database, that may not be so easily scalable, and these will introduce hard limits in how far you can scale. Solving these issues may require considerable redesigns, if they become a problem. Maybe you need a more scalable database, such as a NoSql database instead of a SQL database, or optimising caching, as discussed above.

The hardest part of all, is that the correct solution for scaling is completely dependant on the particular application, and thus there are no generic one-size-fits-all answers to solving scaling issues.

Naming

Ask any programmer what the hardest thing in programming is and this answer will invariably come up. Naming methods and classes well is not always easy, and make the code easier to read, but is really only on this list for fun. This entry has no impact on performance, like the points above, and won’t casue anyone to wake up in the middle of the night with a cold sweat.

One of the major issues I had while developing Arbor Familiae, my Android genealogy app, available at https://github.com/sjmeunier/arbor-familiae, is how to import and export data into, and out of the app. This, in itself, is not hard, but Android requires extra permissions to access external resources, which can be a big turn-off for users, so I searched for another way to do this. The solution is to use file providers, which is type of content provider.

The principle behind file providers, is that instead on the app reading and writing the data to external files directly, the app makes a request to an Intent to provide a data stream to either read or write the data to. This method allows the user to decide where the data goes to, while also not needing any special permissions in the app itself.

So, how does it all work?
Read More »

As I mentioned in my previous post, I have been creating a family tree viewer for Android as a hobby project, and have reached a point now, where it is in a useful state. Therefore, Arbor Familiae is now available on the Google Play store.

I have open-sourced the project, and released the app as a completely free app on the store. The source code can be found on my Github account at https://github.com/sjmeunier/arbor-familiae.

The app allows you to import GEDCOM files into the application, and multiple GEDCOMs can be imported into separate trees.

With an imported tree, the follwing features are available

• Tree Chart - a chart showing all ancestors up to the configured number of generations of the active individual in a tree form, and also includes spouses and children of the active individual.
• Fan Chart - shows the ancestors or descendants of the active individual up to the configured number of generations, as a fan chart
• Relationship Chart - shows the relationship between the root individual and the active individual.
• Heatmap - shows the locations for birth, death, burial and baptism events for the ancestors of the active individual mapped as a heatmap using Google Maps.
• Detailed Biography - shows detailed information on the active individual, including birth, death, parents, souses and children, as well as any notes or sources included in the original GEDCOM for the individual.

I will be posting more technical blog posts in the future, highlighting some of the interesting technical problems I solved while developing this app, so stay tuned…