v6.12rc2 - June 12 2020

[mabian]

v6.12rc2 - June 12 2020

• + Toolbars: apply global color tweaks to toolbar buttons after state change [p=2302525]
• # Actions: paste at mouse positions snaps to the right only if close to the grid line
• # FX browser: adjust clear filter button alignment
• # Theme tweaker: improve description of MIDI piano key colors [t=237984]

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[bFooz]

It's very good to see you're eager for alignment!

But, ehm, this time it's 1 px too low:


And if you want some more aligment fixes:

- the dropdown arrow in the upper picture is off-center

- left-alignment here is really funky:

No alignment at all. "FX", "Filter" and box border all should be algned I'd say. (although at close inspection "Filter" is aligned with the box border, but it does not look like that from far away.)

- the Clear filter button is not completely right-aligned with the box border. This one is not so obvious luckily. And if this is to be aligned well, "Cancel" button at the bottom must be aligned as well.

The "resize" indicator is completely obsolete here and can be removed making space for the cancel button.

[mawi]

Originally Posted by mabian

v6.12rc2 - June 12 2020

• + Toolbars: apply global color tweaks to toolbar buttons after state change [p=2302525]
• # Actions: paste at mouse positions snaps to the right only if close to the grid line
• # FX browser: adjust clear filter button alignment
• # Theme tweaker: improve description of MIDI piano key colors [t=237984]

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

Can that be fixed too?
https://forum.cockos.com/showthread.php?t=237747

[Breeder]

I love filter in FX browser on top but I wonder if previous positioning was good too...anyone else thinks this could be an option?

[amagalma]

Originally Posted by Breeder

I love filter in FX browser on top but I wonder if previous positioning was good too...anyone else thinks this could be an option?

I actually dislike it being on the top, because I was used to the other position. But since most people prefer it on top and it was requested to the devs to change it, I didn't say anything, and I guess that in a couple of weeks I ll get used to it.. However, if and only if it is not a waste of time and energy for the devs to make the positioning optional, then I vote for having the option

[EvilDragon]

Best thing is, it was an option but it got removed :/

[Intek]

# Actions: paste at mouse positions...

Сould you take a look at this - https://forum.cockos.com/showthread.php?t=237839

[akademie]

Originally Posted by amagalma

I actually dislike it being on the top, because I was used to the other position. But since most people prefer it on top and it was requested to the devs to change it, I didn't say anything, and I guess that in a couple of weeks I ll get used to it.. However, if and only if it is not a waste of time and energy for the devs to make the positioning optional, then I vote for having the option

+1 for it to be OPTIONAL

[ovnis]

Option would be a good idea.

[schwa]

Originally Posted by Intek

Сould you take a look at this - https://forum.cockos.com/showthread.php?t=237839

In general, actions that are assigned to mouse modifiers will move the edit cursor, because that's most often what the user would expect. There are a number of actions, like the "paste at mouse cursor" action, that are special-cased to not move the edit cursor.

The complete solution for this is to make separate options in the mouse modifiers for assigning an action with or without moving the edit cursor, and we'll probably add that in a later release.

[akademie]

Originally Posted by schwa

...<snip>
The complete solution for this is to make separate options in the mouse modifiers for assigning an action with or without moving the edit cursor, and we'll probably add that in a later release.

That's nice schwa

[nofish]

Originally Posted by schwa

The complete solution for this is to make separate options in the mouse modifiers for assigning an action with or without moving the edit cursor, and we'll probably add that in a later release.

Nice, please consider it also for the MIDI editor (if feasable).
https://forum.cockos.com/showthread.php?t=164532

[Reflected]

Originally Posted by amagalma

I actually dislike it being on the top, because I was used to the other position. But since most people prefer it on top and it was requested to the devs to change it, I didn't say anything, and I guess that in a couple of weeks I ll get used to it.. However, if and only if it is not a waste of time and energy for the devs to make the positioning optional, then I vote for having the option

I Agree.
I also don't like it being on top.

[Reflected]

Regarding the toolbars

I wish we could dock toolbars more freely

like docking a toolbar below another toolbar at the top (2 toolbars or 3 toolbars, each below the other one at the top)

[akademie]

In this build there is again the graphic bug that was already fixed in some of the native Rea plugins few months ago.

Now it occurs in "Project Settings" dialog (all its tabs).
Here are screenshots (Reaper v6.12rc1 [32-bit] on Windows 7 Pro [32-bit]):





https://stash.reaper.fm/39630/v612rc...settings-1.png
https://stash.reaper.fm/39631/v612rc...settings-2.png
https://stash.reaper.fm/39632/v612rc...settings-3.png
https://stash.reaper.fm/39633/v612rc...settings-4.png
https://stash.reaper.fm/39634/v612rc...settings-5.png

[Meo-Ada Mespotine]

The docs for GetSetTrackGroupMembership have an error for the python-description:

Unknown RPR_GetSetTrackGroupMembership(MediaTrack tr, String groupname, Unknown setmask, Unknown setvalue)

Unknown should be integer.

Same for GetSetTrackGroupMembershipHigh, RPR_joystick_getbuttonmask, PCM_Sink_Enum and RPR_RecursiveCreateDirectory.

[Meo-Ada Mespotine]

Originally Posted by schwa

In general, actions that are assigned to mouse modifiers will move the edit cursor, because that's most often what the user would expect. There are a number of actions, like the "paste at mouse cursor" action, that are special-cased to not move the edit cursor.

The complete solution for this is to make separate options in the mouse modifiers for assigning an action with or without moving the edit cursor, and we'll probably add that in a later release.

Yes! This would be fantastic

[Meo-Ada Mespotine]

When I use PromptForAction and the actionlist is closed:

The following functioncall should return -1 as said by the docs. It shows 0 instead.

retval = reaper.PromptForAction(-1, 1, 0)

If under the same condition(actionlist closed) I run the following function, it returns -1 as described by the docs:

retval = reaper.PromptForAction(0, 1, 0)

So there's an inconsistency in here, imho.


I also think that, if the actionlist was opened through PromptForAction(so it wasn't opened before):

retval = reaper.PromptForAction(1, 1, 0)

it should automatically close again after

retval = reaper.PromptForAction(-1, 1, 0)

as otherwise it stays open. Optionally, you could add -2 as "end session and close actionlist, if it was opened by PromptForAction" as well, so both would be possible.
Otherwise opening the actionlist is easy, closing it again when the session is finished is impossible. Especially, as there is no such action as "close actionlist".

I think in most cases, the actionlist should only stay open, when it was open already.

Another thing:
Maybe it would be a cool thing, if session_id=2

retval = reaper.PromptForAction(2, 66, 0)

would allow setting more selected actions. So if I want to select actions 65 through 67, I would call:

retval = reaper.PromptForAction(1, 65, 0)
retval = reaper.PromptForAction(2, 66, 0)
retval = reaper.PromptForAction(2, 67, 0)

So I could suggest a larger selection to the user.

[amagalma]

Mespotine, try this if you like

[Meo-Ada Mespotine]

I'll give it a try.

[Mr. Data]

Originally Posted by bFooz

It's very good to see you're eager for alignment!

But, ehm, this time it's 1 px too low:


And if you want some more aligment fixes:

- the dropdown arrow in the upper picture is off-center

- left-alignment here is really funky:

No alignment at all. "FX", "Filter" and box border all should be algned I'd say. (although at close inspection "Filter" is aligned with the box border, but it does not look like that from far away.)

- the Clear filter button is not completely right-aligned with the box border. This one is not so obvious luckily. And if this is to be aligned well, "Cancel" button at the bottom must be aligned as well.

The "resize" indicator is completely obsolete here and can be removed making space for the cancel button.

Sorry for chiming in on this topic.

For me, or should I say, for us the ones who localize REAPER the problem of alignment is a special one.

A few examples:

• Have a look at the Item properties dialog.
  It's not perfect (e.g. see the space between the fourth and fifth checkbox on the right side inside the frame), but it's ok. We don't want to be that pedantic, do we?
  
  
  
  Now a look at the same dialog translated to German:
  
  
  Besides this we can also notice the misalignment of text on the left side (everywhere in the window) on many occasions. This also is obvious in the next example
  
  
  
• First the US-English version:
  
  
  And here the German one.
  
  
  There are mainly two reasons for these misalignments
  • There is more than one element in one line
  • The string is too long
  
  
  
• And here's (Tadaa!) my absolute favorite:
  
  
  This one Justin took care of and managed that it now looks like this even when translated:
  

I'm happy with this, but, to be honest, it doesn't solve the overall problem at all. IMHO It's not a good solution to fix all these things one by one (same goes for erroneous displayed umlauts and special characters used in foreign languages BTW where such problems are also handled the same way, but that's another story), because this keeps Justin and Schwa away from their work while we, the people who feel dedicated to thoroughly create Langpacks that meet REAPER's standards can't do our job as well, because of waiting for their reaction, after telling them that yet another occurrence of misalignment (or wrongly displayed characters) has been found. I'd like to see a solution that enables us to do these things ourselves without the need to ask for a fix for each unique occurence.

I'm quite aware that localization doesn't anything to the functionality of REAPER and therefore it might considered as not that important, but meanwhile there are people who try to translate REAPER into French, Spanish, Polish, Russian, Japanese and even Italian and Chinese (IIRC) hence I find it is a bit of a pity that this isn't considered as (really) important, because all these dialogs IMHO are somewhat a figurehead (hope that's the right word). I mean, whoever would consider REAPER as a serious tool and not as a toy, when it shows in translated versions all these clumsy dialogs? A assume that this doesn't really look trustworthy to potential customers and could reinforce any doubts even more if considering the price. But REAPER is trustworthy, runs stable, reliable, is usable in live settings and is by all means not a toy! There are other much more expansive DAWs I wouldn't dare to use live ever.

However, I'd like to see a solution that makes it possible to align things in dialog windows. I made a few proposals - some of them quite crude, others (IMHO) not that bad, but to no avail yet.

Once again, sorry for hijacking this thread.


-Data

[bFooz]

Originally Posted by Mr. Data

Have a look at the Item properties dialog.

Wow, that's something! +1 fox fixing. I withdraw my 1 px objections in favour of fixing this.

[daxliniere]

Opening an item linked to a subproject in the external editors simply opens the subproject instead.

I can see why this is the default, but I want to apply a process in an external editor on the proxy file, not the original source audio.

If someone attempts to edit the subproject, there could be a warning like when you unfreeze a track which has been (unlocked and) edited.

An option to consider?


Hope everyone's well!

[daxliniere]

Also, the ability to select specific regions for rendering is excellent and very, very helpful.

But we lack actions to clear all selected render-regions. Region matrix doesn't seem to offer that function as far as I could work out.


Thanks again,
Dax


EDIT: I've just worked out that region selection does not 'stick'. If you click on another region in the Region Manager, the initial selection is not retained.
Is it possible for region selecion to stick/not be overwritten by clicking elsewhere?

[daxliniere]

A little nitpick - I love using ".." in file paths for render since I discovered it, but output path isn't updated ideally.

For example, I keep my directory structure like this:

\Band name\!OUTPUT\
\Band name\Song 1\
\Band name\Song 2\
\Band name\Song 3\
\Band name\Song 4\


In the render window, I can use ..\!OUTPUT in Directory and Filename as $project and it works PERFECTLY. However the Render to field shows Project-drive:\Band name\Song Name\..\!OUTPUT\ instead of simply Project-drive:\Band name\!OUTPUT\

[daxliniere]

And could be do something about putting subprojects and their proxy files into a directory below the project directory, please, please, please?

I started using subprojects (which are great!), but now my main project directory has 100 .RPP files, all of which are displayed when I use the project folder in the Open RPP dialogbox.

I suppose changing the filetype from .RPP to .RSPP/.RSP would solve this, too.

[Mr. Data]

Originally Posted by bFooz

Wow, that's something! +1 fox fixing. I withdraw my 1 px objections in favour of fixing this.

No, bFooz, please don't!
I didn't want to weigh your concern against mine.
I wanted to emphasize it in a way. (... but then I went into babble. )

-Data

[matt_t]

Originally Posted by akademie

In this build there is again the graphic bug that was already fixed in some of the native Rea plugins few months ago.

It's still present in ReaDelay, ReaEQ, ReaPitch and ReaXcomp.

[akademie]

Originally Posted by matt_t

It's still present in ReaDelay, ReaEQ, ReaPitch and ReaXcomp.

It is actually "THE FIX"
The bug was that there were white places only underlaying the text labels - it was fixed by making the tabs all white.
It is not super nice, I know, but much much better than before

It has to be said that these Rea plugins (ReaDelay, ReaEQ, ReaPitch and ReaXcomp) are different from the other ones (those "all-grey") in that they conains multiple tabs, so highlighting active tabs is more difficult.

[_Stevie_]

Originally Posted by schwa

In general, actions that are assigned to mouse modifiers will move the edit cursor, because that's most often what the user would expect. There are a number of actions, like the "paste at mouse cursor" action, that are special-cased to not move the edit cursor.

The complete solution for this is to make separate options in the mouse modifiers for assigning an action with or without moving the edit cursor, and we'll probably add that in a later release.

That’s awesome news! Could you also consider not clearing a selection on MM action?

+1 on adding the behavior in the ME as well!

[matt_t]

Originally Posted by akademie

The bug was that there were white places only underlaying the text labels

Those white places are actually what I am seeing in those FX.

Actually, I should have been a bit more precise, and thorough in my research.

After a second look I thought they were OK in RC1 and RC2 but broken in RC3. But after a third look, switching between all three RCs, sometimes they look right, sometimes they don't, in whichever RC.

And just to be extra-awkward:
1) when it's looks wrong on my laptop screen it still looks OK on my second monitor
2) all the Project settings tabs which look wrong for you look right for me, in all three RCs, all the time

Over to you, devs

[akademie]

^^^^^^ UUhh, something strange here then
Thank you for more info on other system/monitor, matt_t.

[Edison]

Originally Posted by Mr. Data

No, bFooz, please don't!
I didn't want to weigh your concern against mine.
I wanted to emphasize it in a way. (... but then I went into babble. )

-Data

Hi M. Data,

I have also reported a few times about strange characters, misalignments, overlapping windows. The most recent being in the metadata window.


Best regards,