A strange date & time bug

[birgirbaldursson]

Hi folks,

I'm a new user of Mixbus. I bought the 32c version and I absolutely love it, even though I've come across some minor bugs. The most annoying of them is this one:

   

The whole point of snapshots should be the convenience of going back to older mixes, let's say the one that we exported yesterday around 6 pm, before continuing and screwing things up. But when I look up the date and time on my favored snapshot (can't remember what session name I gave it) I suddenly realize I have saved them all sometime in the distant future. The dates are off by some decades and aren't even consistent. Neither do the time stamps show the actual time of the day when snapshots were taken.

And by the way, my computer clock is showing the right date and time.

Do you think you can fix this for the next update, please?

Birgir Baldursson

[x42]

Which version of Windows is that? and which version of Mixbus (Menu > Help > About) ? 32bit Mixbus on 64bit Windows perhaps?

Best contact Harrison support by email (mixbus @ harrisonconsoles . com). While the forum is handy to check if other users have the same issue, it does not allow to triage and keep track of bugs.

Can you check in the Windows-Explorer that the file modification date is set properly. Right click on one of the "*.ardour" snapshot files in the Session dir > Properties
Near the bottom of the properties window, there should be a list of times (created, last modified, last read).

[johne53]

Robin - there's a bug in the way Windows formats time strings (I've pushed a small fix so you can see what I mean).

Assuming it works, it's likely there'll be other places where the same fix is needed...

[x42]

johne53: we use "stat" and "stat64" (actually the glib wrappers, glibmm has issues with this for 32bit versions on 64bit systems -- see libs/pbd/pbd/gstdio_compat.h) then again it may indeed only be a formatting problem

[birgirbaldursson]

Thanks four your response.

The properties window of the .ardour files shows the correct date and time.

I am using 32c 64-bit version on Windows 7 Ultimate:

Help-About:

"Mixbus 32C 3.6.0
(rev 3.6)
Intel 64-bit"

And by the way, x42, since you are a developer of this software, has somebody noticed that the tools tip window and the number-values on strip nameplates (mixer window) do not show up when the eq buttons and filter buttons are being manipulated? It works however on all buttons below the filters.

But anyway, I love the sound and the workflow of Mixbus and I intend to use it as my main DAW. Looking forward to the next update.

BB

[x42]

Thanks for the feedback. In that case likely John's fix will do it. We'll do a test build. Please contact harrison support by email for a download link.

Has somebody noticed that the tools tip window and the number-values on strip nameplates (mixer window) do not show up when the eq buttons and filter buttons are being manipulated? It works however on all buttons below the filters.

Yes this is intentional. Ben elaborated on in this in some other thread here (early 32C release announcement). In short: There is no easy way to display an accurate numeric (digital) value for those separate EQ controls and the given EQ model.

[birgirbaldursson]

I see. And when getting yourself a copy of Mixbus you are buying into that analog feel that comes with it. I guess that not having exact frequency values when fiddling with the knobs gives you a more believable experience. It's just like back in the old days.

Thanks for fast replies and good communication.

[dustinnr]

I'm curious - do people want frequency values, or simply values that are repeatable?
If the latter, than a direct encoder value, or a relation to top-center in degrees would work just as well (though probably be even harder to explain).

In general, one of the things I really like about MB is that most of its controls are set up so that the resolution makes sense for the intended use. Or to put it another way, the full range of the control is not so extreme as to cause a resolution problem in the most-used range. This makes it much easier to not worry about the exact position of the control; setting the EQ knob to a visual "1 o'clock" is good enough. Like, say, on a hardware console.