Highlighting In 1.5x

Please forgive me if this has been posted already, I’ve searched for mouse, selecting, selection, highlight, highlite, highlighting and have come up with no results for this issue in both the tutorial and the forums.

This is something I wasn’t sure if I should ask about or not during the first alphas and beta since I figured it was obvious, but since it still is the same in beta2, I figured I needed to ask:

Is there a way to get the option that highlights with the mouse to act like it did in the earlier versions? I could left-click and hold anywhere I wanted to start and not have to move the mouse at all–move with the cursor keys to where I want, and let go of the mouse. Now I have to constantly move the mouse while scrolling with the cursor keys or it loses placement, and if I continue to the end of the pattern and it loops to the top, it then usually has only what’s currently at the bottom of the screen to where my mouse is.

Is there an option to address this behavior?

I hope i understood you correctly…:

You can turn off the wrap around pattern edges (shift+scrollock) to get rid of the problem that you scroll to the next pattern sequence.

You do not really have to move the mouse exactly, but if you want to have the visual selection trail synchronous to the row position that scrolled under your mouse-pointer:yes you either have to release the mousebutton or move it.
The Selection follow-mode can also be archieved by using ALT-arrow keys.

Alt key? :rolleyes: That moves the selection.

Let go of the mouse button? :blink: That defeats the whole purpose of what I’m trying to do.

Turn off wrap-around-pattern-edges? Ugh. :( No.

I had a really long explaination and then I decided to hit delete. I forgot that the whole time I’ve been using 1.5 I’ve had to do something quite different than I’m used to, and it compounded the problem with when I want to start a selection near the bottom of the pattern and want to let the page wrap and finish the selection at the top: I cannot use the row position to start my selection with.

If I’ve started the selection at the row position and scroll with the cursor keys and then move the mouse a little to get it to select (but stay in the row position), it will select NOTHING.

How do I make a selection using the row position? Is this a bug, or is there an option I can change?

I have a video clip of this behavior, which isn’t always consistant, at http://www.infraxes.com/here.avi

The first two attempts in this clip work correctly, the third does not–the third attempt shows how sometimes it will skip selecting what is in the row position if the selection was started in the row position and after scrolling with the arrow keys and then moving the mouse outside the row position to where I want to select. The last examples show how if you hold the mouse button down when in the row position and start scrolling with the keys, THEN move the mouse only WITHIN the row position, the only thing that gets selected is only in the row position where the mouse pointer currently resides.

I hope this video clip makes it easier to understand.

If you don’t move the mouse during the initial click, the mouse-movement detection routine does not trigger the selection event for you. (Seems)

However if you move the mouse in the starting-cell as well as in the ending-cell the selection always goes right.

You probably expected that by holding the lmb, the selection routine was already invoked at that time…

Even after seeing the video that shows the problems associated with this “new” behavior, you act like it’s just fine and dandy: “You probably expected that by holding the lmb, the selection routine was already invoked at that time…” Why yes, I did, it’s been standard tracker behavior since the early Amiga days–and if one includes hitting a key to start the selection point and cursoring to where you want and hitting the key again to end the selection point, it’s been since C64 tracker days.

How about a follow-up statement to “You probably expected that by holding the lmb, the selection routine was already invoked at that time…”? Something that shows that it may be considered to be fixed–or worked on (since YOU probably don’t consider it to be a bug) for the final release? Or can you give the reason, poor or decent, as to why they left that portion out of the routine if it’s not something they plan on fixing?

Moving the mouse FIRST doesn’t work, you have to move the mouse after you’ve started using the cursor keys and then again at the end of your selection, and if you’re in the row position you have to move the mouse BOTH before and after you start using the cursor keys and then again after the end of making the selection, so the best way to be sure that the selection will actually work is to move the mouse in little circles the whole time–it’s really stupid.

Please though–how about a followup statement as to why it acts that way or when or if it will be fixed–and if it won’t be fixed, why?

First of all, i’m no dev, wether it requires fixing or not is up to them.
Currently i’m still being busy figuring out what you exactly want and then try to help you as best as i can with my knowledge.

As far as i can follow you… not requiring to move the mouse to get the area selected once the lmb is released is one of the things you want.
Yet i still don’t quite understand your point about the spanning of your selection through the end of the pattern up to the beginning of the pattern.

And no i don’t need to circle the mouse the whole time:only at the start-row and at the end-row and when i release the LMB, the selection is being made.

Yeah, if you want the selection being updated everysingle row:you would have to move the mouse constantly.

But as i also purposed earlier:
Using ALT+arrow keys, you can select even without using the mouse at all. The only hassle here with current keyshortcuts is you can’t jump quickly to another track and select there as well, you have to use the right or left arrowkey and crossover every column and subtrack which is required within the selection.

The dragging part of the selection, only kicks in when you will be using your mouse by holding the lmb during pressing ALT-key.

Personally a few of my favorite shortcuts ever found in trackers for selections were ALT-B (set beginning of selection), then click the end-cell (wherever in the pattern) and hit ALT-E to display the selection block.

I’ve heard more people discussing implementing this solution in Renoise than people mentioning your specific problem.

And the reason why i personally don’t specifically see it as a bug is that it looks like you use a trick that is not in the book. And it is nice as long as it works, but never gives any guarantee that it will remain to function in later versions also.

But as mentioned at the top of my post:this is up to the devs to determine wether your method is deal of the coded concept or just a side-effect that worked to your benefits in previous editions of Renoise.

I just simply make the attempt to give you some tricks to reach what you want with as less hassle as possible.

If someone knows a better trick, he/she is welcome to mention it.

Huh? You mean Ctrl-B and Ctrl-E? I doubt this has been discussed much since it’s already possible :)

Okay sorry,…

Probably confused this with CTRL-I and CTRL-J (volume column interpolation and doubling shortcut keys, were the same options used next to block-selection in Impulse Tracker)

Sorry vvoois, it wasn’t my intention to correct you… To me it just sounded like you hadn’t found your favorite shortcut in Renoise… so I just pointed it out.

There are lots of things in Renoise i haven’t been thoroughly exploring myself yet.
I’ve been copying information that already existed in the old documents and i haven’t done everything yet simply because i haven’t tested everything yet.

If i put something in the 1.5 documentation, i check that it (still) works.

There are even more selection options (to stay on-topic) (ALT+Q, ALT+Y, ALT+A), things that have been in there long time, but currently not being copied to the new documentation.

I hope this adds to your satisfaction Kizzume…:

Select Previous Block For Loop Play
LControl + Subtract

Select Next Block For Loop Play
LControl + Add

Mark Column In Loop Range
LShift + LAlt + Q

Mark Column Above Current Position
LShift + LAlt + A

Mark Column Below Current Position
LShift + LAlt + Y

Mark Whole Track
LAlt + T

Mark Track In Loop Range
LAlt + Q

Mark Track Above Current Position
LAlt + A

Mark Track Below Current Position
LAlt + Y

Mark Whole Pattern
LAlt + P

Mark Pattern In Loop Range
LAlt + W

Mark Pattern Above Current Position
LAlt + S

Mark Pattern Below Current Position
LAlt + X

Vvoois said "And the reason why i personally don’t specifically see it as a bug is that it looks like you use a trick that is not in the book. And it is nice as long as it works, but never gives any guarantee that it will remain to function in later versions also.

But as mentioned at the top of my post:this is up to the devs to determine wether your method is deal of the coded concept or just a side-effect that worked to your benefits in previous editions of Renoise."

Well, you either have never used that method to select before or you haven’t used very many other tracker programs, because it’s been standard behavior in trackers since the Amiga days.

Thank you for your help though, you gave some interesting shortcuts, however, I can’t throw out habits acquired from 16 years of using gui-trackers, including older versions of Renoise.

Here is an example of Renoise 1.28 doing this just fine: http://www.infraxes.com/here128.avi

p.s. the wrap-around problem was still specifically associated with not moving the mouse. It was the same problem causing it.

Here are examples of 8 programs I could easily get my hands on–all of them handle the mouse “correctly”. I can make this list of files bigger–aka–install more trackers and make avi’s of the standard mouse behavior if you need even more proof of this, but I’d rather not fill my hard drive with trackers I won’t be using.


This mouse selection behavior is a STANDARD. A standard that has been around a long time.

Here’s a link to a file that shows more closely how Renoise1.5 doesn’t select anything:

And here’s the way Renoise is supposed to be:

After all this, Vvoois, do you still consider this option to be using a trick that’s not in the book? When you accused me of cheating or using a bug to my advantage and use that as a method to ignore a problem with the new build, it kind-of pissed me off. You have a lot of say on this board, and when you classified my problem as a “trick” that’s not in the book, it basically gets rid of any hope that the problem may be eventually fixed.

Why not move this thread to the 1.5 bugreports section?

Your working example is clear.
And if it worked that way in 1.28 and not in 1.5, it may be a bug.

Though there are other situations in 1.28 that don’t work anymore in 1.5 because it has been deliberately removed upon assumption nobody used it (swapping samples and instruments amongst eachother e.g., trick imported from FT2)

I’m not familiar with your way of working, i’ve never attempted to do this in Protracker 1.x, 2.0 and 3.0 on Amiga. On the C64 i didn’t even had a mouse, so i definately can’t tell you if it was so there (let alone if composing applications really supported mouse at all)
A lot of DOS trackers did not support mouse in this way either (screamtracker-like and not supporting meaning:not being able to select a range with mouse at all)

I either use shortcut keys or mouse, wether which one is more obvious to use, but don’t attempt to combine those things.

Thank you so much. :)

I see no argument why the selection should not be updated, when moving the pattern with keyboardshortcuts while selecting with the mouse.

So its fixed. It behaves exactly as it did before. Period. Can we close this thread now ? :)