linuxaudio.org

On June 15, 2010 02:40:30 pm James Morris wrote:

quoted text
> On 15 June 2010 16:55, Paul Davis  wrote:

> > On Tue, Jun 15, 2010 at 11:27 AM, James Morris  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.
>

quoted text
> >>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@lists.linuxaudio.org

> http://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev