Trouble with SNM_GetIntConfigVar()

[tparker24]

I was testing "REAPER v6.10/x64" on Windows in a portable install. One of my scripts ran into problems, which I tracked back to strange results from SNM_GetIntConfigVar(). I was trying to get the value of "midiouts" from my "reaper.ini" file:

Interactive ReaScript v0.8.3 by cfillion
Type Lua code, !ACTION or .help

> reaper.CF_GetSWSVersion("")
"2.12.0.0"
> reaper.SNM_GetIntConfigVar("midiouts", -1)
-1
> reaper.SNM_GetIntConfigVar("midiouts", 123)
123

And yet an excerpt from my reaper.ini does show the lines:

[REAPER]
midiouts=1056760

So I don't know why SNM_GetIntConfigVar doesn't seem to be finding "midiouts".

It does find it ok on "REAPER 5.99x64" with SWS "2.10.0.1":

> reaper.SNM_GetIntConfigVar("midiouts", 123)
1056760

Thanks for any help.

[Meo-Ada Mespotine]

The midiouts-configvar is the one currently in memory, it does not necessarily reflect the same value in the reaper.ini

The reaper.ini-entry is loaded once at start, so I would guess, that some script changes the config-var, without changin it in the reaper.ini as well. As soon as it's changed as config-var, it is different from the one in reaper.ini without having a negative effect on Reaper.

What I'm wondering though, that the values are so high. According to my docs, midiouts can only be 1 or 0.

https://mespotin.uber.space/Ultrasch....html#midiouts

Which menu let's you change the reaper.ini-value as well? Would love to add this missing information to my docs.

[tparker24]

Thanks for the response.

Originally Posted by Meo-Ada Mespotine

I would guess, that some script changes the config-var, without changin it in the reaper.ini as well. As soon as it's changed as config-var, it is different from the one in reaper.ini without having a negative effect on Reaper.

In my example, I wasn't really running a serious script, but just calling SNM_GetIntConfigVar interactively.

What I'm wondering though, that the values are so high. According to my docs, midiouts can only be 1 or 0.

midiouts is a bit map for up to 32 midi hardware devices. Each bit position gives the "enabled" status of that device (0 or 1). The returned number can be large, because it's a decimal value of the binary bit map.

Which menu let's you change the reaper.ini-value as well? Would love to add this missing information to my docs.

Preferences|Audio|MIDI_Devices let's you change the enabled status (under the "Mode" column).

[Meo-Ada Mespotine]

Originally Posted by tparker24

Preferences|Audio|MIDI_Devices let's you change the enabled status (under the "Mode" column).

Thanks, will look into it. Maybe I see more of its behavior, when toying around with it. There a few configvars who behave a little strangely, maybe this is one of them.

[cfillion]

midiouts is a 64-bit value and SNM_GetIntConfigVar returns a 32-bit integer. SWS 2.11+ checks the size to prevent buffer overflows when writing.

In reaper.ini (likely because the Windows API .ini integer functions are 32-bit), midiouts is split into two 32-bit values: midiouts and midiouts_h (storing the the low and high doublewords respectively).

Extensions-exported API functions cannot have 64-bit integer values as arguments or return value. This might be an oversight or a bug though, because the REAPER-exported RecursiveCreateDirectory takes a 64-bit integer as second argument.

SNM_GetDoubleConfigVar reads 64-bit values but you'd have deal with the floating point representation.

A workaround could be to add {Get,Set}LongConfigVar functions that split the value:

> -- midiouts is 0x1000001fe
> reaper.SNM_GetLongConfigVar('midiouts')
{true, 510, 1}

[Meo-Ada Mespotine]

+1 for SNM_GetLongConfigVar, this seems to be a very helpful thing. With that, I could improve my configvars-docs with 64bit-integers as well.

The 64bit-behavior probably also explains, why I didn't notice that this variable can store much more...

[tparker24]

cfillion, thanks for the info. I wondered what that midiout_h was.

I see now that there are over 20 of these <item>_h things in reaper.ini. So that may affect many more folks. However, many of those items seem to be "false positives" in that I think the "_h" just stands for "height". But the bulk (over 1,000) of the items don't have the corresponding "-h". How is the user to know, in advance, which do and which don't?

Another thing, the previous SNM_GetIntConfigVar apparently worked differently, because it does return midiouts (and I guess, just ignores midiouts_h?), whereas the new SNM_GetIntConfigVar returns an error.

I don't know which behavior is better: return half the data, or return nothing -- probably the latter. But it may break lots of existing reascripts?

This seems like it's becoming quite difficult. The user will need to somehow know in advance whether the item they want is 64-bit (with the halves) or not.

Or maybe they can just always use your proposed SNM_GetLongConfigVar, and check both halves -- assuming that it will also handle a 32-bit and just return 0 if there is no "upper half"?.

[Sorry for the rant]

[cfillion]

Here are test builds for the new functions (Linux and Windows): https://github.com/reaper-oss/sws/pu...ment-630351908.

Originally Posted by tparker24

The user will need to somehow know in advance whether the item they want is 64-bit (with the halves) or not.

Yeah, configvars are completely undocumented, so it's a good thing there are custom documentations like mespotine's.

Originally Posted by tparker24

Or maybe they can just always use your proposed SNM_GetLongConfigVar, and check both halves -- assuming that it will also handle a 32-bit and just return 0 if there is no "upper half"?.

The hardened implementation requires the sizes to exactly match. SNM_GetLongConfigVar (and the corresponding Set function) return false if the configvar is 32-bit. There is no way to distinguish a 64-bit integer value with a 64-bit floating point one though... but at least I think this behavior is the safest and least surprising.

[tparker24]

Thanks so much.

Originally Posted by cfillion

Here are test builds for the new functions (Linux and Windows): https://github.com/reaper-oss/sws/pu...ment-629926475.

I'd like to help test, but frankly I'm at a loss on how to get the test build on github. Please advise.

Originally Posted by cfillion

I think this behavior is the safest and least surprising.

That's the ticket!

[cfillion]

Originally Posted by tparker24

I'd like to help test, but frankly I'm at a loss on how to get the test build on github. Please advise.

Click on the line with "Visual Studio 2019, ARCH=x64" (for Windows 64-bit) and download the .exe installer. Then the install process is as usual.

[tparker24]

Got it, thanks!

[tparker24]

The test version of SNM_GetLongConfigVar is working great in python!

Thanks a bunch.