I have some display issues when the number of track is larger than my screen.
When I use the scroll bar to display the last tracks, the following happen :
I am running on UbuntuStudio Karmic 32bits.
This problem appears with the version 2.8.2 installed from the ubuntu classic repository, but I tried with the 2.8.7 version compiled by myself, and the problem is still present.
I guess that it might be a problem caused by my laptop and not Ardour, but I wonder if somebody have ever had the same problem, and know how to fix it. I cannot find any related topic anywhere.
Yes I think this is certainly an issue with screen resolution. If I use a computer with a larger screen, there is no issue. Is there any way to simply make Ardour think my screen is bigger? I can deal with it not fitting on-screen, but the graphics glitch makes Ardour and sadly Mixbus completely unusable. I’ve been using them both on other computers, to the point where I am finding it necessary to donate, but I really need to be able to use this software in a more portable manor.
Is there a bug tracker entry for this? I would like to sponsor it getting fixed. I’m new around here so please forgive my noobness.
Going off memory, the minimum supported resolution for Ardour is 1024x768. Again that is off memory but I am fairly confident in that. While there is a mode to allow for usage on smaller screens, it is not officially supported by the Ardour dev team, again going off memory.
So short answer is that unfortunately it may not be changed in the near future, but you can certainly put in a Mantis issue for it if you wish, it will show that there is some desire for it at least.
Looks more like a graphics card issue. A little more info on hardware would help.
If you run Ubuntu Studio, chances are you are running a Real Time kernel, and if you do have a high end graphics card, installing proper drivers for that card and prioritizing the card with rtirq just below your default audio card will help.
I’ve run into the same issue on my Asus EEE 901 GO with a resolution of 1024x600. Both ardour 2.8.9 (with and without -ardourino parameter) from the Debian repos and ardour 2.8.11 compiled from source show those rendering errors.
My Kernel is 2.6.32 (standard Debian, non-realtime), grafics card is an Intel Mobile 945GME Express Integrated Graphics Controller. Haven’t had any driver issues, Compositing in XFCE is turned on and works well, turning it off does not resolve the error. The only way i can see the tracks below the scroll threshold is to pull the ardour window big enough (a very lot bigger than my screen size) to show all tracks at once and then move the window with Alt + Left-Mouse to focus on the parts I want to edit.
If I had to guess I’d say it looks like a gtk related error, the lower tracks parts are not being repainted properly.
Hello,
I really like Ardour and Mixbus. I would love to buy Mixbus and donate 100 bucks to Ardour, but this bug throws a wrench into everything. I’m not even sure if it’s Ardour or if its the driver or window manager or what, but it makes things very exciting to say the least…
Im running 10.04 Ubuntu desktop 32-bit with the latest kernel and Ardour builds.My screen resolution is 1024x600.
Seablade, I believe that you are correct. However, and correct me if i’m wrong, I also believe that the main reason that 1024x768 is the minimum is more due to the fact that the elements of the mixer will not fit if the resolution is less. I’m sure this is part of the hesitation in lowering the minimum resolution. Using Ardourino as an example its easy to see why it is a big undertaking. Rearranging and even eliminating mixer elements id not cool.
However, I’m not asking or even wanting to actually lower the minimum resolution. I just want that edit window drawing bug to be fixed. I can deal with moving the windows around on my screen to see everything, in fact, I always stretch the windows out bigger that my screen and move them around as needed. What bugs me is that even when I stretch the window much larger than my screen, like 1280x1024, the bug still exists even though the window is larger than the advertised minimum resolution.
I’m about to do some lectures on recording and I’m doing a section on Linux because I think Jack and Ardour most closely relate to the patch-bay and routing standards of an analog studio. I’ll be doing some work on various projectors, some of which may be below the minimum. It’s a school, so I have little control over presentation equipment.
Even if I could fool Ardour into thinking my screen is 1024x768, I would be perfectly content. It doesn’t need to fit, it just needs to draw the window correctly. How does Ardour learn of the screen resolution?
I don’t believe Ardour does learn of the screen resolution, it only worries about the window resolution.
My point was more that a 600px height may be what is triggering this behavior in some way, but I am not sure exactly how. While I have seen the redraw issue that is being discussed, i have not seen it in a while(Meaning several Ardour versions), but I have been using a screen that is much larger than the ones mentioned as well.
Since I assume from previous comments we are dealing with self-compiled builds that are likely SYSLIBS=0 I don’t know of much else that would explain these particular differences other than possibly graphical driver issues(Which honestly should fix themselves pretty quick if that was the case I believe).
Well it doesn’t matter how large I make the window, the graphics still glitch out. I can make the Ardour window 1440x1280 and I still see the bug on my netbook. Of course the netbook is only 1024x600, so I figured that I could just make the windows larger and that the problem would go away, but it has not. Either Ardour queries the screen resolution at startup or the bug crops up after the window has been at a resolution smaller than the minimum.
Or it is possible that I am wrong, has been known to happen:) It is more just because the common thread seems to be the netbooks with low resolution screens that I am leaning towards that playing a role, but it is more than possibly that it is just coincidence.
Hey I’m not tryin to prove you wrong or anything. I’m just really curious to know what the root cause of this issue is. Its strange that even when I stretch the window larger than the minimum supported resolution, im still stuck. The other thing to note is that my window placement is not saved when i close a project that has been stretched larger than the screen. Instead, when I reopen the session, the window is maximized to 1024x~700 (not quite fitting on the screen but not 768). I believe that this behavior may be part of the same mechanism that makes Ardour aware that the resolution is low. This may be a window manager issue. I tried switching Compiz off and using Metacity, but that did nothing.
@seablade: not true. what is true is that ardour can do no more than hint to the window manager about its preferrred size & position - the window manager might blatantly ignore the request, or subtly tweak the values, or use it as-is.
Thanks for all of the info! So Ardour polls the resolution on startup? What exactly does it query and can it be disabled or permanently set to a value?
Alternately, I there a way to add a key command to redraw the window?
