SWS Extension Updates

[gandsnut]

Any suggestion how to resolve this popup message when starting Reaper? Thx.

[cfillion]

Originally Posted by gandsnut

Any suggestion how to resolve this popup message when starting Reaper? Thx.

Delete /Library/Application Support/REAPER/UserPlugins/reaper_sws_extension.dylib. That's the older version.

[gandsnut]

Originally Posted by cfillion

Delete /Library/Application Support/REAPER/UserPlugins/reaper_sws_extension.dylib. That's the older version.

No file exists on my iMac beginning 'reaper_sws' The popup error window still appears. Thanks.

[cfillion]

Originally Posted by gandsnut

No file exists on my iMac beginning 'reaper_sws' The popup error window still appears. Thanks.

The path is written in the error message. It's in the (probably hidden) Library folder at the root of the drive (/Library), not the Library folder in the user directory (~/Library).

[svijayrathinam]

The search in the SWS resources window seems to be showing results for a boolean "or" search. I am not sure this is by design or a bug. It would be very useful if it shows a boolean "And" search. For example when I search in fx chains..if I type in "reaverb hall" it shows records saved with "fab filter hall" also. Instead it will be very useful if it shows only records saved with keywords "reaverb hall". Is this already possible ? if not can the developers pls take a look into this ?

[tonalstates]

In the Auto Color/Icon/Layout window we can add a rule for a folder named bus to change to layout "C" and be painted red i.e. BUT I have another theme which I use a lot too but the same layout as name "bus" = " Layout C" in one theme is named "Folder" in another and I can't add two rules with the same "bus" naming scheme, because one or the other will work.. So is it possible to add a way to discern between them? But being able to use the same "bus" naming rule. Even just referencing the theme or something like that.

Thanks!

[nofish]

Originally Posted by svijayrathinam

The search in the SWS resources window seems to be showing results for a boolean "or" search. I am not sure this is by design or a bug. It would be very useful if it shows a boolean "And" search. For example when I search in fx chains..if I type in "reaverb hall" it shows records saved with "fab filter hall" also. Instead it will be very useful if it shows only records saved with keywords "reaverb hall". Is this already possible ? if not can the developers pls take a look into this ?

Has come up here, with the tendency/consensus that it should probably default to boolean AND indeed.
However there are very few active SWS devs currently..

[gandsnut]

Originally Posted by cfillion

The path is written in the error message. It's in the (probably hidden) Library folder at the root of the drive (/Library), not the Library folder in the user directory (~/Library).

SOLVED. Geesh, a computer user since 1984 and I still don't pay attention to ERROR MESSAGES. Thanks a lot.

[mozart999uk]

Originally Posted by mozart999uk

Any chance this might be looked at for the next release?

https://github.com/reaper-oss/sws/issues/1512

Bumpity bump :-)

[nofish]

Originally Posted by mozart999uk

Bumpity bump :-)

It's acknowledged.
But (unfortunately), same reply as above (#2968):
SWS development goes quite slow currently.
It could desperately need more active contributers.
(Currently basically it's only cfillion and me doing it in spare time with limited capacity...).

[mozart999uk]

Originally Posted by nofish

It's acknowledged.
But (unfortunately), same reply as above (#2968):
SWS development goes quite slow currently.
It could desperately need more active contributers.
(Currently basically it's only cfillion and me doing it in spare time with limited capacity...).

Thanks so much :-)

I'd love to help but I don't have the scripting skills :-(

[Reflected]

is there a way to export all snapshots for selected track ?

is it possible somehow to add this feature?

if track snapshots will be saved within track templates, it could save lots of duplicated templates that sounds close to each other.

[sockmonkey72]

Originally Posted by Reflected

is it possible somehow to add this feature?

if track snapshots will be saved within track templates, it could save lots of duplicated templates that sounds close to each other.

For better visibility to the devs, SWS feature requests should go here (if not already present): https://github.com/reaper-oss/sws/is...Aopen+snapshot

[MonkeyBars]

I found an issue on github that is similar to a feature I posted about wanting to hire a dev for here. Just want to make sure it doesn't get lost in the shuffle. Any C++ devs want to give it a shot? I can't imagine it would be that difficult since it's leveraging a lot of existing code... just saving it in a different place... right?

https://forum.cockos.com/showthread.php?p=2423241
https://github.com/reaper-oss/sws/issues/483

[Reflected]

Originally Posted by sockmonkey72

For better visibility to the devs, SWS feature requests should go here (if not already present): https://github.com/reaper-oss/sws/is...Aopen+snapshot

it seems like no one is there

[sockmonkey72]

Originally Posted by Reflected

it seems like no one is there

There's quite a bit of activity on the 12.13 branch. Slow, but steady.

[karlingen]

Originally Posted by nofish

It's acknowledged.
But (unfortunately), same reply as above (#2968):
SWS development goes quite slow currently.
It could desperately need more active contributers.
(Currently basically it's only cfillion and me doing it in spare time with limited capacity...).

I would love to help out. I don't know much C/C++ but I know a ton of other programming languages. I even tried to contribute here https://github.com/reaper-oss/sws/pull/1563

But one thing I found hard was how to setup the development properly on a Mac.
Following the readme only showed me how to build the project, not how to the actual workflow and how to debug. So what I did was I opened the project in VS Code and modified a few lines, rebuilt it using the command line, and then dragged the compiled .dylib file to UserPlugins.

I'm sure there's an easier way to do this. Could please explain the steps needed to develop and debug more fluently?
That way it'll be much easier for me and new developers to help out with this awesome project.

[cfillion]

Originally Posted by karlingen

I'm sure there's an easier way to do this. Could please explain the steps needed to develop and debug more fluently?
That way it'll be much easier for me and new developers to help out with this awesome project.

The exact setup steps varies depending on the IDE and preferred workflows. I assume VSCode either supports CMake out of the box or does through an extension. The IDE would usually be configured to build the "install" target (which copies the .dylib and other files to the REAPER install, default is ~/Library/Application Support/REAPER) + launch the REAPER binary (either directly or through a debugger).

When using the command line to build/run/debug without an IDE, it's:

# build, install and run
cmake --build build --target install && /Applications/REAPER64.app/Contents/MacOS/REAPER

# build, install and debug (lldb)
cmake --build build --target install && lldb /Applications/REAPER64.app/Contents/MacOS/REAPER

# ...or attaching the debugger when REAPER is already running
lldb -p $(pidof REAPER)

[karlingen]

Originally Posted by cfillion

The exact setup steps varies depending on the IDE and preferred workflows. I assume VSCode either supports CMake out of the box or does through an extension. The IDE should usually be configured to build the "install" target (which copies the .dylib and other files to the REAPER install, default is ~/Library/Application Support/REAPER) + launch the REAPER binary either directly or through a debugger.

When using the command line to build/run/debug without an IDE, it's:

# build, install and run
cmake --build build --target install && /Applications/REAPER64.app/Contents/MacOS/REAPER

# build, install and debug (lldb)
cmake --build build --target install && lldb /Applications/REAPER64.app/Contents/MacOS/REAPER

Thanks, I guess it isn't as smooth as I had hoped it would be, but that'll work!

When I run:

cmake -B build -G Xcode

An Xcode project file is generated in the `build/` folder.
I assume we can use this project file to develop in Xcode instead.
The only problem with this is that all the code is in the `build/` folder thus making the changes ignored by git.

In an Xcode project for iOS, you'd have all the files embedded. So you'd make the changes to the source files inside of Xcode and only press "Run" in Xcode and it'll build and attach to the app in the simulator.

I'm sure I'm missing something important here. Again, sorry that I might ask stuff that is too basic to experienced C++ devs.

Coming from a web and app development background, this is a slightly different way of doing things I really appreciate the hard work you've put into all of this

[cfillion]

Originally Posted by karlingen

The only problem with this is that all the code is in the `build/` folder thus making the changes ignored by git.

Mhh normally only the IDE's project files and SWS build artifacts are put in the specified directory (.gitignore-ed since those don't belong in the repository). The source code shouldn't be inside 'build'. (I don't have access to Xcode right now, can test later.)

Originally Posted by karlingen

In an Xcode project for iOS, you'd have all the files embedded. So you'd make the changes to the source files inside of Xcode and only press "Run" in Xcode and it'll build and attach to the app in the simulator.

It should be like that.

By the way we also have a channel for discussing SWS development on The REAPER Blog's Slack workspace, send me your email if you'd be interested to join.

[karlingen]

Originally Posted by cfillion

By the way we also have a channel for discussing SWS development on The REAPER Blog's Slack workspace, send me your email if you'd be interested to join.

I'm not able to send a PM here, so I sent you an email instead. Thanks!

[daifdaifdaif]

Just a small bug(?) I noticed:

Using ReaConsole, I'm not able to add multiple instances of the same fx to a track.

E.g. if there's already a Pro-C 2 on the track, using the command "x Pro-C 2", it won't add an additional instance of Pro-C 2 to the track.

If this is planned behaviour, I'd be really happy if you could add the option (possibly a flag in the ReaConsole command) to add additional copies of the same fx to a track.

[UknownSource]

Originally Posted by Reflected

is it possible somehow to add this feature?

if track snapshots will be saved within track templates, it could save lots of duplicated templates that sounds close to each other.

+1 this can be really useful

[MonkeyBars]

Hi! I've been searching around but can't find a list anywhere, if it exists.

Does the SWS extension expose any functionality to ReaScript for (LUA) script devs? I.e. does it have an API? I'd love to hook into its great features directly in my scripts.

[nofish]

Originally Posted by MonkeyBars

Hi! I've been searching around but can't find a list anywhere, if it exists.

Does the SWS extension expose any functionality to ReaScript for (LUA) script devs? I.e. does it have an API? I'd love to hook into its great features directly in my scripts.

Sure.
https://www.extremraym.com/cloud/reascript-doc/

Every function with prefix, except ImGui_, JS_, ReaPack_ are SWS exported functions (e.g. BR_, SNM_), if I haven't missed anything.

[MonkeyBars]

Originally Posted by nofish

Sure.
https://www.extremraym.com/cloud/reascript-doc/

Every function with prefix, except ImGui_, JS_, ReaPack_ are SWS exported functions (e.g. BR_, SNM_), if I haven't missed anything.

Thanks so much Raym! I have been using this page and didn't realize that was the signifier.

I am specifically looking for an API hook into the SWS item selection set code, but looks like I will either need to trigger the scripts as an action or pull the code directly out of those scripts as needed.

[Phazma]

Not sure if this is the right place for SWS requests, but would it be possible to add (selected) as a Filter to the Auto Color/Layout/Window tool?

It would be very useful to be able to automatically change color or layout of a track when it is selected for more flexible ways of evidencing it.

[Reno.thestraws]

Originally Posted by Phazma

Not sure if this is the right place for SWS requests, but would it be possible to add (selected) as a Filter to the Auto Color/Layout/Window tool?

It would be very useful to be able to automatically change color or layout of a track when it is selected for more flexible ways of evidencing it.

Would be easier and more doable by using a defer script with layout actions.
iMHO

[sockmonkey72]

Originally Posted by Phazma

Not sure if this is the right place for SWS requests, but would it be possible to add (selected) as a Filter to the Auto Color/Layout/Window tool?

It would be very useful to be able to automatically change color or layout of a track when it is selected for more flexible ways of evidencing it.

Nice suggestion. I have a PR pending for some filter additions in that tool. Once we've ironed out the remaining issues there, I'd be willing to give this a look.

[Phazma]

@Reno.thestraws I know that it is possible to do via defer script but I believe if done via the SWS tool it would be more integrated/stable, more easily available and could be used seamlessly in combination with other rules without having an extra action running all the time. As we have so many filters already, even rec-arm, I thought why not selected track too. It would allow many options and fit in nicely with the existing filters IMO. Of course until they have time to do this, a script is a good solution.

@sockmonkey72 thanks for taking in consideration! Curious to see what additions will be in that tool. So far it has been very useful to me already.

[juan_r]

Originally Posted by Phazma

Not sure if this is the right place for SWS requests, but would it be possible to add (selected) as a Filter to the Auto Color/Layout/Window tool?

It would be very useful to be able to automatically change color or layout of a track when it is selected for more flexible ways of evidencing it.

Indeed. This has little to do with SWS, but Reaper needs a realiable/universal way to tell selected/unselected objects quickly. "Objects" includes tracks and items. I think a frame would work well. As it is now, depending on the color scheme, without context it's hard to tell if a given object is selected.

Sorry for the rant - again, it's got little to do with SWS.
At least, I think...

Maybe SWS can provide an elegant solution until the devs decide to provide a native solution?

[Raaphorst]

Is Normalisation broken?

When I Normalize an item 'Reset Volume and Normalize to -23 LUFS NORMAL' and measure it using the Loudness tool under Extensions it says at Integrated: -23. But the LUFS meter at LUFS-S shows a louder signal all the time. And when I export the clip I see on render it's -19.9 LUFS-I. Measuring it with YouLean, same value -19.9 LUFS integrated.

In my opinion it used to work a few versions back. Anyone other experiencing the same issue?

[nofish]

Originally Posted by Raaphorst

Is Normalisation broken?

When I Normalize an item 'Reset Volume and Normalize to -23 LUFS NORMAL' and measure it using the Loudness tool under Extensions it says at Integrated: -23. But the LUFS meter at LUFS-S shows a louder signal all the time. And when I export the clip I see on render it's -19.9 LUFS-I. Measuring it with YouLean, same value -19.9 LUFS integrated.

In my opinion it used to work a few versions back. Anyone other experiencing the same issue?

Since the difference between -23 and -19.9 is very close to 3 dB I suspect a mono vs. stereo scenario (plus maybe a small rounding thing), see if this post helps:
https://forum.cockos.com/showthread....27#post2192327

[Raaphorst]

Ha! Of course! Thanks.

And made me aware that the LUFS meter on Master will always read out any signal as stereo. Even if it's mono.

Good lesson. Thanks!

[sockmonkey72]

Originally Posted by Phazma

@sockmonkey72 thanks for taking in consideration! Curious to see what additions will be in that tool. So far it has been very useful to me already.

The tricky thing about the notional (selected) filter is that you presumably want to set it back to something when it's no longer selected. If you're using random colors, that's going to be annoying. You could just re-randomize it, but that's going to make no one happy. So probably we're looking at a selected item previous color cache being stored somewhere, which is possible but messier that any of the other existing filter types, which are essentially stateless. Just thinking aloud, there are probably elegant ways to handle it.

[Phazma]

Originally Posted by sockmonkey72

The tricky thing about the notional (selected) filter is that you presumably want to set it back to something when it's no longer selected. If you're using random colors, that's going to be annoying. You could just re-randomize it, but that's going to make no one happy. So probably we're looking at a selected item previous color cache being stored somewhere, which is possible but messier that any of the other existing filter types, which are essentially stateless. Just thinking aloud, there are probably elegant ways to handle it.

Didn’t think of these implications of a temporary color/layout change but what you say makes sense. Of course it should be only active during selection and go back to whatever it was before selection once it is no longer selected. And the implementation should be clean and not some hacky workaround, given that it is a tool many people have access to and use for different purposes.

I am not in front of Reaper now, but I am wondering how the (record armed) filter is dealing with this? Reaper gives the possibility of auto rec-arming selected tracks, which basically results in the same situation: the track state changes dynamically from rec-arm to non-rec-arm based on track selection and the user will probably want to switch forth and back between colors/layouts for these 2 track states. So I guess the (record armed) filter already has some solution built in for this?

[sockmonkey72]

Originally Posted by Phazma

I am not in front of Reaper now, but I am wondering how the (record armed) filter is dealing with this? Reaper gives the possibility of auto rec-arming selected tracks, which basically results in the same situation: the track state changes dynamically from rec-arm to non-rec-arm based on track selection and the user will probably want to switch forth and back between colors/layouts for these 2 track states. So I guess the (record armed) filter already has some solution built in for this?

I just tried, and this works only if (all) or whatever the next-in-line rule is using a non-random color. If it's random, it sticks at the armed color.

Reading the code, there's an explanation for this (there's a flag set when the color is set via this tool, and random doesn't re-run if that flag is set), but maybe this can be refined. In any case, there is no color caching happening right now, that would need to be added somehow.

[Phazma]

Originally Posted by sockmonkey72

In any case, there is no color caching happening right now, that would need to be added somehow.

Ok I see. Well that’s up to you SWS guys then to evaluate whether the benefits of color caching are enough and the performance price not too big to implement this or if you rather prefer to keep it less complex. Personally I would really appreciate seeing this implemented along with the (selected) filter.

[Raaphorst]

Originally Posted by Raaphorst

Ha! Of course! Thanks.

And made me aware that the LUFS meter on Master will always read out any signal as stereo. Even if it's mono.

Good lesson. Thanks!

Must say it would be nice if in the future an extra option was introduced so you could normalize a MONO and STEREO file in the same way (make the MONO 3 db louder) so your meters won't show a difference when working in STEREO which most people will do.

[nofish]

Originally Posted by Raaphorst

Must say it would be nice if in the future an extra option was introduced so you could normalize a MONO and STEREO file in the same way (make the MONO 3 db louder) so your meters won't show a difference when working in STEREO which most people will do.

It's already done (https://github.com/reaper-oss/sws/pull/1229).
Currently not sure when it will be available publicly though...