Chunk Track/Take FX: BYPASS - third value ? (SOLVED)

[nofish]

edit:
Solved, post #12


=== original post ===



Anyone knows what the third 0 indicates ?

According to Wiki , first is bypassed, second is offline but third isn't even listed there ?
edit:
Wiki is now updated accordingly, thanks IXix.

edit:
Ok, easier question
Is it possible to get offline state from an FX without chunk parsing ?

[X-Raym]

 reaper.TakeFX_GetEnabled( take, fx )
 reaper.TrackFX_GetEnabled( track, fx )

?

[nofish]

Thanks X-Raym.

Returns false when FX is bypassed though, so I can't use it I think as I need to exclusively detect offline state or ?

[FnA]

Curious... How do you suppose SWS implements these actions?

SWS/S&M: Toggle FX 1 (,2,3 etc) online/offline for selected tracks



It seems there is a bug or unfinished aspect to these actions. At 0:07 "toggle FX 3" should stay on after second track which complies is selected, no?

I'm curious how SWS implements that and actions such as

SWS/AW: Set selected items timebase to time

Something always running in the background? How do they do that?
Also REAPER's property window I guess.

[nofish]

Chunk manipulation for offline / online:

https://github.com/reaper-oss/sws/bl...nM_FX.cpp#L186

(note the comment in L. 216 - no dedicated API yet => state chunk update)

For some background stuff they use a fake control surface.

https://github.com/reaper-oss/sws/bl...nsion.cpp#L467

[heda]

The only way is chunk parsing
I only modify the second number in the chunk and maintain the other numbers.
We have been asking for this API function for GetSet offline/online plugins for long time, but I think devs don't read the API requests thread at all.
I think the way to request API is by emailing them directly.

[nofish]

Originally Posted by heda

The only way is chunk parsing
I only modify the second number in the chunk and maintain the other numbers.
We have been asking for this API function for GetSet offline/online plugins for long time, but I think devs don't read the API requests thread at all.
I think the way to request API is by emailing them directly.

Chunk parsing is what I'm doing now too.
And I just requested too, maybe they see it eventually.

https://forum.cockos.com/showpost.ph...&postcount=257

heda (or anyone), you don't happen to know what the third number is either ?
(Just out of curiousity.)

edit:
btw. I've experimented with making Get/SetOffline() available to ReaScript. Also uses (SWS) chunk parsing internally but may be a bit faster (due to more optimized / compiled SWS code) and more practical than doing the parsing directly in ReaScript. Only works for track FX currently though, not item FX.
PM me if you want to have a go at testing.

[nofish]

Here's a SWS test build (Win64) which adds the following ReaScript functions (Lua example):

boolean reaper.NF_TrackFX_GetOffline(MediaTrack track, integer fx)
reaper.NF_TrackFX_SetOffline(MediaTrack track, integer fx, boolean offline)

reaper.NF_TakeFX_GetOffline(MediaItem_Take take, integer fx)
reaper.NF_TakeFX_SetOffline(MediaItem_Take take, integer fx, boolean offline)

if anyone wants to test. Feedback appreciated.
As always, better not use in real projects (for now).

https://www.dropbox.com/s/ni8odfe2mi...sws64.dll?dl=1

(The ReaScript doc you get with action "ReaScript: Open reaScript documentation (html)..." is updated for these.)

[FnA]

Thanks for the links.

What kind of test do you want? Just loop over a bunch of tracks/takes, take some time precise() measurements, ... ?

I don't really have any fancy usage in mind myself. Not that it's not a good addition to script functions. I mostly stick to scripts that are a few dozen lines at most.

I have two Windows 7 x 64 machines. One is a not very good i3 laptop with a bunch of non-daw crap on it. That's the one I usually test a pre on, etc. The other is much faster i7 desktop that I hesitate to take chances with, but I guess there should be no problem trying something in a portable install there if it was helpful somehow?

[nofish]

Thanks for offering testing FnA.

Actually testing about speed I didn't have in mind at all. As it uses the already present SWS chunk parser/patcher it is what it is speedwise.

I was rather thinking about just using it and making sure it works correctly and doesn't break anything as chunk manipulation is a bit of a touchy thing (though as I didn't change anything of the actual SWS chunk manipulation code I'd think it's ok.)

[FnA]

Do you prefer I use Lua or Eel? I mean, if you have tested one or the other less yourself or something like that. I can do Python too, I suppose, but mostly don't bother with that anymore and my Python install is old now too...

[Justin]

The third value is only set if the plug-in is offline and should be floated when brought back online...

[nofish]

Thanks Justin. So the Wiki can now be updated.

http://wiki.cockos.com/wiki/index.ph...rack.2FTake_FX

[nofish]

Originally Posted by FnA

Do you prefer I use Lua or Eel? I mean, if you have tested one or the other less yourself or something like that. I can do Python too, I suppose, but mostly don't bother with that anymore and my Python install is old now too...

Whatever you see fit.
I've only tested a little using Lua.

Thanks.

[FnA]

I used Eel a little with the track FX functions. So far just for switching offline. Seems ok mostly.

Except maybe complicated concerning third 0. REAPER seems to modify this only when switching Offline, not when closing window. Script (edit-I mean your extension) is obviously not modeled on that, because no one knew about it. I wonder if you will want to change the build. So I hold off on further testing a little...

[nofish]

I see what you mean with the third value.

