But when I updated it to the new SWS Extentions release the bug still exist. Can you pls take a look at this ?

Hi This take fx channel bug is still not fixed in ver 2.9.8.

Can you pls fix this ?

I reported this long time ago and nofish made a temporary fix. But Now I find new feautures in SWS extension ver 2.9.8 that I want to use. But the old bug still remains..Can you pls fix this ? if not..@nofish could you pls make another temporary fix with the new version ?

I would like to know what steps I should follow to contribute some code to SWS.

I uploaded the code to my fork at GitHub, and submitted a pull request. (I am not quite sure that I did everything correctly, since this is my first time doing pull requests.)

Is there anything else I should do? I notice that the most recent SWS installer is v2.9.7 of September 2017. There have been numerous other pull requests since then, most by cfillion, but none have been incorporated into a new SWS version yet.

EDIT: I would appreciate it a lot if someone could test whether my code builds correctly on MacOS and Linux.

I'm not an 'official SWS maintainer' but I did some contributions to SWS in the past I may answer some things.

- It's a good idea to start working from the next branch, rather than master branch as you did, since the 'next' branch contains all the latest code changes.
In short (don't know how familiar you are with Git branching), 'master' branch contains the code for official SWS releases, the 'next' branch is where ongoing development happens and is used for pre-releases, so it's usually ahead of the master branch. (Rundown of the branching approach, 'Develop' branch is the equivalent to the SWS 'next' branch.)

edit:
A common approach is also, rather than working on 'next' directly, to start a new local branch from next (= 'feature branch' in above link) when working on something and then pull request that branch when done. This enables working on stuff in parallel for example by simply switching branches.

- Similarly pull requests should be submitted to 'next' branch, rather than 'master' branch. (As mentioned in the README).
edit:
To clarify, you can choose which branch your pull request should be merged into when creating it on GitHub:

- It's suggested to update the whatsnew.txt, if you add new stuff, as mentioned here.

As said, I'm no SWS maintainer, so just take it as 'good practice suggestions' (other contributors may correct me).

As to your PR itself, Tim (SWS) is the current maintainer (afaik) and handles merging of PR's so he'll probably approach you if he wants something changed etc.

For live performance, I have a project where I'm using Regions to indicate "songs" and within the regions, I'm using markers for song bits (intro, V1, C1, etc).

I've been making a new project every time I want to change up the set, but that isn't really fast or fun. The regions make it a little easier to copy/paste songs in the order I want, but why not use the Regions Playlist extension??

Well...It seems that the Regions Playlist editor thinks that a marker means jump to the next region. Boo. Yeah yeah..."Just delete your markers!" But I WANT the markers AND the regions!!

Is there a way to make the Regions Playlist tool ignore the markers and only follow the regions? I understand the appeal of the current method, but it would be nice to be able to turn the sensitivity to markers on/off with a toggle or something.

I just installed the SWS extensions and maybe I'm nuts but for the life of me I can't find the SWS Track/Mixer/Envelopes menu in the track control panel context menu. According to the SWS manual, it should be under "SWS Snapshots" but my context menu ends at SWS Snapshots.

I've posted this under Gitub but i wanted a little more attention and couldn't find the sws request/general thread.. Hope it isn't out of place to post here..

I'm the drummer and system playback engineer 🥇 in my bands and I use a small 10 Touchscreen only windows system for Multitrack playback live , therefore the region playlist text is very small and hard to see so i switch it to monitoring mode(which is nice and clear)

The problem is now there is no way to navigate the setlist via midi controllers.

The key to this is that some songs/regions must smoothseek to the next song/region, but sometimes i have to pause/stop inbetween and also skip these smoothseeking songs/regions so i can't use seperate playlists.

I tried to make some custom actions

This resets the the whole list
-play next region based on currently playing region
-stop

This has erractic behaviour
-play next region based on currently playing region
-pause

Here's what i'm wanting

goto/select Next Region in current playlist (In Non Playing State or stopped without playing next region)
goto/select Prev Region in current playlist (In Non Playing State or stopped without playing next region)
Play Currently Selected Region In Region Playlist (When stopped)
Stop Currently selected region and stay selected ready to play again

Ultimately would be awesome if its available when in monitoring mode..

"SWS/S&M: Remove all envelopes for selected tracks" has an issue in that version causing it to freeze if the master track is selected. I think it's still worth updating though, unless you rely on that action working on the master track.

"SWS/S&M: Remove all envelopes for selected tracks" has an issue in that version causing it to freeze if the master track is selected. I think it's still worth updating though, unless you rely on that action working on the master track.

(The fix is ready – just waiting to be put in an official release...)

Thanks for the answer mate! Actually I do use that specific action on master track, but if the official release fix is coming I think I can wait a bit longer.

Hi! May I leave here a little feature request: in Auto Color/Icon/Layout please add a little check box about case sensetivity. This thing may be useful for auto coloring folder tracks written all caps, like 'GUITARS' and will not touch 'Guitars' tracks. Thanks!

Hi! May I leave here a little feature request: in Auto Color/Icon/Layout please add a little check box about case sensetivity. This thing may be useful for auto coloring folder tracks written all caps, like 'GUITARS' and will not touch 'Guitars' tracks. Thanks!

Hi! May I leave here a little feature request: in Auto Color/Icon/Layout please add a little check box about case sensetivity. This thing may be useful for auto coloring folder tracks written all caps, like 'GUITARS' and will not touch 'Guitars' tracks. Thanks!

I agree for BUS distinction and/or parent folders of similar names etc

EDIT2: Should this ReaScript be inserted before the SWS action and the Zooming? I'm not sure how to integrate it with my current Custom Actions. I'd appreciate any clarification please

It replaces the SWS action. It does the exact same thing except, because it doesn't write to the ini file, the setting is restored the next time REAPER is started. This might be preferable depending on what you want.

But I doubt it makes any difference on performance (also Lua is likely imperceptibly slower – it needs to be read, parsed and interpreted...). The SWS action should be just fine as-is.

Sws stopped its development after sep 2017 isnt it?? or they moved to some other site??

Sws can simply be merged with reaper 6.0. if reaper installer integrates and dissolves sws within it . it would be very much handful for most reaper users. why we need an extension why cant it be within and merged with no extra efforts???

Sws stopped its development after sep 2017 isnt it?? or they moved to some other site??

Development is still going, there just hasn't been a new release. The main guy (swstim) doesn't have enough time to go through the changes/fixes that have been submitted.

Quote:

Sws can simply be merged with reaper 6.0. if reaper installer integrates and dissolves sws within it . it would be very much handful for most reaper users. why we need an extension why cant it be within and merged with no extra efforts???

This will probably never happen, because then Justin and Schwa would have to take over responsibility for a huge pile of extra code that they didn't write. Programmers hate, hate, HATE doing that.

I have an issue with the SWS actions "SWS/S&M: Map selected tracks MIDI input to channel 'x'". This causes Reaper to freeze for a second or two and leaves hanging MIDI notes sometimes. When I do this from the track input dropdown menu it works smoothly, it appears that it's the SWS action that is acting strange.

I have an issue with the SWS actions "SWS/S&M: Map selected tracks MIDI input to channel 'x'". This causes Reaper to freeze for a second or two and leaves hanging MIDI notes sometimes. When I do this from the track input dropdown menu it works smoothly, it appears that it's the SWS action that is acting strange.

Any tips?

Cheers!

SWS uses a rather 'hacky' way to do this (chunk manipulation), which is not ideal in live situation I guess.

I think best alternative would be if we had these actions natively so I'd suggest doing a feature request.

Netflix of all places just changed its requirements. We now need to use the pure 1770.1 version of the loudness measurement standard for their stuff.

There are other tools to do this, but everything is slower than Reaper, where I normalize the items of the 5.1 or 2.0 mixes and do the split-to-mono playouts that I need to pack up and send off. With other tools there's at least one more inbetween step, as none of them seem to be able to generate single-channel files. Thus, I'd rather use Reaper, even if I need to get another tool in the meantime. It's just the better tool.

The Loudness portion of the extension uses the BS-1770.3 or 4 method of measuring as well as the EBU R128 recommendation.

-edit-

It's a little more complicated than just the 1770-1 mode (loudness measurement with no relative and absolute gate)

Reaper's extension architecture just lends itself so well to offline scanning, that I'm hoping there's a programmer with a spare few hours to slot in an extra mode in to the existing Loudness portion of the SWS extension.

It converts the input to 16kHz, runs it through a bunch of detectors and combines the results to get a value on whether speech is there or not.

The algorithm produces a 0 or 1 per sample, so that's a per-sample gate applied to the audio stream. That response has a set delay too, which makes it easier to compensate. The details are more difficult to fathom for an amateur coder like myself.

The gated audio is then fed to the 1770.1 measuring algorithm.

Basic structure seems simple. I'm just not sure we can share the source code like is done with the whole SWS extension.

Netflix of all places just changed its requirements. We now need to use the pure 1770.1 version of the loudness measurement standard for their stuff.

There are other tools to do this, but everything is slower than Reaper, where I normalize the items of the 5.1 or 2.0 mixes and do the split-to-mono playouts that I need to pack up and send off. With other tools there's at least one more inbetween step, as none of them seem to be able to generate single-channel files. Thus, I'd rather use Reaper, even if I need to get another tool in the meantime. It's just the better tool.

The Loudness portion of the extension uses the BS-1770.3 or 4 method of measuring as well as the EBU R128 recommendation.

-edit-

It's a little more complicated than just the 1770-1 mode (loudness measurement with no relative and absolute gate)

Reaper's extension architecture just lends itself so well to offline scanning, that I'm hoping there's a programmer with a spare few hours to slot in an extra mode in to the existing Loudness portion of the SWS extension.

I've created a simple signal flow diagram, derived from the description in the Dolby Dialogue Intelligence documentation.

Where the global dialogue intelligence gate sits is where the Relative Gate sat of the 1770-2/3/4 specification.

However, each channel is individually gated with the dialogue intelligence gate first as well, before being added up to a global loudness number. I'm not sure why the global result is gated again.

Thus, this is dialogue intelligence combined with the first version of the 1770 specification.

Note the Delay block. This is to compensate for the 2048 ms delay of the dialogue intelligence algorithm.

More detailed information is available in the documentation of the Dialogue Intelligence source code package. Please keep in mind that the specification that is the basis of this request requires the use of the 1770-1 spec, not the 1770-2 spec as detailed in the dialogue intelligence documentation.

The target level is -27 LKFS of integrated speech-gated loudness across the selected item. The reference might very well be the Nugen LM Correct tool, which is an offline, one at a time file processor(and audio suite plugin for PT).

Right-click and "View Image" to get the full sized image if you're viewing this forum in the Reaper 5 theme, which downsizes large images.

Technically I'd be allowed to merge PR's, Tim ('sws') gave me privilege to do so at some point, but this was mainly for being able to close issues, I don't feel entitled as a co-maintainer as there was never talk about it, so I refrain from doing so currently.