[WaveTrans]

As suggested from you, Geoff, quoted below, I checked all paths and removed any paths which may involve the plugins folder;
also checked for any old CSI .dlls in the plugin folder and elsewhere.

Reaper start-up then indicated loading of the CSI plugin, which appears separate from the vst scan performed.

Unfortunately CSI does not show up in the menu.

I then tried if any eucon plug dependencies are causing this as Funkybot suggested (see below) which made me wonder how to install it in the first place.

Not shure, if it´s correct but tried it like this:
- downloaded and put the “reaper_csurf_eucon64.dll” into the RRP/userplugin folder
- copied the most recent CSI .dll into RRP/plugin folder
- copied the most recent CSI folder into the ReaperResourcepath (RRP)

started Reaper using desktop shortcut and double clicking project.
According to the startup notification of Reaper, the CSI Plugin is loaded.

Unfortunately, no CSI in the control surface mode pull down.
copied thereaper_csurf_eucon64.dll also into the plugin folder but no change.

copied the .dll from 14th in, CSI is available again and works fine.
Checked it for Sends/FX all works fine with the build from 14th. (Found out that if the FXMenu is opened via controller, FXzones work well; however,
if the FXmenu is closed by mouse, the controller loses contact.) Also checked native MCU mode which also works well.

One mor observation: if I set up CSI using the 14th build and save the project, the controller is recognized and in working order upon reload of the project.
If I then replace the build .dll from 14th with any build .dll released afterwards, upon project load the controller stays dead, the previously
working CSI pages are not shown and the CSI plugin is not llisted in the control surface mode pull down.

Apart from the possibility that I did not install the eucon plug correctly, I wonder if there are any hidden and/or more fundamental differences between
the build from 14th Dec 2019 and the more recent versions which make the plug invisible for reaper? I can only check the name, which is the same as of all builds

As mentioned in a previous post, the 26th of December .dll also worked until I replaced it with the 31st Dec 2019 and 1st of january 2020 versions.
since then this strange behaviour occurs.

Anything else I can do to help resolve this issue?

Originally Posted by Geoff Waddington

Hmmm...1

Seems strange that the vst scan is picking it up.

That could mean that there is a copy of the csi dll in the vst search path, or the vst search path is pointing somewhere it doesn't need to (and probably shouldn't), or both.

Check all this out, you may be on to something here.

Originally Posted by Funkybot

Just to provide an external frame of reference: if I launch Reaper here, the splash screen appears, it says "scanning plugins" for a while (I believe this is a check for new VST2/VST3 plugins), then some text will flash really quickly, and in that I'll see something like "Loading Plugin: csuf_eucon_64.dll" and some others wizz by. I think that's Reaper loading "Reaper Plugin" .dll's, not necessarily treating them like VST2/VST3 plugins. Is that what you're seeing? If so, that might be normal (works here anyway).

But definitely go in and make sure that you don't have the "Reaper (x64)\Plugins" folder listed as a VST Plugin Folder in your Reaper preferences. I could definitely see that causing issues.

But, you've been using CSI for longer than I have, so I suspect it's not that and there's something else going on. It seems weird that at least 3 people (all on Windows? I am, but again, it works here) have suddenly reported issues with these newer releases, starting at the same build and persisting across a few builds.

Last question/thing to check: are you also installing the new CSI Eucon.dll from Geoff's signature? I have been. Even if you don't use Eucon, try installing the CSI eucon .dll anyway. Maybe a dependency somehow got built in. That's a total shot in the dark, but I'm a Eucon user, so it just sticks out as an area where maybe we could be doing things differently. And it's also the build where Geoff introduced Eucon that caused the issues so I wouldn't be surprised if there's some Eucon related dependency that accounts for why it works here and not on other systems. Again...total guess. But just trying to rule things out.