[Halda]

This looks great! Looking forward to future development.

I'm also on OS X, and can confirm it working on OS X 10.11 El Capitan.

The instructions posted above by Baillive does work, but note that you have to first install the required libraries via Brew before you can run the pre-compiled app. If we want a full stand-alone OS X app, it needs packaging together with GTK+ etc.

Some feedback on the amplitude discussion: I think it should be displayed like most other Timegraphers do. Check the Witschi technical paper. Their description of the amplitude makes it seem that they only measure the tic OR the toc pulses. I.e. the 1st and 3rd pulse OR 2nd and 4th. It's not entirely clear if the value they display is the average, but it does look like that. They also display the standard deviation, which is a nice extra.

BTW: If the amplitude measurements are different between tics/tocs that would mean the watch is out of beat, right?

 

[Halda]

Several people have mentioned microphones and amplifiers; There's another DIY Timegrapher software that has instructions for constructing both a mic and amp. Website here.

(The drawback with that software is that it's Windows only, so I have never tried it out myself.)

 

[Halda]

I was going to do a small UI suggestion and ask for the data fields in the same order as real machines, but when checking I realized they are not all the same.

The original red Witschi Watch Expert had the fields as: RATE - BEAT ERROR - AMPLITUDE (and bph & lift angle at the bottom)

Witschi Watch Expert III has: RATE - AMPLITUDE - BEAT ERROR (and at the bottom CALIBER PARAMETERS, with bph & lift angle)

The Chinese Timegraphers are: RATE - AMPLITUDE - BEAT ERROR - PARAMETERS (bph / lift angle)

I guess the common order is to have the amplitude before the beat error, so maybe those could be switched around. Perhaps the bph reading could be moved out to after the bph setting above, since it's not something that will change.

 

[Halda]

I tried to compile the latest update on my Mac (OS X 10.11.1) and it fails at "#include <cairo/cairo-ft.h>"
If I change it to "#include <cairo-ft.h>" it works. Any ideas why?

Anyways, I'm getting the same error as Baillive does for what it's worth.

Edit: I did some further debugging this morning and found that using the full path to the font file in FT_New_Face will make the error go away, so it must be a problem with locating the file.

I'm not sure where Freetype is looking for relative file names, but changing #define INTERFACE_FONT "VeraMono.ttf" to "./VeraMono.ttf" will fix the problem on Mac (assuming the font is located next to the executable).

However, no text will show up in the interface. The FreeType font does seem to load properly because it reports a valid number of glyphs available etc.

I did manage to get text showing up by replacing cairo_set_font_face(c,cr_face) in cairo_init with something that didn't use that specific font:

cairo_select_font_face (c, "sans-serif", CAIRO_FONT_SLANT_NORMAL, CAIRO_FONT_WEIGHT_NORMAL);

 

[Halda]

It would great if you could try again, but I believe that the same result will follow (no text visible).

The updated code compiles fine now, and it does load the font file. |> You're right that the result is the same though, no visible text showing...

I haven't worked with any of these libraries before, but my guess would be that Cairo is to blame. Maybe the conversion from Freetype doesn't work or it needs more initialisation? Is there a way to probe the cr_face object for details? I checked the cairo_text_extents during the text rendering and it reported a height of 0, which might be a clue?

 

[Halda]

Another weird thing happening when the text won't show up is that not all lines in the interface renders:

Some further tests show that if I disable all cairo_show_text calls in expose_waveform then the lines will show up. So there's definitely something weird happening when trying to show text.
I also noticed that the line width changes to 2.0 after the failed calls to cairo_show_text (instead of the expected 1.0).

 

[Halda]

Font file corrupted? The md5 of mine is 37d8aff129ecd7d3fc495b7239f834db.

Yep, same md5 here. Font shows up fine in the OS inspectors too.

As an experiment I tried to set cr_face to NULL and, on debian, cairo just reverts to the default.

I tried that too and it seems to revert to some default because now text shows up.

I also tested to use another random ttf file (from Microsoft) and it failed in the same way; no text shows up. Looks like something goes wrong with cairo_ft_font_face_create_for_ft_face()

 

[Halda]

I tried version 0.2.3 on Windows 10 Pro (version 1511) and it worked fine. The Microsoft LifeCam Cinema webcam picked up a signal after pressing the watch crystal against the microphone. :-!

 

[Halda]

Trying to build under OS X just turned into a huge waste of time. (There seems to be something odd with the specification of the ffwt3 library.)

For OS X the instructions and binary here will work.

 

[Halda]

I am very much unfamiliar with commando's and such, and have tried to search for answers online, but after many hours looking and trying I just decided to post my problem as there might be others too who encountered this problem.

You're almost there! In Terminal, simply go to the directory where the downloaded source code is (by using the cd command). Then enter the command make.

This should invoke the compiler and produce the executable for you. Good luck!

 

[Halda]

If you don't have a microphone yet but still want to try out tg on your Mac there are tools that will allow you to route the audio from other apps into a "virtual microphone" so you can for example play a YouTube clip of a ticking watch and have tg analyze that audio as if it was coming from a microphone.

There's an old free app called Soundflower that allows you to do that, and also a brand new one (but not free) called Loopback.

 

[Halda]

How accurate measurements have you got with this software? I've been using it for about 3 months and it seems to be very good, but are those readings close to professional timegraphers measurements?

The calculations are probably as accurate as "professional" timers, at least for the rate and beat error values. There might be some disparity with the amplitude calculations at the moment. If so, it will probably be fixed. It's a new feature and still in beta after all.

However, there's no calibration implemented yet. So the accuracy of the numbers you get will depend on how well your sound card performs.

 

[Halda]

When I try to use a mono microphone (a piezoelectric) I get this error

This is caused by tg requesting a stereo input source. It looks like it can be fixed by having tg ask for a mono input instead since it doesn't seem to actually use the stereo data.

 

[Halda]

If I ask for just 1 channel (either by checking the number available or forcing it) I get no signal whatsoever.

You also need to change some other Portaudio parts that handle the incoming signal. The code currently assumes two channels and will generate garbled data if just fed mono. Easy enough to fix, but perhaps contrate_wheel will chime in with the best way to do it in case the algorithm also relies on stereo data.

 

[Halda]

Re: Ace Timer No. 1000 Timegrapher comparison #2

I'd like to explicitly note that tg consistently gives a reading of +4s/d higher than the Ace Timer. It may vary from +3 to +5, but after stabilization it always settles in around that same difference. That's a clue to something though I'm not sure what.

This is expected because tg currently doesn't have a calibration option. PC sound cards are usually not exact enough, and will give more or less invalid results. However, the error rate is always stable. In your case it seems to be about 4 sec/day. Once tg implements the ability to adjust the rate calculations, it should match up perfectly.