Yet another mp3 player

I last wrote on this topic at the end of August, exactly five months ago, saying "I have ordered yet another player from Ebay but this has yet to arrive so I can't comment on it". The player is a 4MB Ruizo: it has both internal memory and can accept a memory card. So loading this player simply involved me extracting the SD card from the Sansa Clip and inserting it into this player.

The good points of this player: it seems to run forever without being charged and it has a good sound. More importantly, it continues playing from exactly where it was when it was turned off, so theoretically this is the perfect mp3 player.

Why am I less than enthusiastic? The 'user interface' is extremely badly designed, seeming to me non-intuitive and inconsistent. When scrolling though a list, it seems obvious (to me, at least) to use the up and down arrows, but the interface requires using the left and right arrows. Every menu option seems to use the arrow keys in a different manner. Changing the volume is likely to succeed 50% of the time; the other 50% will do something random. I only discovered the 'continue playing from the same place' by serendipity a few weeks ago.

Another small but important point: the Sansa Clip had, as its name suggests, a clip which allows the player to be clipped on to a piece of clothing or to a belt. The Ruizo has a hole at the top which allows a lanyard (a piece of cord) to be attached; presumably this lanyard is then supposed to go around one's neck allowing the player to be like a medal. This is unsatisfactory. After thinking about this for a while, I realised that I can use a key chain - treat the player as a key, then hang the chain on my belt.

Since then I have ceased to use any of the player's options. I turn the player on - it starts from where it stopped previously. When I finish, I press on the round button in the middle for a long time (a few seconds). If I am lucky, there will appear on the screen 1 2 3; I continue to press on the round button until these figures disappear,  to be replaced by 'Bye bye'. I then turn off the player with the on/off switch. 

These simple operations give me what I need. Anything else is liable to pick a random song, or one which is much earlier in the playlist. As I have over a thousand songs on the card, I haven't got to the end yet, so I don't know whether the list will 'wrap around' and start again from the beginning. I'm not even sure if the songs are being played from the card or from internal memory; at one time I tried to set up a play list, but this seemed to play only songs from internal memory so I copied as many songs as I could from the card to the memory.

If it weren't for these interface problems, this would be an excellent player. A set of instructions came with the player, but these were largely incomprehensible, and as I wrote earlier, key usage is inconsistent. At the moment, this is the best player which I have, but it needs improvement.

Thank heaven for system restore

Yesterday ended with me writing "I posted a question on the program's support forum". Due to the day's frustration, I was pessimistic about the chances of receiving a useful reply. Someone did post an answer, most of which was about updating drivers and similar. But the first sentence was the key: restore the system from a system restore point.

I was pleased to discover that my computer creates a system restore point every morning, so I could restore everything to how it was yesterday at 6am. After rebooting, I started the multi-track program, and yes! There was now audible output through the computer's sound card.

For about ten minutes, I tried recording vocals with the microphone connected directly to the computer's sound card but this was not good. So I then connected the external sound card to a USB port, connected the headphones and microphones ... and was able to make very clear recordings.

I sang the song through once, which seemed to be sufficient. Just at the end of the first verse, my telephone beeped which caused me to record a 'drop in' on the final line. Whilst editing the sound file, I saw that the beep occurred just after my singing, so I was able to silence this without needing the drop in. I then spent an hour or so tuning the lead vocal as well as separating strategic parts so that I could create harmonies.

I'm now listening to the finished song and everything seems to be fine. I'll master a version and listen to that for the next few days.

Frustrating day

Yesterday I surprised myself slightly by writing the final verse to the song that I wrote about a few months ago. Every so often I would tinker with the arrangement slightly, but finding words - or even a topic - seemed to be beyond me. About a month ago, I managed to write almost two verses, but threw them out a day later as they seemed to be repeating lyrically what I had written in an earlier song and they sounded very false. Since then, I have managed to write a verse a week, and yesterday, as I mentioned above, I wrote the final verse.

Today I had plenty of time on my hands, so I thought that I would record the vocals. I setup the microphone on the mike stand, plugged in and recorded a few takes. When I listened to them, the tracks had a terrible audio quality, as if they had been recorded at the bottom of a big hole. No amount of equalisation could save them. So I exchanged the microphone and headphones for the combination phones/mike which I used for several years, and recorded a few more takes. Whilst these sounded better, they were still very boxy. OK: I tried yet another microphone which I have. Slightly better but still bad.

At this stage, it occurred to me that the problem might not be with the microphones but rather with the cheap external sound card which I am using, that allows me to connect the microphone and phones to the computer via a USB connector. Years ago, I used to be able to connect the microphone to my 'music' computer and record with the multi-track recording program which I have. At some stage, recordings made this way started sounding bad, which is when I started to use the external sound card with Audacity to record on a mobile computer. Maybe I could try recording directly again.

At this point, the multi-track software ceased working: I get error messages about the sound card not being able to handle input. I tried different configurations but was unable to hear anything from this program. I should point out that other programs - wave editors and mp3 players - work correctly. Strangely enough, I was even able to use the multi-track program to mix the tracks which I had created, although this was not a good idea as the vocal wasn't synchronised with the music, apart from the poor quality of the sound.

So not only did I waste several hours trying to get a good vocal sound, I also managed to ruin the setup of the program which I need in order to turn the vocals into something which sounds good. Very frustrating.

I posted a question on the program's support forum, but I am not optimistic about getting a useful answer, primarily because I am using a very old version of the program.

Validity styles

Over the past six months, one of the psychologists employed by the OP for whom I consult has been working on developing new models, which explain inter alia the 'validity style' of an examinee's responses. These can vary from 'random' (in which the examinee hits one key repeatedly without reading the questions) to 'honest' and on to 'normal' as a default value. The psychologist sent me a list of rules which enable the program which displays an examinee's results to determine the style. He wrote the rules in pseudo-code:

If (INF == extreme && IR == extreme) then return RANDOM.
If (INF == extreme) then return INFREQUENT.
If (IR == extreme) then return INCONSISTENT.
If (DEF == extreme || GI == extreme || 
    (DEF == borderline && GI == borderline)) then return FAKE_GOOD.
If (DEF == low) then return HONEST.
If (CM == extreme) then return UNCOMMON.
(Else) return UNCLASSIFIED.

I have implemented similar rule mechanisms in the past, but in each case they were always 'and' statements, like the first rule shown above. 'Or' statements seem to be more complicated, and 'short-circuit evaluation' should be used throughout. There was one rule which had both 'and' and 'or' statements which had me literally scratching my head how to implement this.

At one stage, I half seriously considered embedding a Prolog interpreter into the program, as these rules could easily be rephrased as Prolog rules, such as

random:- inf (extreme), it (extreme).
infrequent:- inf (extreme).
inconsistent:- ir (extreme).
fake_good:- def (extreme).
fake_good:- gi (extreme).
fake_good:- def (borderline), gi (borderline).
honest:- def (low).
uncommon:- cm (extreme).
unclassified:- true.

but I quickly backed down from this idea. The above mental exercise reminded me that in Prolog, 'or' statements are handled by having two similar rules. After this insight, it became easier to translate the rules into data stored in SQL tables.

Writing the interface code to store the rules was complicated as I identified three different possibilities: creating a rule with a clause, editing that clause and adding a new clause to an existing rule. Thus for 'or' statements, there would be two (or more) rules whereas an 'and' statement would require one rule with two (or more) clauses. Once I worked this out in my head, the implementation simplified.

Writing the code to evaluate the rules (the equivalent of a Prolog interpreter) took some time, primarily because I confused the short circuit evaluation with the value returned by the evaluation function as to whether a rule was proven. After debugging this code live several times, I finally figured out how it should be written. Testing the code on real data seemed to work, but in almost every case, the result was 'normal', which didn't really test anything.

So I added a 'validity style' field to the 'people' table and wrote an external program based on my code which would evaluate for all people who have been tested since 01/01/17 (about 4500 people) their validity style and store this value in the table. I ran the program then queried the table to find people who did not have a normal style. The result was no one, which I knew was incorrect. I went over the code line by line which seemed to be correct, but then I noticed that one query was not closed. This wouldn't make any difference if only one person is being tested (as in the production code), but for my testing code this was a bug. So I added the 'close' statement, ran the test again, and discovered the many people who have non-normal validity styles.

The next step is to check the complete output for these people in order to see whether the raw data supports the validity style. This isn't my problem.

Under pressure but trying to escape

I see that it's been a few weeks since I last posted something here. That doesn't surprise me very much as nothing particularly interesting has happened so far this month, and I've been under a great deal of pressure (or, quite possibly, created for myself the pressure). I have known for two weeks that there would be two difficult meetings in which I had to participate - one at home (kibbutz) and one at work; as it happened, they were held day after day. The meetings have now passed; I won't say that I came out of them unscathed, but at least they weren't as bad as I might have suspected.

Another weight on my mind has been my doctorate: specifically, a failure to chase after people in order to interview them. As it happens, yesterday I completed an interview with one of my (former) pupils then wrote up the interview. Apart from asking former pupils, I also send 'cold emails' to any Priority using company that orders from my company - I can see from their order form which program they are using. This morning I received an answer from one of these cold emails, that someone is prepared to be interviewed! I must follow this up and interview the person next week. I should point out for my readers that these interviews last for about an hour and are conducted by means of the telephone. I downloaded an app for my phone last week which automatically records telephone calls; this worked well yesterday. In the evening I copied the files (the interview was interrupted a few times) from the telephone to my computer; I then listened to the interview and filled out the written report, stopping the interview whenever necessary. I am also translating and paraphrasing as I write.

I have also been planning this year's holiday which will be in Greece: some time in Athens and some time in Andros, which is a very green island (as opposed to Santorini) which is close to the mainland (the ferry ride is 'only' two hours). After playing around with dates and flights, I was able to book the hotel which we wanted in Andros, but was unable to do so with my first and second choices of hotel in Athens. It seems that there is something important happening on May 22nd, because both hotels were full on that date but had rooms for the previous and following days. Anyway, I booked with a third hotel which looks reasonably good.

And somewhere in the background, I have been listening frequently to the song "We can be together" by Jefferson Airplane. I first heard this song some years ago after having downloaded the 'Volunteers' album but wasn't particularly impressed - the song shares the same opening riff with the song 'Volunteers'.  Somehow recently my attention returned to this song and I've been listening to it closely in the past few days. I especially like the vocal harmonies of the 'chorus' and also appreciate the cognitive dissonance between the singing and the words, especially those of the second 'chorus' ("Up against the wall..."). There is a live version of this song on YouTube from the Dick Cavett show, broadcast the day after Woodstock (August 19, 1969) which is quite infamous, as the song was broadcast without censorship (listen and you'll hear why).  

A very good article about this song can be read here. I listen to the music much more closely to the words and can see that the article mentioned above misses a few musical things. Musically, the live Cavett version is inferior to the studio version which is not too surprising as there are some very interesting rhythmic changes happening throughout the song, which get somewhat mangled when played live. Most of the song has a straight-forward 4/4 beat (and one clip shows drummer Spencer Dryden thumping his drums in a normal rock rhythm) but other parts have a slowed down, possibly 3/4, rhythm. 

An SQL trap and how to get out of it

Today I spent about two hours trying to debug a complicated Priority procedure. After about half an hour, I managed to determine exactly where the problem lay, but I couldn't figure out why there was a problem. As it's cold and wet outside, I couldn't get up and go for a walk, turning the problem over in my head. Having a break for lunch didn't help either.

Here's the problematic code

INSERT INTO GLOB_TMPTREE (FATHER, SON, PIS, ORDI, USER)
SELECT :PART, ORDERITEMS.PART, TEC_ORDIFEATURES.OPTIONCODE,
ORDERITEMS.ORDI, SQL.USER
FROM ORDERITEMS, TEC_ORDIFEATURES, TEC_FEATURES
WHERE ORDERITEMS.ORDI = TEC_ORDIFEATURES.ORDI
AND TEC_ORDIFEATURES.FEATURE = TEC_FEATURES.FEATURE
AND TEC_FEATURES.FEATURECODE = 'PIS'
AND ORDERITEMS.ORD = :ORD
AND ORDERITEMS.TEC_U1 = :U1
AND ORDERITEMS.TEC_U2 = :U2
AND ORDERITEMS.ORDI <> :XLINE;

Leaving aside the specific details of the query, I am selecting data then entering it into a table. I checked (several times) that the actual query was returning data; even so, it was not being inserted into the table. The line before the quoted passage deletes all the lines in the table belonging to the current user so there shouldn't be a problem in inserting the data.

With the benefit of 100% hindsight, I can now say: when an insert fails, check the table's primary key. In this case, the primary key was composed of father, son and pis; it so happened that another user had tried to run the procedure but for some reason, the procedure didn't complete and certainly didn't clear up after itself. There were lines in the table for this other user - and it turned out that the primary key values for these lines were exactly the same as the ones I was trying to insert.

When I finally got to this stage, I deleted all the lines in the table (this is only a temporary table with a few lines at most); I then ran the procedure, and unsurprisingly it did exactly what it was supposed to do. I then added the 'user' field to the primary key which should prevent the same error from happening again.

So: when an insert fails, check the table's primary key! Maybe next time I'll remember this.