The thing is when offlining a floating FX via extension / script the third value is not set to 1 automatically. Hadn't noticed this, thanks. Makes sense though now that I think about it.

It would be possible to account for this in the extension (check if FX is floating before offlining, if so set value to 1. And when onlining, check for third value, if set make it float).

But this would involve several more chunk juggling (speed). Besides if desired to make FX float when onlining it can be done in a script directly using Track/ItemFX_SetOpen() I think.

So I think I rather leave it as it is now.
Besides, using SWS actions "Set FX offline / online" also don't account for the third value it seems. If you set a floating FX offline and bring back online with these actions, the FX doesn't float either (maybe because third value wasn't introduced / known yet when these were written), so I guess that may be a reasonable excuse to have my extension act the same.

[FnA]

Hi, interesting pre going on now too. Unfortunately no time for that or scripts for a few days . I am on phone now...

I am ok with just the main entree meat and potatoes thing. The third integer is kind of nitpicking thing. So I don't have a really strong opinion about the following. I guess I was looking at it from perspective of recalling unexpected windows with reapers native actions because that's how I ran into it.

So it looks like you would have to do chunk twice to even return a variable for scripter to use when on lining. 1 read 1 write. Maybe best to forget that then...

But what about setting the third number when off lining? Would optional second variable be troublesome? (Edit. Maybe multiple choice int?) Seems that would not be heavy addition speed wise.

Also, would it be any good to have the Get function gets the other numbers too? I don't know if third number is really useful but seems like some scripter might want bypass info too. He wouldn't have to run a different function then. Just some ideas. Thinking out loud basically...

[nofish]

I've now made it so:

If a FX is floating when offlining, it'll float again when bringing back online.
I think that makes the most sense to me as it matches Reaper behaviour.

Link in post #8 is updated with the new version.

[heda]

hehe.. your excuse was good, but you couldn't avoid doing the right thing I'll try to test it. It sure does work better than chunk edits in Lua, which I am never sure if they work well.

[nofish]

Originally Posted by heda

hehe.. your excuse was good, but you couldn't avoid doing the right thing

You so hit the nail on the head it made me laugh !

Thanks if you get round testing it.
I mainly started this because it annoyed me a bit that for such seemingly common thing as offlining / onlining FX we need to resort to chunk manipulation in scripts.

[FnA]

I will poke around that with some simple scripts over next few days.

Glad if heda will test, because I don't have experience with chunk issues myself.

[nofish]

Thanks for the offer Veto.

I don't know how to "pass a patch" though or what this means.
(Explaination welcome)

But - I can push the branch to my SWS fork on GitHub tomorrow (gotten quite late here already.)

This should also do or ?

[nofish]

Ah now that you say git feature.

I've seen that feature at some point but never used it so far.
I'm using SourceTree as git client and there it seems to be as easy to create a patch (just right-click commit(s) -> Create patch).

So here it is:
https://www.dropbox.com/s/rg9rshh0t0...ions.diff?dl=1

I've now also pushed the branch (but didn't submit a PR yet).
As I know you're also doing SWS contributions I'd appreciate if you (or anyone) is motivated to have a look at the code and share your thoughts (I'm still rather a beginner when it comes to C++). I've tried to comment quite thoroughly.

https://github.com/nofishonfriday/sw...cript.cpp#L977

[nofish]

Thanks for having a look, appreciated.

Compiling it here with gcc 4.8.4 I got errors "invalid conversion from ‘const void*’ to ‘void*’"
It looks like ParsePatch() needs a mutable string (char foo[]="bar") as 7th argument ("foo" only is immutable).

I wasn't aware of this, as compiling with MSVC I didn't get any errors, so that's valuable info. Fixed.

Or did you want to use Parse() instead?

Looking through it, I indeed used ParsePatch() in some places where I could have used Parse(). Changed.

- concerning issue 913 maybe for the final version add a note to the reascript help file that this function is a no-op if recording. It could be confusing for users if before or after the call of this function other stuff is happening and a scripter did not take account for this (because he did not know).

Good point. Done.

Otoh other functions like BR_MIDI_CCLaneRemove() or BR_MIDI_CCLaneReplace() would need that note too.

I'd think that's a bigger project to tackle when is finally decided if the check should stay or not.

- return -1 if no fx is found at FX idx

I see the usefulness but the thought was (for consistency) to make the function signature like the similar native API functions for bypass state Track/TakeFX_GetEnabled() which also return a bool and ...SetEnabled() returning void.

The patch and git repo is updated (though I did a amend / push force to not clutter SWS commit history), so if you get round to try to compile again let me know how it goes now.

Thanks again.

[nofish]

You're right, I missed these three you mention, now fixed.

Maybe there's a similar option set in MSVC?

I have to keep this in mind.
Actually I just started looking for it but I gave up already again for now.
So much options, warning levels etc. to wade through.

I see, not great (no distinction between onlined FX and simply no FX) but not a big problem.

Yeah, maybe I should have not done the "consistency" approach to start with. Actually I don't fully understand why Justin didn't make the bypass functions also more useful as you say.
But I think I'll leave it as it is for now, as there are other functions scripters can use to check for FX presence.

[nofish]

Thanks for digging for me.

However...



I think that's because even though I use VS 2017 the SWS project is still a VS 2013 project and '/permissive-' was introduced in VS 2015.

So I guess I'm out of luck here.