On June 15, 2010 02:40:30 pm James Morris wrote:
On 15 June 2010 16:55, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
On Tue, Jun 15, 2010 at 11:27 AM, James Morris
<james(a)jwm-art.net> wrote:
Incidentally, if I want the GUI to update very
close to real time, say
a grid of blocks flashing on and off as notes come and go, any
thoughts? Would a GTK GUI update fast enough?
key insight: your display monitor only redraws between 60 and 90 times
per second. attempting to redraw anything more frequently than this is
simply wasting CPU cycles and making your life more difficult. put
more bluntly: it doesn't matter if you have notes turning on and off
1000 times per second - you and your users not working on a display
device that can possibly show this. you need to mentally disconnect
what is going on in the backend from what is going on in the GUI : the
backend can tell some layer of code in the GUI what is happening, but
defer updates to a reasonable refresh rate.
I do think I have mentally disconnected the backend and GUI sides of
things. I mean, the backend (what I referred to as the engine) is
working without any GUI to act as a crutch for it. Nor when the GUI is
working will the backend (at least the Real Time thread) call any of
the GUI code.
But the refresh rate is a good point. I don't know how the stuff which
appears and disappears faster than the refresh rate will be
represented visually (some kind lightening fast image (anti-aliasing)
filter?) - or (more likely) it won't be represented at all.
Does anyone actually use MIDI (note) data beyond refresh-rate speeds!? :D
Perhaps more importantly, be able to detect the exact time the notes occurred
and be able to observe quick, short note or controller changes not visible by
your eyes.
If it is desired to visually observe events shorter than the screen refresh
rate can show, how about a 'scope trace' or 'chart recorder' style box?
Say 100 horizontal pixel positions on the graph represents 1/60 second
(the refresh rate of most LCDs).
Thus each pixel position represents 1/100 of 1/60 second.
The vertical graph positions represent some data, midi CC value for example.
Thus the entire graph box need only be updated every 1/60 second,
or even less if say 200 pixels, representing 1/30 second, are used,
and so on...
If a graph is not desirable, say a knob or slider control instead,
then another idea is to change the colour of the control
indicating something quick happened, say for example a quick
change to a new value and then quickly back to the previous value,
which your eyes, and monitor, would not have noticed.
It's an important change nonetheless, because your ears heard it.
Perhaps some meaning could be conveyed through the actual colour used.
Perhaps a digital number on the control face indicating how many events
occurred.
Although you might want to smooth this by only updating
once per second for example.
The idea is to 'latch' detection of short events, for longer display later.
Because even if you had a monitor with a very high refresh rate,
your eyes still aren't going to detect short events, so it's pointless
to only display the event for just that brief period, no?
But with those methods, it's a question of how often you want the
control's colour or number to change, or even if you want to
manually 'reset' them after having been informed of the changes.
You could get fancy by making 3D controls, where the depth
conveys some information.
Say a knob which is actually 100 knobs stacked depth-wise.
The 100 knobs represent all the changes during 1/60 second.
You could rotate the whole assembly to view it as a sort of 'graph',
or rotate it 'normally' to just show the front knob representing the most
recent value.
OK, well that's a bit far fetched, but...
(Just a few ideas born while thinking of how to display live oscilloscope
traces on an LCD monitor, so this discussion of displaying live data
on slow refresh devices interests me...)
Tim.
I'm
also wondering about
going for an "Immediate Mode" GUI using SDL, possibly with OpenGL, I'm
unsure... It's a way off yet, I'm concentrating on getting the engine
working without a UI first.
Gtk or Qt or whatever will work just as well in terms of screen
refresh/update as any other solution. That doesn't mean that there
might not be other reasons to prefer a solution.
The program will be very visual (two dimensional). The idea is born
from something which happens visually (placing things next to each
other). It will need some kind of custom widget to display the main
'canvas'. Notes will essentially be represented as boxes within. As
they will persist after note-off, fading them out would be required.
The boxes might look nicer with smooth corners ;-) Some boxes will
need title bars, handles for moving, resizing, etc. Eg
window-decorations. Transparency will also be very advantageous.
That's why I was thinking of something like SDL.
James.
--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev