22 Nov
2011
22 Nov
'11
10:12 p.m.
On Tue, Nov 22, 2011 at 09:13:37PM +0100, Nick Copeland wrote:
If you are using a toolkit that has a data flow of the
following:
pointer motion->graphical display->values->application->output
Well, basically that is broken as you have a flow that is
input->output->input->application->output
invariably that is going to lead to issues. The tail (the toolkit) is wagging the dog
(the application) as it imposes restrictions on the values the application is allowed
to see.
In my opinion (ok, it is only opinion) is that the correct flow is
input->application->output
Yes, I see your point, and it makes a lot of sense. So what would be
required is
* compute the new parameter value from
- a stored state in 'paramater space' rather than 'widget space'
- and pointer (mouse) gestures,
* update the widget according to that value.
This is more or less what I do in the rotary controls used
in e.g. zita-at1 and zita-rev1. It's possible because the
mouse movement and the visual representation of the value
(the angle of the line on the rotary knob) are not directly
related anyway.
But this is not how most (all) toolkits work.
You could probably use them in the way you suggest with some
extra effort. But in many cases (e.g. linear sliders) the
pointer and widget would have to remain in sync visually,
which then means that your resolution in paramater space
can't be better than the visual one. Unless you allow the
pointer to move faster than the visual object it is controlling
(which is what I do in the 2-D panner, but it's possible only
because the widget is so small).
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
22 Nov
22 Nov
10:19 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
Or simply hide the cursor?
On Nov 22, 2011 4:12 PM, "Fons Adriaensen" <fons(a)linuxaudio.org> wrote:
On Tue, Nov 22, 2011 at 09:13:37PM +0100, Nick
Copeland wrote:
If you are using a toolkit that has a data flow
of the following:
pointer motion->graphical display->values->application->output
Well, basically that is broken as you have a flow that is
input->output->input->application->output
invariably that is going to lead to issues. The tail (the toolkit) is
wagging the
dog
(the application) as it imposes restrictions on
the values the
application is allowed
to see.
In my opinion (ok, it is only opinion) is that the correct flow is
input->application->output
Yes, I see your point, and it makes a lot of sense. So what would be
required is
* compute the new parameter value from
- a stored state in 'paramater space' rather than 'widget space'
- and pointer (mouse) gestures,
* update the widget according to that value.
This is more or less what I do in the rotary controls used
in e.g. zita-at1 and zita-rev1. It's possible because the
mouse movement and the visual representation of the value
(the angle of the line on the rotary knob) are not directly
related anyway.
But this is not how most (all) toolkits work.
You could probably use them in the way you suggest with some
extra effort. But in many cases (e.g. linear sliders) the
pointer and widget would have to remain in sync visually,
which then means that your resolution in paramater space
can't be better than the visual one. Unless you allow the
pointer to move faster than the visual object it is controlling
(which is what I do in the 2-D panner, but it's possible only
because the widget is so small).
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:23 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
On Tue, Nov 22, 2011 at 04:19:01PM -0500, Paul Giblock wrote:
Or simply hide the cursor?
!! A good idea. But it could be confusing to the user, unless
you provide a substiute.
Caio,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
10:36 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
> Or simply hide the cursor?
Well, the tablets don't even have one since that last thing you want
with multitouch is ten cursors on the screen.
Or you can always do a Claassen and hide the whole damn GUI. That
actually has quite a lot going for it as well...
Regards, nick.
10:48 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
!! A good idea. But it could be confusing to the user,
unless
you provide a substiute.
Yes. I suppose one could overlay a sprite to where the user clicked
with the mouse last, then we are getting into the syncing you
mentioned earlier.
One thing I do like about this method (either emulating the cursor or
hiding it), is that one could map the mouse's delta position to a
value on an arbitrary scale. 10:1, log, etc.. It doesn't matter where
the cursor actually is.
On second thought.. perhaps it does - the cursor is bounded to the
screen dimensions. Perhaps reset the mouse position and keep some
running delta. Food for thought in either case.
Paul
23 Nov
23 Nov
12:33 a.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
On Tue, Nov 22, 2011 at 04:48:50PM -0500, Paul Giblock wrote:
Makes we wonder: is there a way in X11 to get mouse motion events
without screen bounds ?
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
!! A good
idea. But it could be confusing to the user, unless
you provide a substiute.
Yes. I suppose one could overlay a sprite to where the user clicked
with the mouse last, then we are getting into the syncing you
mentioned earlier.
One thing I do like about this method (either emulating the cursor or
hiding it), is that one could map the mouse's delta position to a
value on an arbitrary scale. 10:1, log, etc.. It doesn't matter where
the cursor actually is.
On second thought.. perhaps it does - the cursor is bounded to the
screen dimensions. Perhaps reset the mouse position and keep some
running delta. Food for thought in either case. 
22 Nov
22 Nov
10:20 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
On Tue, Nov 22, 2011 at 4:12 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Yes, I see your point, and it makes a lot of sense. So
what would be
required is
* compute the new parameter value from
- a stored state in 'paramater space' rather than 'widget space'
- and pointer (mouse) gestures,
* update the widget according to that value.
its typically called Model-View-Controller programming. its not quite
the same MVC that people mean when they use it in connection with web
programming.
we use this model in ardour as much as possible, which is not say
everywhere, but many/most places.
But this is not how most (all) toolkits work.
You could probably use them in the way you suggest with some
extra effort.
for both Qt and GTK, you can simply override the default event
handlers to get this behaviour. its very easy.
But in many cases (e.g. linear sliders) the
pointer and widget would have to remain in sync visually,
which then means that your resolution in paramater space
can't be better than the visual one. Unless you allow the
pointer to move faster than the visual object it is controlling
(which is what I do in the 2-D panner, but it's possible only
because the widget is so small).
its can get quite a lot more complex than this. its not uncommon to
find cases where you want the on-screen view/control to be updated
*without* modifying the model. the canonical case of this in ardour
involves dragging regions around on screen. forget the canvas - there
can be clocks that show the current region position. these need to
update to show the motion of the region, but its vastly,
overwhelmingly too expensive to update the model (the backend, in
libardour) with every recorded mouse motion. so a rather complex
scheme is sometimes necessary wherein UI events change the state of
the view(s)/controller(s) without changing the model, and only at the
end of a gesture of some kind does the model finally update and things
go back to the regular dependencies.
this does make for some hellish code, though.
10:43 p.m.
New subject: Fw: Re: "bleeding edge html5" has interesting Audio APIs
On Tue, Nov 22, 2011 at 04:20:32PM -0500, Paul Davis wrote:
its can get quite a lot more complex than this. its
not uncommon to
find cases where you want the on-screen view/control to be updated
*without* modifying the model. the canonical case of this in ardour
involves dragging regions around on screen. forget the canvas - there
can be clocks that show the current region position. these need to
update to show the motion of the region, but its vastly,
overwhelmingly too expensive to update the model (the backend, in
libardour) with every recorded mouse motion. so a rather complex
scheme is sometimes necessary wherein UI events change the state of
the view(s)/controller(s) without changing the model, and only at the
end of a gesture of some kind does the model finally update and things
go back to the regular dependencies.
this does make for some hellish code, though.
Indeed. There are similar things in Aeolus (but probably not as
hairy as in Ardour) which is strictly MVC.
Doing 'the right thing' as pointed out by Nick requires in most
cases a round trip to the application code and back. Which can
become problematic if this involves a relatively slow OSC/network
connection for example. Things get even more hairy if you consider
automation and plugins.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
4546
days inactive
4546
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Fons Adriaensen -
Nick Copeland -
Paul Davis -
Paul Giblock