Saturday, March 31, 2012

Sequencing "Darkness" / 2

Having nothing better to do this morning, I decided to record vocals for my cover of Van der Graaf Generator's "Darkness". The first and third verses went well enough but I had several problems with the second verse, requiring several takes. I then 'comped' the vocal track and put it through the pitch corrector. The original song is in the key of E; this was too high for me so I dropped my version down to C. Whilst some parts were easier to sing, I found myself having to reach for the C# an octave above middle C. I just about got there (and of course the pitch correction software helped) but those high notes have no power.

Whilst mixing the song, I decided to make a change in the music track: this has a flute on the right hand side and a French horn on the left. During the instrumental solo, I thought it would be a good idea to exchange the instruments' stereo placement, which required a little mixer automation.

The vocal, as always, sounded too polite (partially due to the high notes). It sounded good in mono so I didn't use my usual technique of recording in stereo and delaying one side by 50-60 milliseconds. In order to get parts of the vocal sounding more evil, I copied the vocal track to a new file, silenced the parts which I didn't need, converted the file into stereo, added a little delay on one channel and then flanged the track. The idea of the above is to thicken the vocal track at specific parts, adding a little distortion. The result is interesting but not exactly what I was looking for.

I uploaded the track to the Internet; it can be downloaded here.

After listening a few more times to the track, I came to the unavoidable conclusion that the song is still pitched too high. I transposed the song down another three semitones (it's now in A) and created a new music track. I'll listen and get acquainted with it before trying to rerecord the vocals.


Thursday, March 29, 2012

Nobel prize winner visits MBA


Wednesday evening is MBA evening this semester; unfortunately I seem to have been cursed and have managed to make only five out of eight meetings.

While waiting for our lecturer to appear, I noticed further down the hall a tall and distinguished gentleman holding a conversation with the lecturer in Economics. It took me a moment to place his face; unless I am much mistaken, I was looking at Professor Daniel Shechtman, who won the 2011 Nobel Prize for Chemistry. 

This is most peculiar, as I can't imagine why such a distinguished academic would show his face in a somewhat run-down institution (whilst we learn a British curriculum run by a British university, our lectures are held in an Israeli college whose rooms have seen better days), especially as we are a business school and he is pure science. Maybe he was a childhood friend of the Economics lecturer?

To my regret, I didn't approach him, primarily because I had nothing to say to him except 'what an honour'. And what if it wasn't him? 

Sunday, March 25, 2012

Pharyngitis, Darkness

I spent most of last week resting at home, after having been diagnosed with pharyngitis. As part of the public service, "Learn something new each day", I discovered that pharyngitis and tonsillitis are both infections in the throat that cause inflammation. If the tonsils are primarily affected, it is called tonsillitis. If the throat is primarily affected, it is called pharyngitis (I didn't know what the difference between the two types of infection was).

My throat had felt like it was participating in a sword-fight every time I swallowed; funnily enough, talking seemed to alleviate the pain (and I had to talk a lot last Sunday and Monday). But by Tuesday I was feeling very weak so I managed to drag myself to the clinic where I was diagnosed (without a throat swab, I note). The doctor prescribed antibiotics and pseudoephedrine, which was supposed to act as a nasal decongestant.

Fortunately, I didn't run a high temperature; most of the time I simply felt weak, along with great difficulty in swallowing and producing large amounts of mucus from my nose. I could also barely speak.

I spent the time by working from home, reading and by completing a new cover version of a Van der Graaf Generator song, "Darkness". I found a version which I had sequenced once, which was about 90% complete. Unfortunately, I apparently had aimed at sequencing the song as it was played (including double sax parts) as opposed to creating my own version of the song, so after I completed the copy, I then started a new version which borrowed only slightly from the original. This alternate version is much lighter than the original, which is just as well, as one couldn't really create a darker version had one tried.

Looking at this song now, some 41 years after having heard it for the first time, I am struck by how much it displays Peter Hammill's unconventional approach to chord sequences. There is nary a minor chord to be found, but there are almost all the major chords based on the white keys; the song is in E and features E, F, G, A, C and D. Note that the dominant fifth chord, B, does not appear. 

When I sequence a song, I first get its structure correct, then start adding fills and solos. This latter stage can last a long time, as I listen to the song repeatedly and get new ideas. When taking the dog for a walk (I was feeling a little better at that time), I played the song once more in my head and noticed a similarity between a few bars of 'Darkness' and 'Something in the air' (Thunderclap Newman). I immediately took the instrumental part of SITA for those bars and pasted them in to the corresponding place in 'Darkness'; that part has always reminded me of the Marseillaise, which I took as a musical joke aimed at 'All you need is love'. If so, then I am prolonging the joke. I don't know whether the casual listener would be aware of the quote; at the moment, my ears are sensitised to this lick and so it stands out.

Due to my illness, I have yet to record a vocal, although paradoxically the sound emanating from my throat might sound better than my normal singing voice.


Friday, March 16, 2012

Rubber duck debugging

I was reading yesterday about Rubber Duck Debugging, in the context of Stack Overflow. The scenario, which has happened to me several times, is as follows:
  • Programmer is stuck
  • Programmer writes a description of the problem to a help desk
  • Whilst writing the description, the programmer realises what the problem is and how to fix it
  • Programmer deletes the letter to the help desk
I went through a version of this today; following is the background. For one customer, we have to print sticky labels with identifying details on the label (this of course is not a problem). The problems start when one of our factories produces three sub-assemblies which together make up the part which the customer ordered. My program was printing three labels (so far, so good), but I was asked to serialise them (which means printing on the first label 1/3, printing 2/3 on the second label, and 3/3 on the third label).

The external program which we use to print the labels has the capability of serialisation, but this is slightly limited. Let's say that I had to print two labels for one part and another two labels for a second part. The labels should bear the tags 1/2, 2/2, 1/2, 2/2. Unfortunately, the external program was printing like this: 1/2, 2/2, 3/2, 4/2. No matter what combination of flags I tried, I was unable to print what I wanted.

Then I called the help desk - they noted my details but promised nothing.

Thinking about the problem a little more, I came to the solution. The ERP program was inserting into the 'labels' table two rows, where each row was to be printed twice. The simple fix was to insert into the table one row for every label to be printed, where each row would be printed once. I also included the total amount of labels to be printed for each part (I know that this is a seriously muddled explanation, but all will soon become clear). Now I get the results that I want.

Before:
Part numberQuantity
1232
5672

After:
Part numberQuantityNumeratorTotal
123112
123122
567112
567122

All I needed was the metaphorical (apocryphal?) rubber duck in order to look at the problem from a slightly different angle and so find the solution. All of these problems (like the Excel comments problem which I wrote about the other day) seem totally trivial after they have been solved, but they are very confusing beforehand.

Thursday, March 15, 2012

Sequencing "Lost" / 2

I had some spare time recently so I thought that I would try to record some vocals for my version of Peter Hammill's epic song "Lost". We had three power cuts on the first evening when I tried recording (there was a ferocious storm raging outside) and most of what I recorded was not worth keeping. After an hour of frustration, I realised that fate was against me and so abandoned any further attempts.

I had another go at recording the vocals last Saturday, in a break from revising about negotiation. The only conclusion which I had made from my previous abortive session was that the song was too slow; I increased the speed from 80bpm to 84bpm, which may not seem much but made it much easier to sing.

I then proceeded to record an almost complete take, only to stumble over the words in the final verse. So I recorded the final verse again, mixed the two together, deleted the original .... and discovered that I had muted the almost complete take, resulting in a composite vocal of the last verse only. Gnashing of teeth. This first take, however, served to warm up my throat, and and I recorded a complete second take shortly after, complete with minor sound effects such as the dog barking, my stomach growling and what sounds like the door to the balcony being opened. I was able to silence most of the dog's barking and my stomach; the aural artifacts that remain can only be heard when the vocal is soloed in the mix.

I have begun using pitch correction software - I have a tendency to sing about half a semitone flat - and it seems that this program can't handle lengthy files (the take lasted about 10 minutes, which means that it was about 50 MB in length - recorded in mono). At first I wasn't sure what to do, but later I had the idea of copying the original vocal file into several sections (carefully noting the offset of each section from the file's beginning), correcting each section  and then stitching the five resulting files back together. This plan worked admirably, although every file started playing a few milliseconds too soon; moving them in time was easily achieved.

Once I had all the pitch corrected files playing at the right time, it was only a small matter to create a composite file (without deleting the originals!) which became my master vocal take for compression, eq and reverb. As usual, it was very difficult to find the right eq settings; I have been using a new microphone which supplies completely different tonal qualities to my previous one and I have yet to settle on standard equalisation settings. Eventually I decided to add a strong treble boost which provides a nice sound - it doesn't sound very much like me, but that's not too important. I always find mixing vocals and music very hard; I work on it for an hour, create a finished mix, do something else for an hour and then return to the mix.

I finally settled on a mix which satisfied several rounds of listening (each time lowering the level of the vocal); I uploaded this to a file server and notified the PH mailing group. So far, the response has been encouraging; those that have commented have noted that my arrangement is different but interesting (including the vocals).

This version can be found here.

Of course, after having uploaded what was supposed to be the final version, I had some more ideas which I have yet to check. One of them involves playing the tune to a later Peter Hammill song, 'Masks'. There's an instrumental lick played at one point which reminded me later of 'Masks' and changing the lick to the 'Masks' melody should be simple - although it will involve a slight harmonic change. Another idea involves inserting a few more bars into an instrumental break in order to enhance the dynamics - I don't know how this is going to work yet. It will also involve adding some silence into the vocal file. Normally I don't care for the 'digital razor blade' but adding four bars of silence (at 84bpm, 16 beats should last 11.429 seconds) shouldn't be too difficult.

Tuesday, March 13, 2012

Post mortem on the Negotiation exam

If I am ever to be found walking the Tel Aviv boulevards on a sunny, spring day, with only happy thoughts in my mind, then it's a sign that I've completed another exam in my MBA course. Today's exam was on Negotiation, a subject which I don't seem to have written much about. Almost all of the lectures were held in December/January, leaving us six weeks in which to forget the material. About three weeks ago, I started revising, and I was pleased to note that I remembered most of the material. Since then, I've been working on specific points and looking at previous exam papers, in order to see what is required.

The exam is structured in the following manner: the opening case study has five small questions, each worth eight marks. After that, there are three essay questions, each worth twenty marks. The first three questions regarding the case study are almost always the same, so these can be learnt by heart, although obviously the data has to come from the case study. The latter two questions come from a slightly wider pool but these also can easily be memorised.

And so it was today: the case study was about a French company contracting with a British company who would provide training courses. A day before the agreement was to be signed, the French company sent an email which basically reneged on all the terms of the agreement. What are the interests of both sides? What are the negotiating issues? What is Negotek and how can it help? These questions were like an arcade game: I wrote the answers and could hear in my mind how my score was steadily increasing, ching ching! The fourth question was about the email - a clear case of closing stage manipulation to my mind. I wrote about this subject at a deeper level than the previous questions, ching ching! The final question of this section was about each side's BATNA (Best Alternative To a Negotiated Agreement) - also easy, ching ching!

The first essay question required us to contrast Fisher and Ury's "Principled Negotiation" with Kennedy's "four stage plan", specifically in the context of negotiations between management and workers in a factory about a pay rise. Since I had gone over the four points of F&U with a fellow student five minutes before entering the exam room, this material was extremely well known. Ching ching ching!

The final two questions were slightly awkward in that in first reading, it wasn't clear what they were about. After reading them through a few times, I noticed that the clue to both was in the final sentence. Unless I am very much mistaken, the penultimate question was about constructive/destructive behaviour (Carlyle and Rackham), whereas the final question was about the ten ways to making decisions. I wouldn't say that the arcade game was going ching! ching! ching! as I wrote my answers, but I should have done well on these questions.

Summing up, it looks like that I did very well on this exam, which would be somewhat ironic as it is a subject not close to my heart. On the other hand, appearances can be deceptive and the examiner may be more balanced regarding my mark. I'll know in about six weeks.

All that is left is Strategic planning.....

Monday, March 12, 2012

Proposed doctorate

After posting my previous blog, I realised that I hadn't updated my readers why the tags for it were DBA (Doctorate of Business Administration) and ERP (Enterprise Resource Planning). I wrote about a year ago about working towards a doctorate, where my subject was to be areas in which the classical model of ERP fails. But after a few months of cogitation, I concluded that I was able to find solutions for these areas of ERP failure, and so I needed to find a new subject.

This wasn't too hard as I shortly came across an article entitled Attack of the killer spreadsheet which was very much aligned with my own thinking. To quote some of the article,
The really important thing to remember about spreadsheets  is they are not the companies ERP system. The company ERP/MRP system must always remain the backbone, the main data repository, the source for management information and where business transactions and processes are recorded and tracked.

But what’s wrong with spreadsheets – I hear you ask? Well, the way most spreadsheets are configured means that they miss fundamental (and critically important) ingredients that most ERP’s are equipped with out of the box!

Improper use of spreadsheets often stems from a perceived lack of functionality within the ERP system or a work around where the ERP logic isn’t aligned to way the company wants to operate. Often the easiest, or the perceived easiest, method of fixing that is to “plug” a spreadsheet in to solve the problem. We’ve all seen these out in the field and their function can vary from a simple list (my ERP doesn’t record all the data I need) to acting as an EDI interface between a customer and supplier ERP system.

On this basis, I put together a doctoral proposal, part of which currently reads as follows:
ERP programs are packaged with reporting systems of various level of complexity and capability; these systems are normally based on SQL (Structured Query Language), a database computer language designed for managing data in relational database management systems. The use of SQL is normally the province of IT professionals who configure and support the ERP programs; the end user is dependent upon the professionals and rarely has the ability to create reports of her own within the system.

In order to circumvent this inability – and for other reasons – the use of Microsoft Excel is prevalent within organisations using ERP. The use of Excel can both help and hinder the effectiveness of ERP systems: "when employees use spreadsheets, they create the very problems that ERP systems are meant to address: silos of data, inconsistent information, manual tracking of information and broken business processes".

I propose to investigate the use of Excel in organisations using ERP in an attempt to determine whether Excel does indeed help or hinder; it may well be that certain functionality helps whereas other functionalities hinder.

I propose to ascertain this by conducting interviews with users of ERP/Excel. The majority of the interviews will be conducted with users of the Israeli developed Priority ERP system, as I am most familiar with this product. I intend, however, to conduct interviews with users of ERP systems such as SAP, Baan and Kav (another Israeli product). I also intend to conduct interviews with Priority users in Britain and possibly other countries. These interviews will enable me to determine whether the efficacy of Excel depends on the user's level of sophistication (and knowledge of her ERP system), on the ERP program or on the national culture.

So, whenever there's a blog entry about someone intending to do something in Excel and me suggesting that they do that something in Priority, know that this is connected with my (proposed) doctorate, hence the DBA tag.

Although I have applied to the DBA programme at Heriot Watt University, I have yet to be accepted, as the accepting committee will only discuss my application after I complete my MBA degree.

Another example of Excel usage

My company frequently sends chairs as examples to customers; the customers can use the chair for a period and in so doing 'get a feel' for the chair. Hopefully, a sale will result from this trial period. Even more hopefully, we will collect the example from the customer. Unfortunately, we don't have a very good record for collecting, although that has been improving lately.

Each example is sent with a delivery note; Priority (our ERP system) can track the delivery notes and can also determine which examples are still extant, yet to be returned. Today, those who are supposed to be collecting the examples decided that they would improve their performance by keeping a record of their contacts with customers who have extant examples.

I was asked how they could create the non-returned examples report in Excel; I explained how to do this. Then I was told that they intended to add comments about each example within the spreadsheet. The red light above my head immediately turned itself on.

Looking at the delivery note screen in Priority, I saw that there was an accompanying 'task log' screen which could maintain all the comments for each delivery note. The existing report would need to be modified to add the new data, but that would be a trivial matter. 

So, instead of a spreadsheet which might be passed from hand to hand, which everyone can edit (but no track is kept of who added what), which might get lost, damaged or exist in several versions, we now have an elegant database report which contains the same information, is accessible to all, has its changes logged, will always be up to date and will never be damaged. The user has to perform the same amount of work (if not less) to add the comment to the database. As far as I am concerned, this is an all-around win situation.

To be fair, my solution was enthusiastically accepted and adopted.

The solution this time was trivial, but that's not the point. The point is that when something has to be documented for the first time, people automatically think of using Excel! Of course, Microsoft  don't get a royalty for every spreadsheet which gets opened, but they must be pleased at the amount of market penetration that their product has achieved.

Thursday, March 08, 2012

House with no door / 2

I've been very tied up with family problems in the past week and will probably continue to be tied up for another week so I haven't got much time nor mental energy to devote to blogging. I do have enough time and energy to blog this scrap, though.

Continuing the discussion about the authorship of 'House with no door', I had occasion to look at the cd sleeve and the songwriting credits, which are as follows (original orthography)
Killer (Hammill/Banton/Smith)
House with no door (Hammill.........Jackson)
The Emperor in his war room (Hammill)
Lost (Hammill)
Pioneers over c (Hammill/Jackson.........Band)
As we know that Killer was definitely a joint composition, one can assume that the use of the slash (/) means that the songwriting credit is shared - thus 'Pioneers' was definitely written by Hammill/Jackson. One can assume that the use of the ellipsis (.....) indicates an arranging credit: thus 'Pioneers' was written by H/J and arranged by the band. Hence 'House' was written by Hammill but 'arranged' by Jackson - this is how his instrumental woodwind arrangement was credited.

Saturday, March 03, 2012

Incremental search in a combo box

Lately, I have increased the use of combo boxes in my programs and it has come to my attention that I sorely need incremental search. A standard combo box finds strings according to the first letter only - if the user presses 'b', then the combo box finds the first string which starts with a 'b', but should the user then press 'r' (let's assume that he's looking for 'brian'), the combo box jumps to the first string which starts with 'r'. Incremental search would cause the combo box to find the first string which starts 'br'.

Obviously some functionality has to be overloaded, but it's not clear exactly what. Googling doesn't bring up many possibilities; here is one of the more complete versions which I found.

procedure TMainForm.DocEntryCBEnter(Sender: TObject);
begin
 GS := '';
 GCOUNT := 0;
 TComboBox(Sender).ItemIndex := 0;
end;

procedure TMainForm.DocEntryCBKeyPress(Sender: TObject; var Key: Char);
begin
 AutoMatch(TComboBox(Sender), Key);
end;

procedure AutoMatch(cbo: TComboBox; var keyascii: char);
var
 sbuffer: pchar;
 s: string;
 retval: longint;

begin
 getmem (sbuffer, 255);
 if Keyascii = #8 then
  begin
   dec (GCOUNT);
   s := copy (GS, 1, GCOUNT);
  end
 else
  s := copy (GS, 1, GCOUNT) + (Keyascii);

 try
  strpcopy (sbuffer, s);
  retval := sendmessage (cbo.Handle, CB_FINDSTRING, word(-1), longint (sbuffer));
  if retval <> CB_ERR then
   begin
    cbo.ItemIndex := Retval;
    GS := cbo.Text;
    Inc (GCOUNT);
    Keyascii := chr (0);
   end
  else
   begin
    messagebeep (0);
    cbo.Text := GS;
   end;
 finally
  freemem (sbuffer, 255);
 end;
end;
Whilst this code includes some nice ideas and looks impressive, it transpires that there are several lines which are inefficient and a few which are simply wrong. At first, I thought that the AutoMatch procedure ought to be part of the DocEntryCBKeyPress code, but it is written cleverly in such a way that it can handle a multitude of combo boxes - or not, as the accumulated string gs would be common to all the combo boxes, when in fact it should be separate.

The first inefficiency is creating a temporary buffer of 256 characters every time the user presses a key (this is the call to 'getmem'). Why not create a permanent buffer for the combo box in the same way that the variable gs is created? But why even do that? This buffer is only required as a parameter to the SendMessage, and it seems that the writer had only an incomplete knowledge of type casting - whilst he type casts the pchar (sbuffer) to a longint (as required for the fourth parameter of SendMessage), he could also have typecast the gs string to a pchar - thus obviating the need for sbuffer, along with its allocation and deallocation.

It also seems that the writer had never heard of string concatenation - he can simply add the new keystroke to the accumulated string (gs) without having to use the 'copy' function.

There is an error in the line which handles the 'backspace' keystroke (#8): should the first key to be pressed be backspace (however illogical this may be), gcount will logically receive the value -1, which will probably be rounded to 65535. Instant memory problems!

The other mistake which I found only became clear after using the code - let's say the user presses 'b' (whilst looking for 'brian'). The call to SendMessage will succeed; the line cbo.ItemIndex := Retval means the combo box will display the first string which starts with 'b' and then the accumulated string is set to this value. Let's say that the found string was 'Bobby'; now the accumulated string will be 'Bobby'; when the user presses 'r', the accumulated string will now be 'Bobbyr', which presumably will not match anything!

My code looks like this:
Procedure IncCBKeyPress (cb: TComboBox; var key: char; var fsaved: string);
var
 retval: longint;
 len: word;

begin
 len:= length (fsaved);
 if (Key = #8) and (len > 0)
  then setlength (fsaved, len - 1)
  else fsaved:= fsaved + key;
 retval:= sendmessage (cb.Handle, CB_FINDSTRING, -1, Longint(PChar(fsaved)));
 if retval <> CB_ERR then
  begin
   cb.ItemIndex:= Retval;
   key:= #0
  end
 else
  begin
   messagebeep (0);
   cb.itemindex:= 0;
   fsaved:= '';
  end;
end;
I've changed the variable names slightly - what was gs has now become fsaved. This is in preparation of creating a new TIncComboBox component. This code can definitely be shared between several combo boxes as the accumulated string is passed as a parameter.