15 Jun
2010
15 Jun
'10
8:40 p.m.
On 15 June 2010 16:55, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
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.
On Tue, Jun 15, 2010 at 11:27 AM, James Morris
<james(a)jwm-art.net> wrote:
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
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'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. --p