Why were sws_*.zip files moved to old folder on Landoleet right now with release 6.09+dev0428, please?
Aren't those sws' already compatible with this 6.09+dev0428 version?
EDIT 20200430: So, now those "sws_*.zip" files are back in the root of the LoL Thanks
Last edited by akademie; 04-30-2020 at 02:04 PM.
Reason: EDIT sws zips are back in root
love to be able to set muted track colour...What determines this color? Why isn't it possible to change it? I think if Justin, Schwa or maybe White Tie could once for all answer this question
Absolutely, 100%, but it isn't related to this pre. That colour seems to somehow exist outside normal colour space (it does a number of unexpected things), there clearly is a reason that this feature request that you, I , everyone has been making for so many years remains unaddressed. Lets not derail the awesome thing that is in this Pre and demands our detailed discussion.
Awesome! One question though, how does it take into account wildcards like times and dates?
Or would the best way to get the written files by retrieving their filenames using RENDER_TARGETS and rendering immediately after that?
That API call returns the list of filenames after resolving all wildcards, so if you are using time-of-day wildcards, the filenames will go stale after some period of time.
Media Explorer doesn't read metadata from these FLAC Files. These files have metadata. I can see these in sound miner. But Media Explorer won't read this.
The files contain a block of non human readable data labeled "SMED". My guess is sound miner encodes tags in some proprietary format. If you have more information about that format we can look at deciphering it.
REAPER crashed, happened when clicking on a track, no clue how to reproduce. Was using new project with a few colored tracks w/one midi item to play around with new Color Control, and also made adjustments to v6 Theme with theme adjuster, thats about it.
Why were sws_*.zip files moved to old folder on Landoleet right now with release 6.09+dev0428, please?
Aren't those sws' already compatible with this 6.09+dev0428 version?
The code from Justin which is contained in these sws_*.zip files on LoL ((to make SWS compatible with R6 new tcp/mcp architecture) is also contained in the current pre/bleeding edge SWS version, along with other fixes etc. https://www.sws-extension.org/download/pre-release/
So these versions on Lol are kinda obsolete meanwhile so imo it makes sense moving them to 'old'.
The code from Justin which is contained in these sws_*.zip files on LoL ((to make SWS compatible with R6 new tcp/mcp architecture) is also contained in the current pre/bleeding edge SWS version, along with other fixes etc. https://www.sws-extension.org/download/pre-release/
So these versions on Lol are kinda obsolete meanwhile so imo it makes sense moving them to 'old'.
Oh, I see. Thank you for clarification nofish.
It would be fine, if SWS would be downloadble as simple *.zip file also (and not only .exe installer)
EDIT 20200430: Those "sws_*.zip" files are now back in the root of the LoL
Last edited by akademie; 04-30-2020 at 02:05 PM.
Reason: sws zips are back in LoL root
We can add take markers while recording but we can't do that behavior via scripting cause ReaScript doesnt have way to access Items being recorded. I was creating a script to handle predefined Take Markers names and Colors but it can't work on these unfinished items contrary to native take action. I guess adding support to these kind of item would be hardcore, maybe having a simple way to create presets (just name and color) for the quick add take markers actions ? Some people wanted to mark items while recording.
I would like to see ReaScript-access to items being recorded as well, even if some of the attributes aren't accessible for obvious reasons (final-length and such) so we could not only add takemarkers but also itemnotes to items being recorded.
We need to discuss very carefully how and where the 'User Interface Color Controls' is communicated to the user...
I am vote for this hundred times — this new feature is unrelated to the theming and such, it is for display compensation. And it has to be one and only visible thing for the "casual" user (as the all 98% users are).
I’m interested to hear the use cases for the refinements to delay compensation.
I’m imagining it enables to switch audio at all points around the studio between being heard at the same time to as soon as possible.
Previously, PDC was added per plugin in chain, so even if you had, say, 3 plugins that each added 16 samples of latency, and your audio interface buffer size was 128 samples, you would get 384 samples of latency total.
With this new rework, you get 128 samples of latency. You would get another block of latency only if total latency incurred by plugins in the chain exceeds the size of the audio interface buffer. Obviously a huge improvement!
REAPER crashed, happened when clicking on a track, no clue how to reproduce. Was using new project with a few colored tracks w/one midi item to play around with new Color Control, and also made adjustments to v6 Theme with theme adjuster, thats about it.
Thanks, that dump file was enough to figure out why the crash occurred.
For those interested in reproducing, one way I found was (DON'T DO THIS, it will crash!):
1) Enable prefs/general/advanced/allow keyboard input during mouse edits
2) Create a volume envelope in a lane, add some envelope points
3) Click and hold the mouse on one of the envelope panel buttons
4) Hit 'V' to hide the envelope without letting go of the mouse
5) Move the mouse
I am vote for this hundred times — this new feature is unrelated to the theming and such, it is for display compensation. And it has to be one and only visible thing for the "casual" user (as the all 98% users are).
While a bit torn about where the new UI Color Controls should be, I kinda agree with this. If we entertain the thought of having "all the theme things" in the same Themes menu, we'll have this:
Theme Adjuster (script) is in the Themes menu already. It's theme specific, works only with the Default 6 theme and some mods of it. The confusion amongst oddly high number of people who think old themes don't work in v6 seems related. Seems like some people assume Theme Adjuster should work with all the themes and then think Theme Adjuster or the old themes are "broken" in v6 because that is not happening. On the plus side, it's by far the easiest way to make quick adjustments to specific themes where it applies.
Theme Tweaker, which actually works with any theme. But how it works is theme dependent, so you'll have to know some hows and whys.
UI Color Controls which works the same regardless of the theme.
To me it seems pretty clear which one could actually cause least amount of confusion amongst common users *)...maybe apart from having to re-adjust the controls when changing themes. So instead of putting all the theme things under the same menu, I would support having only the UI Color Controls there, and making the more theme dependent/specific things accessible from actions, or at least having them in a separate menu section.
*) Doesn't necessarily apply to current users...we can already be in varying states of confusion.
Previously, PDC was added per plugin in chain, so even if you had, say, 3 plugins that each added 16 samples of latency, and your audio interface buffer size was 128 samples, you would get 384 samples of latency total.
With this new rework, you get 128 samples of latency. You would get another block of latency only if total latency incurred by plugins in the chain exceeds the size of the audio interface buffer. Obviously a huge improvement!
Ahhh! Now I understand thanks
Will rest with reainsert to check that doesn’t break!
Previously, PDC was added per plugin in chain, so even if you had, say, 3 plugins that each added 16 samples of latency, and your audio interface buffer size was 128 samples, you would get 384 samples of latency total.
With this new rework, you get 128 samples of latency. You would get another block of latency only if total latency incurred by plugins in the chain exceeds the size of the audio interface buffer. Obviously a huge improvement!
No additional CPU in the new implementation? If not, that sounds pretty impressive indeed!
Previously, PDC was added per plugin in chain, so even if you had, say, 3 plugins that each added 16 samples of latency, and your audio interface buffer size was 128 samples, you would get 384 samples of latency total.
With this new rework, you get 128 samples of latency. You would get another block of latency only if total latency incurred by plugins in the chain exceeds the size of the audio interface buffer. Obviously a huge improvement!
+ 1 for adding Preferences/Appearance/Theme and move there
Theme development: Show theme tweak/configuration window (link that page to existing action also)
colors tweaker
shortcut button for Theme adjuster
+1. I definitely support doing it this way.
Quote:
Originally Posted by White Tie
Similarly, the theme tweak/configuration window was moved from the menu to the action window when it became reckless to ignore that casual users were getting into all kinds of trouble because it they weren't aware that it had the potential to mess things up very quickly.
This has never really been the Reaper way and I don't think we should make an exception for this aspect. Like it or not, the theme tweaker has become vital and it is where everyone suggests going when a user dislikes/wants to change something. In fact, it is the ONLY location for changing some aspects that get changed constantly, like fonts/sizes. So we can't both say, hey there is this tool the majority of users are going to need at some point AND say we are also going to hide it so you don't do something stupid. Just put access to it in the prefs. Reaper has never treated its user base as stupid in the past. Same should apply here. The biggest danger of the theme tweaker is not that you can screw up your theme and accidentally save it. The bigger danger is that it isn't documented like other areas are.
Quote:
Originally Posted by White Tie
The 'User Interface Color Controls' is the very best thing Reaper can do to play its part in mitigating the consequences of the screen brightness war that's been going on in the monitor market for the best part of a decade. To you audio types, this is somewhat analogous to the loudness war, and has similar by products of a) most 'real people' not understanding nor really caring about it, and b) multiple uncoordinated piecemeal attempts to deal with it potentially just muddying the waters, so to speak.
I think there are a couple issues at play here. I don't think what we are talking about here is any kind of "brightness war". The issue at play is that monitors are getting larger. That resolutions are increasing massively. And it is just plain hard to see stuff. When most users are complaining about not enough contrast, they aren't complaining about just overall contrast. They are referring to contrast between different elements. So while I certainly understand the need to address this, if this is the answer to the "brightness war" I already have gamma and contrast and brightness right on my monitor controls. So this is more analogous to a software version of that with a few more options. And on the themes I've tried, like WT said it isn't changing any custom colors. Which on third party themes is a whole heck of a lot. On one theme I tried it only changed the color of the main toolbar So, if you read this thread and others, what you are going to find people asking for is the ability to change the contrast of individual elements - not the whole kit and kaboodle. Like Joe is talking about with mutes. Or Stevie is talking about with selected items not being bright enough. Right now, the only way to change that is by editing PNGs. I think at a basic level, regular users having to edit PNG files to create the right amount of contrast for them is something we want to avoid.
Quote:
Originally Posted by White Tie
If we treat it like a theming control - On the plus side, it would essentially supersede a great deal of disparate theme editing functionality for a vast swathe of users, by being infinitely easier to use. Massive win.
For me, that is the whole argument right there. I vote let's treat it exactly that way. Because we have so many things in so many different places right now. It just isn't manageable in its current state. If you have a tool like this or Amalgama's fantastic version in Prefs/Appearance/Theme and have access to everything the user needs to customize, then that indeed is a win for everyone. I would in fact argue that as a new user, that would be the first place they would look.
Quote:
Originally Posted by White Tie
If we chunk it in with the other theme controls, we reintroduce the need to know which of these many ways of changing things is the one you actually want, and why, and what would be the consequences of you doing something ill-advised.
I think the important thing to consider here is just WHY do we have things in so many different places right now. With some basic housekeeping we can organize this much better instead of having all these different tools in different places. If the argument is, we need to stop users from doing something stupid or ill-advised but that will also prevent regular users from making basic changes to an element and forcing them to edit PNG files, then what are we even talking about? There's lots of places a user can royally screw stuff up in Reaper. The solution is not to split everything theme and color related, put it in disparate places and make it harder to access imho. It is to put everything under one roof and document it. If we do that, then not only does it benefit users who just want to tweak something. It also benefits new users trying to navigate this stuff instead of every new user logging on to the forum and asking "hey where do I find this?" Heck, even experienced themers do exactly that because they don't know where stuff is.
To me that really would be a win-win and we have an opportunity to do just that.
Can confirm: same CPU, same ASIO buffer sizes, same projects with cca 180 tracks and 230 FX. Previous Reaper versions struggling to maintain a glitch-free playback, this version, smooth, rock-solid playback, no glitches whatsoever. Overall CPU usage, as measured by windows, looks the same.
It is enabled by default (for now) and you can change it per-FX-chain.
Also of note is the new Master-FX mode: for this mode, master FX with PDC should use less CPU (at the expense of delaying the other hardware outputs). We might eventually want to enable that by default (need to figure out what side effects it will have -- the big obvious one is that it will take longer to hear playback when it starts.. the traditional modes run faster-than-realtime, in that mode it would require realtime).
The solution is not to split everything theme and color related, put it in disparate places and make it harder to access imho. It is to put everything under one roof and document it.
An HDR LCD screen will be between 500 and 2,000 nits.
Sure but this isn't any kind of war per se. Just better technology. It's the same with projectors. If you had an older one, unless it was massive it had a lower lumen output. Now they make them much smaller with higher lumen output. Same with TVs being able to do much more accurate colors in a tiny frame. Saying higher nits is related to a brightness war is like saying HDR's wider gamut is a color war.
Last edited by Klangfarben; 04-29-2020 at 02:30 PM.
Can confirm: same CPU, same ASIO buffer sizes, same projects with cca 180 tracks and 230 FX. Previous Reaper versions struggling to maintain a glitch-free playback, this version, smooth, rock-solid playback, no glitches whatsoever. Overall CPU usage, as measured by windows, looks the same.
This is fantastic news!
Awesome software engineering as always.
Congratulations Justin, Schwa. You guys rock!
Same results here. Reaper's PDC handling has been near the top of my (admittedly shrinking!) gripes list for a while, and I'm so happy it's here. For me, this ONE new feature has improved -
Project play/stop/pause responsiveness
Mute/Solo/Undo/Redo responsiveness
General UI responsiveness
Overall CPU use, particularly realtime CPU
Complex routing scenarios with high PDC chains seem to be running more smoothly now too.
And so far with no downsides that I can tell. The larger your buffer size the bigger an improvement you will see from the new method of handling PDC. If you never run CPU heavy projects with lots of heavy latent plugins at high buffer sizes, then you will not notice a difference in the slightest. For everyone else, it's happy days!
Can not confirm any gains on Master.
Was testing with 16 heavy-weight FXs in a single chain with total PDC of 3072 spls, and no matter if it is on a folder track or on the Master track, no matter which PDC strategy used, CPU usage stays the same.
One curious side-effect: while I was moving FX chains left and right to test this, I noticed that I have "MIX" folder track that holds all other channels as a parent, with 4 FXs in it's chain, and then, one more folder track "MASTERING" as a parent to that one, with those 16 FXs in it's chain. Now, when I cut-paste MASTERING track's FXs into Reaper's MASTER track, nothing changed, as I reported above. But, when I tried to cut-paste those 4 FXs from "MIX" folder and add them to Repaer's MASTER channel, to combine all FXs together, the CPU was overwhelmed. From that moment on Reaper went into robotic-glitch-sound mode and nothing would help to fix that. What is baffling for me here is, how was Reaper/CPU able to process the same audio path with no problems when FXs were scattered 4 of them in one folder and then 16 more on it's parent, but can not cope when all of them are in one single chain combined? I can't wrap my brain around this.
[*]+ RS5k: increase max voice limit to 64, default limit to 8
It's great to see RS5K getting some love! While you guys are on the topic could you kindly take a look at updating the volume envelope controls? They currently aren't controllable enough to do the sort of volume shaping I need on drum tracks. It'd be really helpful to have a "hold" parameter, a curve control for attack slope, and a curve control for decay slope.
This has never really been the Reaper way and I don't think we should make an exception for this aspect. Like it or not, the theme tweaker has become vital and it is where everyone suggests going when a user dislikes/wants to change something. In fact, it is the ONLY location for changing some aspects that get changed constantly, like fonts/sizes. So we can't both say, hey there is this tool the majority of users are going to need at some point AND say we are also going to hide it so you don't do something stupid. Just put access to it in the prefs. Reaper has never treated its user base as stupid in the past. Same should apply here. The biggest danger of the theme tweaker is not that you can screw up your theme and accidentally save it. The bigger danger is that it isn't documented like other areas are.
I think there are a couple issues at play here. I don't think what we are talking about here is any kind of "brightness war". The issue at play is that monitors are getting larger. That resolutions are increasing massively. And it is just plain hard to see stuff. When most users are complaining about not enough contrast, they aren't complaining about just overall contrast. They are referring to contrast between different elements. So while I certainly understand the need to address this, if this is the answer to the "brightness war" I already have gamma and contrast and brightness right on my monitor controls. So this is more analogous to a software version of that with a few more options. And on the themes I've tried, like WT said it isn't changing any custom colors. Which on third party themes is a whole heck of a lot. On one theme I tried it only changed the color of the main toolbar So, if you read this thread and others, what you are going to find people asking for is the ability to change the contrast of individual elements - not the whole kit and kaboodle. Like Joe is talking about with mutes. Or Stevie is talking about with selected items not being bright enough. Right now, the only way to change that is by editing PNGs. I think at a basic level, regular users having to edit PNG files to create the right amount of contrast for them is something we want to avoid.
For me, that is the whole argument right there. I vote let's treat it exactly that way. Because we have so many things in so many different places right now. It just isn't manageable in its current state. If you have a tool like this or Amalgama's fantastic version in Prefs/Appearance/Theme and have access to everything the user needs to customize, then that indeed is a win for everyone. I would in fact argue that as a new user, that would be the first place they would look.
I think the important thing to consider here is just WHY do we have things in so many different places right now. With some basic housekeeping we can organize this much better instead of having all these different tools in different places. If the argument is, we need to stop users from doing something stupid or ill-advised but that will also prevent regular users from making basic changes to an element and forcing them to edit PNG files, then what are we even talking about? There's lots of places a user can royally screw stuff up in Reaper. The solution is not to split everything theme and color related, put it in disparate places and make it harder to access imho. It is to put everything under one roof and document it. If we do that, then not only does it benefit users who just want to tweak something. It also benefits new users trying to navigate this stuff instead of every new user logging on to the forum and asking "hey where do I find this?" Heck, even experienced themers do exactly that because they don't know where stuff is.
To me that really would be a win-win and we have an opportunity to do just that.
I have to say I agree with pretty much everything outlined here. A more cohesive and unified layout will be easier to use and (I dare say) will yield better results because of ease of use.
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
+ Appearance: add Options / User Interface Color Controls
has nothing to do with themes and colors.
It is like your monitor controls built into the software.
You set it once you buy a new monitor and forget about it.
I think it would be a fair working assumption that a complete overhaul of the way theming works is not going to happen in the next pre.
I don't think anyone here is expecting that. But we're having a discussion about the new tool, how people think it should be used, where it should go and how it relates/interacts with the current set of tools. So the discussion is pretty on-topic imho. And pretty important. If the devs want it moved somewhere else later we can certainly do that. But I would say at least let users chime in here before we move on to the next pre.
And why? In the Hell of a Gods of All Performances, why the REAPER was not in time? I.e, see — a good gig, boom! Itka first kick is trankated, where is my attack?
Such and other "complaints" received of. It's from the usual users (98%). How to be clean of it if is not a Reaper faults? It's your's, дебил и бездарность — quantize it, сука.
Sorry for my Russian, it's not nearly perfect.
Идиоты! Вам показали, и вы как стадо, ломанулись. Туда, откуда нет возврата. Что ж вы с собой хотя бы водички не захватили? Рипер — не для всякого. Случайного прохожего. Для вас, случайных, — Штайнберг, Аблетон, Штудио Айнц. В ассортименте.
Огромное количество недоделок, которые, в общем-то, на производство музыки никак не влияют, останутся здесь. Записать свой голос, гитару, бас плюс аккомпанимент — можно. Ещё и как лихо!
@
schwa, Justin — is it possible to make a zoom of MIDI-event as a whole by defult? As it is for now I'm double clicking. Say, I recorded a piece of geniality. But I would edit it — double-click — my music is in the left corner of my MIDI editor and it is small! Do not understand how a zoom function is work now, but please! Double-click, open up the my midi-ies in a whole! Not in a small part in the left corner. Hope you understand me.
Is there a way (when rendering via item selection) to have the item's text note info turned into the description info for the BWF metadata for that rendered out audio file?
That seems super useful for creating libraries/working on film etc
Or do most people doing this another way like using a region's name surrounding those items as the origin for the description
__________________ subproject FRs click here note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.