Men at Work
As soon as I began experimenting with the DOSY toolbox I was surprised to discover an unexpected hole, which is just a novel proof of my old theory on NMR imprinting.
If your first spectrometer is a Varian, you will become a certain kind of spectroscopist and a certain kind of programmer. If your first instrument is a Bruker, you will become a different spectroscopist and a different programmer.
If a brukerist programmer had written this toolbox, he would have imported the frequency domain spectrum and started from there. Mathias Nilsson is instead a Varianist and he imports the FID only. We talked about it and now he agrees with me on the importance of importing and exporting the data to and from as many programs as possible. For example, I might prefer using an external software for the preliminary processing (FT, phase and baseline correction), then the DOSY toolbox for the separation of components, eventually a third software (or the first one again) for printing, visualizing, creating slides, etc...
This is not really efficient, because in many real cases I probably want to try with different preliminary processing (e.g.: apply or remove a line broadening), and this is already easily done with the toolbox, but becomes cumbersome if I move data from an application to another at each stage. The principle is, however, to let the user choose whatever he prefers.
This kind of transfer is the less problematic one: the information is not to be stored, not to be transmitted, is consumed on the spot on the same machine that generates it. I and Mathias have already started collaborating on this and, if only we were better programmers, we had already finished by now, but this is not the case.
Unfortunately, we are equipped with two different brains, and it has a price: countless emails to explain each other what we need, what we can do, how we would solve a given problem. It's really a case where it takes more to explain a thing than to do it.
In practice, we have created a simple, highly readable, redundant file format that consists into a text file, like JCAMP-DX, but without compressions of any kind. At the same time, we are testing this format on the field. I am writing two scripts (the language is Lua) to export data from iNMR to the DOSY toolbox and to import data back again.
We have chosen this approach because I am the prototype of the average ignorant. If I am able to write these scripts for at least one external program, this can be categorized as an easy task, whichever other program you want to use in combination with the DOSY toolbox, the only requisite being that the program must be scriptable.
Now you know what I have been doing during these days and why the promised review is not ready yet. To tell the truth, I don't know why I should write a review in a case like this, where the source is open and the author is so collaborative. I mean: if I find something that I don't like, it's more productive to talk about it directly with Mathias Nillson than to spend a day to write a review.
Generally speaking, I don't believe in open source, I don't see how it might work. Pick any example of a moderately large project: how many people can safely modify it? Normally, it's only the original author. In practice, it makes little difference if the source is open or not.
In this particular case, the software is written with MATLAB, which I haven't, but it would be the same if it was written in a language I am familiar with.
To be continued...