pitch wheel controller event resolution

[nbd]

Hello.

I noticed that the "Insert line of controllers" is not making enough steps
for pitch wheel, so I looked at the code.

src/gui/rulers/ControllerEventsRuler.cpp:

// If inserting a line of PitchBends then we want a smoother curve

     if (m_controller->getType() == PitchBend::EventType)
         quantDur = Note(Note::Demisemiquaver).getDuration();

so I changed it to

     if (m_controller->getType() == PitchBend::EventType)
         quantDur = Note(Note::Hemidemisemiquaver).getDuration();

but was still not satisfied. Then I tried

     if (m_controller->getType() == PitchBend::EventType)
         quantDur = Note(Note::Hemidemisemiquaver).getDuration() / 16;

and then it was almost way too much.

Would it be easy to let user decide this on runtime somehow? There might
be cases where fixed resolution is not wanted.

How about some 'grid resolution' parameter for all controller events (not
just pitch bend, others could benefit from it too)?

Or maybe option to smooth the existing curve, by first selecting the
events and then the context menu would have 'smoothen' or similar, and
that would double the resolution. This could then be done several times,
until the smallest time interval is reached between adjacent values (1ms I
guess).

Example:

'Insert line of controllers' gives values 10 8 6 4 2 0. Then smoothing it
would yield 10 9 8 7 6 5 4 3 2 1 0.


Comments?

BR,
Tommi Uimonen

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Monday 14 July 2008, Tommi Sakari Uimonen wrote:
> Would it be easy to let user decide this on runtime somehow? There might
> be cases where fixed resolution is not wanted.

You already got your toes wet, and you know more about that code now than I
do.  Why not take it the rest of the way?  The whole control ruler feature
was left in kind of a rough state right after its introduction, and nobody
has ever gotten around to going back to polish and tweak it.  It is very
unlikely that anyone presently on our staff ever will, but that doesn't mean
we have no interest in seeing this improved.  We'd be delighted to see
someone undertake this as a pet project.
--
D. Michael McIntyre

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Mon, Jul 14, 2008 at 6:08 AM, Tommi Sakari Uimonen
<tuimonen@...> wrote:

> Would it be easy to let user decide this on runtime somehow? There might
> be cases where fixed resolution is not wanted.
>
> How about some 'grid resolution' parameter for all controller events (not
> just pitch bend, others could benefit from it too)?
>
> Or maybe option to smooth the existing curve, by first selecting the
> events and then the context menu would have 'smoothen' or similar, and
> that would double the resolution. This could then be done several times,
> until the smallest time interval is reached between adjacent values (1ms I
> guess).

All good suggestions.  I suppose that the smallest sensible time
interval between adjacent values when drawing a straight line is
unlikely to be constrained by Rosegarden's timing resolution, but by
the quantization of the value range.  That is, there's not much point
in placing the events so close together that you would end up with
multiple consecutive events having the same value.  At least, not by
default, though there may be situations in which you want to be able
to ask for that explicitly.

Perhaps we could do a better job of choosing the default time step by
working out the time step necessary to produce a value step of 1, and
picking the next largest fraction of some base note-related duration.


Chris

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

> You already got your toes wet, and you know more about that code now than I
> do.  Why not take it the rest of the way?  The whole control ruler feature

Yes, why not.

> was left in kind of a rough state right after its introduction, and nobody
> has ever gotten around to going back to polish and tweak it.  It is very
> unlikely that anyone presently on our staff ever will, but that doesn't mean
> we have no interest in seeing this improved.  We'd be delighted to see
> someone undertake this as a pet project.

I'll see what I can come up with. Questions propably at first.

Tommi

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Monday 14 July 2008, Tommi Sakari Uimonen wrote:

> > I do.  Why not take it the rest of the way?  The whole control ruler
> > feature
>
> Yes, why not.

Great then!

> I'll see what I can come up with. Questions propably at first.

Sure thing.  Fire away.
--
D. Michael McIntyre

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

>> I'll see what I can come up with. Questions propably at first.
>
> Sure thing.  Fire away.

One minor flaw I noticed is that when grid is zoomed, mouse clicks seem to
be misaligned. You can see this by first drawing a line of controllers,
then zooming to max (2000%) and trying to select them. If clicking the
highest bar from the point that is higher than the other bars, it will
select the correct event, but if clicking eg. from the bottom, it will
choose the next to right one.

Also by inserting just one controller, you can experiment how far from it
will react to mouse clicking. It seems like the active area is at least
50% larger than the size of the visible bar, to both sides.

Tommi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Tuesday 15 July 2008, Tommi Sakari Uimonen wrote:

> One minor flaw I noticed is that when grid is zoomed, mouse clicks seem to
> be misaligned. You can see this by first drawing a line of controllers,
> then zooming to max (2000%) and trying to select them. If clicking the
> highest bar from the point that is higher than the other bars, it will
> select the correct event, but if clicking eg. from the bottom, it will
> choose the next to right one.

I can reproduce this, but sometimes the clicks actually do select the expected
bar.  I'm not sure exactly what the pattern is.

While we're paying attention to the rulers in general, one thing I've always
found troubling is how difficult it is to see just which controllers are
actually selected at all.  The little red border is easy to miss, and that
whole mechanism differs from the rest of Rosegarden, so it's not consistent.

> Also by inserting just one controller, you can experiment how far from it
> will react to mouse clicking. It seems like the active area is at least
> 50% larger than the size of the visible bar, to both sides.

Without doing actual pixel measurements to come up with the real numbers, I'd
say it looks like more like 10% here.  At least at 2000% zoom.  And if I zoom
back to 100%, it's still 10% or maybe a little less.

I definitely see what you're talking about though.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

> I can reproduce this, but sometimes the clicks actually do select the expected
> bar.  I'm not sure exactly what the pattern is.

At least when clicking the highest bar from the highest point.

> While we're paying attention to the rulers in general, one thing I've always
> found troubling is how difficult it is to see just which controllers are
> actually selected at all.  The little red border is easy to miss, and that
> whole mechanism differs from the rest of Rosegarden, so it's not consistent.

I noticed that too. I would prefer just dots at the precise location of
the controller event. Since, to my understanding, pitch wheel controller
events don't have duration(*), they just set the new value and that value
stays on forever until next value is set. The dots would be easier to
distinguish from each other. The bar, to my opinion, just consumes too
much space and looks clumsy if there are several of them overlapping
(didn't find a way to change the size yet)

(*) I have to investigate if the same applies for every controller.

Tommi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Wed, Jul 16, 2008 at 6:34 AM, Tommi Sakari Uimonen
<tuimonen@...> wrote:
> Since, to my understanding, pitch wheel controller
> events don't have duration(*) [...]
>
> (*) I have to investigate if the same applies for every controller.

It does.  No MIDI events have duration -- notes only acquire duration
by virtue of being separated into note-on and note-off, and there
aren't any other events that work in that way.

The reason the rulers use bars rather than points currently is that
the same code is used for the velocity ruler, and of course velocity
does have a duration because it's associated with a note.  I think
you're right that points would work better for controllers.


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

> > I can reproduce this, but sometimes the clicks actually do select the
> > expected bar.  I'm not sure exactly what the pattern is.
>
> At least when clicking the highest bar from the highest point.

I was clicking on random bars with hard to quantify results, but definitely
not always the highest bar from the highest point.


On Wednesday 16 July 2008, Chris Cannam wrote:

> The reason the rulers use bars rather than points currently is that
> the same code is used for the velocity ruler, and of course velocity
> does have a duration because it's associated with a note.  I think
> you're right that points would work better for controllers.

The velocity ruler existed first, and Guillaume just re-used the bars when
putting together the control rulers, if I don't misremember.  I agree that it
would be nice to have a more precise way to locate events in time, and dots
seem easier to work with than bars for this purpose.  I think I'd keep the
color coding by value though.

--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Hello All,

Michael said:
> I agree that it
> would be nice to have a more precise way to locate events
> in time, and dots
> seem easier to work with than bars for this purpose.  I
> think I'd keep the
> color coding by value though.

I see the value of it, but the vertical position also gives an idea of value.  Color coding does help though.

It would be nice if the controller event ruler worked similar to the drum matrix editor where duplicate events showed up as black.  Of course, using smaller dots than in the drum matrix editor would help with visibility of high density controller events.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

> I see the value of it, but the vertical position also gives an idea of value.  Color coding does help though.

The dot will have a vertical position.

> It would be nice if the controller event ruler worked similar to the
> drum matrix editor where duplicate events showed up as black.  Of
> course, using smaller dots than in the drum matrix editor would help
> with visibility of high density controller events.

Controller event should not have duplicate events anywhere. Always just
one event per certain time. But I guess you mean when several events are
close to each other and zoom is out.

I'm starting to feel that the right way would be to introduce Ardour-like
automation, where just few control points are defined and straight
line drawn between them. But I'm not yet quite sure how that would be
interpreted when playing. Should there be new event triggered every
millisecond, or it could be something configurable. This way the
automation data would stay the same and events could be triggered at
different intervals, depending on the setting. On a slow computer 1ms
might be too much, so the user can reduce the resolution. I'll have to
think about this.. And maybe you too, Chris? Is this implementable?

Tommi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Hello All,

In response to Tommi concerning automation and some recap of thoughts discussed so far.

I think maybe a stepwise solution might be better.  This based off of what seems to be a best value for the effort.  I'm probably wrong.

Starting from the current setup:
1.  In controller events, see if we can add the draw property line used in the velocity ruler.  That would help in altering existing events--most of the code is existing.

2.  Add an option to control the width (or density) of controller events.  This would affect the width of the bar and the density of automatically inserted events such as "insert line of controllers."  We'd need to decide where to put the "width (density)" configuration option and what time base to use--ms or note duration or both.

Those two options may add quite a bit of functionality.

3. Use dots instead of bars for event controllers where vertical position and color indicate value.

Then, add automation:
4. Add connecting lines, curves, etc. for automation.

A couple things to ponder concerning automation:
How will we get RG to interpret this?  Will RG do this in real time during playback or will RG compute and store intermediate automation values at the time user specifies the automation task for the selected events?  Or another alternative?

Other changes discussed:
These were things that were mentioned and can be explored as well.

1. Change the color inside the event screen graphic instead of changing the border.  Currently controller event selection turns border red.  This change will give RG a more consistent feel.

2. Track down issue with controller event selection.  Currently, the selection is ambiguous; since, the active selection area of controller events appears to be larger--possibly proportionately larger--than the actual representation of the event on the screen.

Well, those are my thoughts.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

Hi, some update on the progress

> 3. Use dots instead of bars for event controllers where vertical
>    position and color indicate value.

This mostly works now. I'm using QCanvasEllipse instead of
QCanvasRectangle. There is still problem, when the zoom is used, the dot
width is increasing. I tried to track down where it actually happens, but
I'm not quite sure yet how to fix this. There is some resize canvas call
that seems to do it, but I could use some hints how to proceed.

> 1. Change the color inside the event screen graphic instead of changing
>    the border.  Currently controller event selection turns border red.
>    This change will give RG a more consistent feel.

Done. Currently the selected items are colored Qt::blue.

> 2. Track down issue with controller event selection.  Currently, the
>    selection is ambiguous; since, the active selection area of
>    controller events appears to be larger--possibly proportionately
>    larger--than the actual representation of the event on the screen.

This kind of went away, after I started using the QCanvasEllipse.


Tommi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Hello Tommi,

You said:
> QCanvasRectangle. There is still problem, when the zoom is
> used, the dot
> width is increasing. I tried to track down where it
> actually happens, but
> I'm not quite sure yet how to fix this.

I've never used this stuff before, so take my advice with a grain of salt.

It appears that the QCanvasEllipse obeys the QT3 scale(double sx, int sy) settings.

I see a few solutions:
1. include /src/gui/general/HZoomable.  Use double getHScaleFactor() to divide your width of your ellipse before sending it.

But I don't think this will help if you zoom in after events are drawn.

2. Use a code from /src/gui/editors/matrix/QCanvasMatrixDiamond.cpp to draw an object that consistently disregards scale.

3. explore QT3's qsize and qsizepolicy--there seemed to be some features there as well concerning scalability of objects.

Well, those are my thoughts.  I hope it helps.  I don't have any more time to look into for now.

Personally, I like solution #2 since it is already working in RG.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

In my last post I said:

> It appears that the QCanvasEllipse obeys the QT3
> scale(double sx, int sy) settings.

I meant:

scale(double sx, double sy) settings.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[nbd]

Hello

> 2. Use a code from /src/gui/editors/matrix/QCanvasMatrixDiamond.cpp to draw an object that consistently disregards scale.

This seems to be working now, I adapted the code and created
QCanvasDiamond class under src/gui/rulers. I don't know what is the
correct way to include new files to build, but I managed to build it by
adding them to GUIFileList.txt

Next I should tackle the issue that several control lines can be drawn on
top of each other. The ruler curve should follow the mathemathical
function rule of being one-to-one (or something fancy like that), meaning
that there can be only one value at a certain point of time. So if other
values are drawn on top of existing, the old values should be removed.

Tommi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel