goli4thus / linvstmanager Goto Github PK

View Code? Open in Web Editor NEW

53.0 53.0 2.0 765 KB

Graphical companion application for various bridges like LinVst, etc.

License: Other

CMake 1.90% QMake 1.06% C++ 94.55% C 0.33% Python 0.29% Dockerfile 0.61% Shell 1.26%

linvstmanager's People

Contributors

Stargazers

Watchers

Forkers

dreamcat4 perlindgren

linvstmanager's Issues

List update issue on conflict status + remove function

I was messing around with some plugins in VM and came across this small issue (don't have time right now to check if it's repeatable, but something tells me it is):

I previously had some plugins which i've removed physically and they had status NoBridge in list
I've installed another versions of those same plugins to some other path and then added them to the list (hence name conflict was suggested)
I've decided to remove older versions from list, those with NoBridge status so switched to NoBridge filter to the right and had removed them with Remove VST function
After that they've been removed from list, but those who get conflict still had Conflict status wherever i do (i've tried resetting filtered etc)
After saving and rebooting program - it have been updated fine

Preferably list should be refreshed and Conflict status should be resolved in such case in runtime...

Loading VSTs was working before, but it doesn't work anymore.

I keep getting this error when trying to load VSTs on Reaper. It was working before, I don't know what changed.

"The program lin-vst-servertrack32.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience"

This is what "Show details" says:

Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x10004159).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:10004159 ESP:0032e9a0 EBP:7d6644e0 EFLAGS:00010246(  R- --  I  Z- -P- )
 EAX:00000000 EBX:00000000 ECX:00a50c38 EDX:00a50c38
 ESI:00a52710 EDI:433d4154
Stack dump:
0x0032e9a0:  0032ea60 00000001 7d6644e0 00000000
0x0032e9b0:  00000000 00a50c38 00000000 7e8f0470
0x0032e9c0:  00000000 00000000 00000000 7d69ff90
0x0032e9d0:  00000000 7e8f0470 7d69ff90 7e8f0470
0x0032e9e0:  05800001 7e8f0470 0032e9f8 7d615f70
0x0032e9f0:  00000000 7e8f0470 7d615f70 7e7dc15a
Backtrace:
=>0 0x10004159 VSTPluginMain+0xc49() in csr plate (0x7d6644e0)
  1 0xf77ef000 in winex11 (+0x8efff) (0x7e9fcb90)
  2 0x7e9ecae0 _ZN15RemoteVSTServerD2Ev+0xef() in lin-vst-servertrack32 (0x7e9ec9f0)
  3 0x81ffffde (0x59e85356)
0x10004159 VSTPluginMain+0xc49 in csr plate: movl	0x0(%eax),%ecx
Modules:
Module	Address			Debug info	Name (61 modules)
PE	10000000-1001f000	Export          csr plate
PE	61740000-61782000	Deferred        advapi32
PE	62fc0000-6304f000	Deferred        rpcrt4
PE	63480000-6348c000	Deferred        version
PE	63bc0000-63bd9000	Deferred        shcore
PE	64a40000-64a95000	Deferred        shlwapi
PE	68500000-6855b000	Deferred        combase
PE	68700000-6872f000	Deferred        uxtheme
PE	6a280000-6a32a000	Deferred        msvcrt
PE	6a400000-6a531000	Deferred        ole32
PE	6bc00000-6bc2a000	Deferred        sechost
PE	6bcc0000-6bd40000	Deferred        setupapi
PE	6c9c0000-6cc57000	Deferred        gdi32
PE	6ed00000-6ef24000	Deferred        user32
PE	70b40000-70c16000	Deferred        ucrtbase
PE	71200000-7121b000	Deferred        imm32
PE	7b000000-7b0e8000	Deferred        kernelbase
PE	7b600000-7b81b000	Deferred        kernel32
PE	7bc00000-7bc9c000	Deferred        ntdll
ELF	7d000000-7d005000	Deferred        <wine-loader>
ELF	7d711000-7d741000	Deferred        libexpat.so.1
ELF	7d741000-7d794000	Deferred        libfontconfig.so.1
ELF	7d794000-7d80b000	Deferred        libpcre.so.1
ELF	7d80b000-7d82e000	Deferred        libbrotlicommon.so.1
ELF	7d82e000-7d97b000	Deferred        libglib-2.0.so.0
ELF	7d97b000-7da59000	Deferred        libharfbuzz.so.0
ELF	7da59000-7da96000	Deferred        libpng16.so.16
ELF	7da96000-7daa8000	Deferred        libbz2.so.1.0
ELF	7daa8000-7db71000	Deferred        libfreetype.so.6
ELF	7dba6000-7e594000	Deferred        shell32<elf>
  \-PE	7dbd0000-7e594000	\               shell32
ELF	7e7a5000-7e8f4000	Deferred        libx11.so.6
ELF	7e918000-7e926000	Deferred        libbrotlidec.so.1
ELF	7e926000-7e940000	Deferred        libz.so.1
ELF	7e940000-7e956000	Deferred        user32.so
ELF	7e956000-7e982000	Deferred        libxcb.so.1
ELF	7e982000-7e9a0000	Deferred        libgcc_s.so.1
ELF	7e9ab000-7e9d5000	Deferred        gdi32.so
ELF	7e9d5000-7e9fe000	Dwarf           lin-vst-servertrack32<elf>
  \-PE	7e9e0000-7e9fe000	\               lin-vst-servertrack32
ELF	7e9fe000-7eb86000	Dwarf           libwine.so.1
ELF	f76be000-f76c6000	Deferred        libxfixes.so.3
ELF	f76c6000-f76d3000	Deferred        libxcursor.so.1
ELF	f76d3000-f76e7000	Deferred        libxi.so.6
ELF	f76e7000-f76f6000	Deferred        libxrandr.so.2
ELF	f76f6000-f7704000	Deferred        libxrender.so.1
ELF	f7704000-f770b000	Deferred        libxxf86vm.so.1
ELF	f7740000-f77ef000	Dwarf           winex11<elf>
  \-PE	f7760000-f77ef000	\               winex11
ELF	f7b55000-f7b5d000	Deferred        libxdmcp.so.6
ELF	f7b5d000-f7c2a000	Deferred        libm.so.6
ELF	f7c2a000-f7ce1000	Deferred        ntdll.so
ELF	f7ce1000-f7eda000	Deferred        libc.so.6
ELF	f7eda000-f7ee0000	Deferred        libdl.so.2
ELF	f7ee0000-f7f02000	Deferred        libpthread.so.0
ELF	f7f05000-f7f10000	Deferred        librt.so.1
ELF	f7f10000-f7f15000	Deferred        libxcomposite.so.1
ELF	f7f15000-f7f1a000	Deferred        libxinerama.so.1
ELF	f7f1a000-f7f30000	Deferred        libxext.so.6
ELF	f7f34000-f7f39000	Deferred        libxau.so.6
ELF	f7f39000-f7f6a000	Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
00000020 (D) Z:\usr\bin\lin-vst-servertrack32.exe
	00000024    0 <==
	00000100    0
	00000104    0
	00000108    0
	00000114    0
00000038 services.exe
	0000003c    0
	00000040    0
	0000004c    0
	00000068    0
	000000a4    0
	000000b8    0
	000000d0    0
	000000e4    0
00000044 winedevice.exe
	00000048    0
	00000054    0
	00000058    0
	0000005c    0
00000060 winedevice.exe
	00000064    0
	0000006c    0
	00000070    0
	00000074    0
	00000080    0
	00000084    0
	00000088    0
	000000b4    0
00000078 explorer.exe
	0000007c    0
	00000094    0
	00000098    0
000000ac plugplay.exe
	000000b0    0
	000000bc    0
	000000c0    0
	000000c4    0
000000c8 svchost.exe
	000000cc    0
	000000d4    0
	000000d8    0
000000dc rpcss.exe
	000000e0    0
	000000e8    0
	000000ec    0
	000000f0    0
	000000f4    0
	000000f8    0
System information:
    Wine build: wine-6.16
    Platform: i386 (WOW64)
    Version: Windows 10
    Host system: Linux
    Host version: 5.10.61-1-MANJARO

Few depricated methods on build

Hey! 😃
Long time no compile!

Check this out there are some warnings on deprecated methods (Manjaro KDE Stable, gcc v10.1.0, Qt v5.15.0), maybe worth a look, in case they drop those methods without legacy support or something...

make -j4

Scanning dependencies of target linvstmanager_autogen
[  3%] Automatic MOC for target linvstmanager
[  3%] Built target linvstmanager_autogen
[  6%] Automatic RCC for src/resources/resources.qrc
Scanning dependencies of target linvstmanager
[ 16%] Building CXX object CMakeFiles/linvstmanager.dir/src/confighandler.cpp.o
[ 16%] Building CXX object CMakeFiles/linvstmanager.dir/src/customprogressdialog.cpp.o
[ 16%] Building CXX object CMakeFiles/linvstmanager.dir/linvstmanager_autogen/mocs_compilation.cpp.o
[ 19%] Building CXX object CMakeFiles/linvstmanager.dir/src/customsortfilterproxymodel.cpp.o
[ 22%] Building CXX object CMakeFiles/linvstmanager.dir/src/dialogpreferences.cpp.o
[ 25%] Building CXX object CMakeFiles/linvstmanager.dir/src/dialogrename.cpp.o
[ 29%] Building CXX object CMakeFiles/linvstmanager.dir/src/dialogrenamebatch.cpp.o
[ 32%] Building CXX object CMakeFiles/linvstmanager.dir/src/dialogscan.cpp.o
[ 35%] Building CXX object CMakeFiles/linvstmanager.dir/src/horizontalline.cpp.o
[ 38%] Building CXX object CMakeFiles/linvstmanager.dir/src/legacyconfigparser.cpp.o
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp: In constructor ‘DialogRenameBatch::DialogRenameBatch(const QVector<VstBucket>&)’:
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:93:99: warning: ‘void QButtonGroup::buttonClicked(int)’ is deprecated: Use QButtonGroup::idClicked(int) instead [-Wdeprecated-declarations]
   93 |     connect(mButtonGroupMode, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::buttonClicked), this, &DialogRenameBatch::slotModeChanged);
      |                                                                                                   ^
In file included from /usr/include/qt/QtWidgets/QButtonGroup:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:15:
/usr/include/qt/QtWidgets/qbuttongroup.h:90:10: note: declared here
   90 |     void buttonClicked(int);
      |          ^~~~~~~~~~~~~
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:93:99: warning: ‘void QButtonGroup::buttonClicked(int)’ is deprecated: Use QButtonGroup::idClicked(int) instead [-Wdeprecated-declarations]
   93 |     connect(mButtonGroupMode, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::buttonClicked), this, &DialogRenameBatch::slotModeChanged);
      |                                                                                                   ^
In file included from /usr/include/qt/QtWidgets/QButtonGroup:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:15:
/usr/include/qt/QtWidgets/qbuttongroup.h:90:10: note: declared here
   90 |     void buttonClicked(int);
      |          ^~~~~~~~~~~~~
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:94:103: warning: ‘void QButtonGroup::buttonClicked(int)’ is deprecated: Use QButtonGroup::idClicked(int) instead [-Wdeprecated-declarations]
   94 |     connect(mButtonGroupLocation, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::buttonClicked), this, &DialogRenameBatch::slotLocationChanged);
      |                                                                                                       ^
In file included from /usr/include/qt/QtWidgets/QButtonGroup:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:15:
/usr/include/qt/QtWidgets/qbuttongroup.h:90:10: note: declared here
   90 |     void buttonClicked(int);
      |          ^~~~~~~~~~~~~
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:94:103: warning: ‘void QButtonGroup::buttonClicked(int)’ is deprecated: Use QButtonGroup::idClicked(int) instead [-Wdeprecated-declarations]
   94 |     connect(mButtonGroupLocation, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::buttonClicked), this, &DialogRenameBatch::slotLocationChanged);
      |                                                                                                       ^
In file included from /usr/include/qt/QtWidgets/QButtonGroup:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogrenamebatch.cpp:15:
/usr/include/qt/QtWidgets/qbuttongroup.h:90:10: note: declared here
   90 |     void buttonClicked(int);
      |          ^~~~~~~~~~~~~
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogscan.cpp: In member function ‘void DialogScan::getScanAmount(const QString&, int&, int&)’:
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogscan.cpp:495:22: warning: ‘void QProcess::start(const QString&, QIODevice::OpenMode)’ is deprecated: Use QProcess::start(const QString &program, const QStringList &arguments,OpenMode mode = ReadWrite) instead [-Wdeprecated-declarations]
  495 |     process.start(cmd);
      |                      ^
In file included from /usr/include/qt/QtCore/QProcess:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogscan.cpp:30:
/usr/include/qt/QtCore/qprocess.h:168:10: note: declared here
  168 |     void start(const QString &command, OpenMode mode = ReadWrite);
      |          ^~~~~
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogscan.cpp:501:22: warning: ‘void QProcess::start(const QString&, QIODevice::OpenMode)’ is deprecated: Use QProcess::start(const QString &program, const QStringList &arguments,OpenMode mode = ReadWrite) instead [-Wdeprecated-declarations]
  501 |     process.start(cmd);
      |                      ^
In file included from /usr/include/qt/QtCore/QProcess:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/dialogscan.cpp:30:
/usr/include/qt/QtCore/qprocess.h:168:10: note: declared here
  168 |     void start(const QString &command, OpenMode mode = ReadWrite);
      |          ^~~~~
[ 41%] Building CXX object CMakeFiles/linvstmanager.dir/src/lineeditbridge.cpp.o
[ 45%] Building CXX object CMakeFiles/linvstmanager.dir/src/linkhandler.cpp.o
[ 48%] Building CXX object CMakeFiles/linvstmanager.dir/src/logoutput.cpp.o
[ 51%] Building CXX object CMakeFiles/linvstmanager.dir/src/main.cpp.o
[ 54%] Building CXX object CMakeFiles/linvstmanager.dir/src/mainwindow.cpp.o
[ 58%] Building CXX object CMakeFiles/linvstmanager.dir/src/modelscan.cpp.o
[ 61%] Building CXX object CMakeFiles/linvstmanager.dir/src/modelvstbuckets.cpp.o
[ 64%] Building CXX object CMakeFiles/linvstmanager.dir/src/datahasher.cpp.o
[ 67%] Building CXX object CMakeFiles/linvstmanager.dir/src/preferences.cpp.o
[ 70%] Building CXX object CMakeFiles/linvstmanager.dir/src/runguard.cpp.o
[ 74%] Building CXX object CMakeFiles/linvstmanager.dir/src/scanhandler.cpp.o
[ 77%] Building CXX object CMakeFiles/linvstmanager.dir/src/scanworker.cpp.o
[ 80%] Building CXX object CMakeFiles/linvstmanager.dir/src/scanresult.cpp.o
[ 83%] Building CXX object CMakeFiles/linvstmanager.dir/src/sidebar.cpp.o
[ 87%] Building CXX object CMakeFiles/linvstmanager.dir/src/statisticline.cpp.o
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/scanworker.cpp: In member function ‘bool ScanWorker::checkDllBasic(const QString&, bool, const QString&)’:
/run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/scanworker.cpp:95:41: warning: ‘static int QProcess::execute(const QString&)’ is deprecated: Use QProcess::execute(const QString &program, const QStringList &arguments) instead [-Wdeprecated-declarations]
   95 |     int exitCode = QProcess::execute(cmd);
      |                                         ^
In file included from /usr/include/qt/QtCore/QProcess:1,
                 from /run/media/x133/STORAGE 2/Programs/Linux/_Music/LinVstManager/Source/linvstmanager-master/src/scanworker.cpp:11:
/usr/include/qt/QtCore/qprocess.h:263:16: note: declared here
  263 |     static int execute(const QString &command);
      |                ^~~~~~~
[ 90%] Building CXX object CMakeFiles/linvstmanager.dir/src/verticalline.cpp.o
[ 93%] Building CXX object CMakeFiles/linvstmanager.dir/src/vstbucket.cpp.o
[ 96%] Building CXX object CMakeFiles/linvstmanager.dir/linvstmanager_autogen/F4FAE6NH3Q/qrc_resources.cpp.o
[100%] Linking CXX executable linvstmanager
[100%] Built target linvstmanager

[Suggestion] List sort order

Since now default sort mode is by Name, and it works like that:

+
.
#
A
B
C
a
b
c

I think perhaps more natural and logical for human readability sorting by name would be:

+
.
#
A
a
B
b
C
c

So is it possible to make airwave another supported vst bridge? I understand that airwave includes a gui manager app too. however it would be nice to include it here since some vst plugin dont work well with linvst and bitwig daw specifically i found this occur yesterday witth bc free amp. Therefore some of my plugin may not be possible with linvst due to that interop issue with that particular daw. Thanks for considering this matter.

Cannot Disable in Linvstmanager

Using LinVst 3.15 and LinVSTX 3.15 and Linvstmanager 1.1.1. Currently, I can enable plugins using the E key or by right-clicking. However, I cannot disable plugins using the D key or by right clicking. Using Manjaro w Kernel 5.9.10. If I manually delete the .so file and run Linvstmanager, it does show correctly as disabled. However, if I enable it again, I cannot disable within linvstmanager.

This started happening for me the last few versions but I can't recall exactly when this started. When linvstmanager was first released, this was not an issue and disable worked fine. LinVST .so files and VST plugins are all in my home folder so there should not be any issues with permissions.

Any chance you could make this work with slightly older QT / Ubuntu LTS?

Hi,

When I try to compile, it throws a bunch of errors that look like this:

[ 44%] Building CXX object CMakeFiles/linvstmanager.dir/src/main.cpp.o
/home/kieran/Downloads/linvstmanager-1.0.1/src/linkhandler.cpp: In member function ‘RvLinkHandler LinkHandler::refreshStatus(bool, int, bool, bool)’:
/home/kieran/Downloads/linvstmanager-1.0.1/src/linkhandler.cpp:58:56: error: ‘class QString’ has no member named ‘chopped’; did you mean ‘chop’?
                         filePathSo = vstBucket.vstPath.chopped(3) + "so"; // Replace "dll"
                                                        ^~~~~~~
                                                        chop

Some Googling suggests that this is due to a dependency on QT5.10:

https://phabricator.kde.org/T8526

I'm running Ubuntu 18.04, which is the current latest LTS version, but that only has this when running the apt command suggested in the docs for linvstmanager:

qt5-default is already the newest version (5.9.5+dfsg-0ubuntu2.5).

Could you please either update the instructions, or tweak linvstmanager so it's not dependent on the newer version?

UI text truncationless, possible areas for improvements

We've discussed it during testing period a little, since then i've moved from Manjaro Deepin to Manjaro KDE, although i use same font of Noto Sans 10pt systemwide, my monitor have somewhat odd 101x101 dpi with 2560x1600 resolution, so fonts render little bigger by OS, than usual setups...

Problematic areas currently:

Status column, maybe it's better to use some auto value so it would set width by value of widest element in column (if qt have it, i'm thinking web-like tables).
Filters right panel, obviously using fixed width panel here will lead to stuff like that, on some monitors and / or bigger font-sizes

P.S. Btw, just in case, linvstmanager uses proper System settings fonts, not stuff like fontconfig defaults, right?

fc-match Sans
fc-match Seriff
fc-match Mono

Aur seems gone

It seems that the aur for arch is gone...

Beta testing

(takeover from Goli4thus/linvstmanage#1)

First of all, thanks for your feedback! Definitely helps in getting this application to a more stable point!

@Goli4thus
First impressions just testing scan since i wonder how it will go:

1. There are some strange things about build install, i'll describe a bit later...

2. Scan of my VST folder of 2156 .dll files took just ~16 seconds that's pretty good! smiley

3. There were quite a few excessive non-vst dlls on scan, but seems that mirrors pretty much what DAW scanners usually detect

The fact that it only took 16 seconds for 2156 .dll files makes me think that you probably didn't have the "Verify dll-files for being actual VST files" option ticked.
This requires setting up the VstDllCheck.exe tool in preferences, which is shipped with LinVstManager.
It would also be the explanation why the scan showed you so many "non-vst dlls" as a result (VST2 files that weren't verified are indicated by 'VST2 (?)' in the scan result table).

4. There's huge problem i have encountered, i've added all those scanned ones, and tried to **Enable** all those who are disabled this caused at the very least something like memory leak, but then DE even asked if i want to close the process because it's not responding (looking in my .so folder it stuck hard on 23 items). I thought that could be because i haven't yet saved config, so i have killed process, cleaned .so folder and started over, saved config, rebooted **linvstmanager** - tried again it goes same. Also i have noticed that to create 1 symlink it take ~4 seconds or even more (x 2000, you can imagine what a bummer that is), it's insanely much slow **Enable** action, compared to **linvstmanage** almost immediately creates all of my vst links..

I've spent lots of hours on this one today and came up with LOTS of performance improvements (28f47ce).
I also checked with 2000 "dummy vst dlls" (empty dll-files) and was able to reproduce your findings with the slowness compared to linvstmanage-cli. Honestly don't know why I haven"t tested such big numbers myself beforehand. Anyway, please have another try. It should be noticably faster now.

5. I have noticed that you write .so directly as **VstName.so**, which is i can tell from personal experience will be huge problem, because there are a lot of different devs who have exactly same vst names, therefore we must use at the very least something like **DevName_VstName.so,** like:

Abbeyroadplugins_EMI_TG_12413_Limiter

I actually thought a bit about that and somewhat hoped that every Dev would try to give his VST a unique name to "stand out". But that probably was wishful thinking on my part and I get your point: It's not really robust like it is now and could easily cause clashing in the link folder.

Therefore I've introduced a suffix that is appended to soft-links in link folder (d2a43e6). This is based on a hash value that is calculated based on a VST's absolute path.
So unless two identically named VST.dll (or vst3) files are located within the same folder (which is simply not possible), that link name with the added suffix will always be unique.

1. Import previous although works perfectly as intended, won't help me personally too much, because 4 and 5 also happens there, and prior i have followed convention of:
~/.vst/Abbeyroadplugins_EMI_TG_12413_Limiter/
    TG12413_1969.so
    TG12413_2005.so

~/.vst/Aegean_music_Spirit_reverb/
    Spirit Reverb x64.so
So unless it's followed my structure exactly (which is not possible since it's manual dev naming, sometimes it's not exactly same as what's embedded in vst as dev) then there's not too much sense, because i have customly configured Renoise VST cache (with categories and all that). So for myself any deviation from that structure would anyway require manual intervention with Renosie. It's my personal problem, just wanted to mention smile

Well, I get your point, but yeah, there's no real way to consider such a custom naming scheme.

Please notify @osxmidi that it's not ready for production / LinVst integration yet, 4 and 5 are really serious ones.

I don't think he assumes that LinVstManager is already "rock solid" or "ready for shipping" because that would be quite uncommon for newly developed software.
I also intentionally have not made a release on github and haven't written about it on reaper forum due to that.

Also feel free to guide me through any useful debug info about 4 and 5 which i can provide, since it's pretty hard to emulate my amount of VST plugins, which could certainly be factor..

As mentioned above, empty dll dummy files worked surprisingly well for reproducing your findings.
Having your number of actually VSTs still will be helpful I think to catch those more extreme edge cases which the average user might never trigger on his own.

Will back with more testing soon and update on 1

1. On **build** (no expert at all, just wonder):
   
   * Tested on Manjaro Deepin lacks panel icon, launcher icon...Pretty much all variants of icons, except blurry one on alt-tab and small in system manager, seems that by default you install only **/usr/local/share/icons/hicolor/48x48/apps/linvstmanager.png**, but as far as i know Linux can use svg icons directly? Well, even if png, you can fill all those sizes or most important ones, i guess: 16x16 20x20 22x22 24x24 32x32 36x36 40x40 48x48 64x64 72x72 96x96 128x128 192x192 256x256 384x384 512x512. And why not default **/usr/share/icons**?
   * **/usr/local/share/applications/linvstmanager.desktop** just wonder, why not **/usr/share/applications**, shouldn't it be default for any Linux distro?

As far as I know, "manually installed" applications (meaning without the distro's package manager, but some like make/make install) usually should go into those "local" variant system folders (/usr/local/* instead of /usr/*), to keep out of the way of where a distro's package manager installs to.

Regarding the icons:
I hoped it was fine, because for me on Manajro with XFCE I get icons where I would expect them without be pixelated.
But there's no problem in making other resolutions of those icons. They are part of it now (078df09).

2. I've cleaned everything and tested again without touching or interacting with computer at all, just to see tested **Enable** with Import of my config, which are 1905 real tested vsts. It took 2 hours and 15 minutes...


* Technically it have completed

* It seems to me that now process of creating symlinks goes in a same process with GUI which leads to that leaks and caused full LinVstManager freeze, if so probably it's a good idea to create all routines like update / enable / disable etc inside new process to decouple it from GUI

* It have created 106 additional .so symlinks inside my wineprefix, that wasn't there before in root of my VST folder here (no idea on what criteria or why):

I'd say please test again with the added performance improvements. Lot's of things didn't seem right with the previous version when it came to having lots of VSTs in the table.
In general I agree that heavy processing should not be done in the main GUI event loop.
That's for instance the reason why the scan operation is being done in it's own thread.

Right now (as mentioned above) the performance has significantly improved (at least for me; curious on your case).
So it might be considered "ok-ish" now and if one doesn't always perform each operation with thousands of VST at the same time, it might not really be noticeable the way it's implemented at the moment.
But I'll note it down as a possible improvement.

~/.PlayOnLinux/wineprefix/VST/drive_c/VST
I can give you names of those symlinks if you want...I see no system there
* I have compared lists of .so symlinks created with **linvstmanage** (definitely correct one, since it matches vst exactly) and same imported list with **linvstmanager**, there are some mismatches and bug with **.** character parsing:
linvstmanage linvstmanager
Acid Rack 2.0.so Acid Rack 2.so
AMB ElectraBass v1.2.so AMB ElectraBass v1.so
Eiosis AirEQ 5.1.so Eiosis AirEQ 5.so
NUGEN VisLM2_5.1 64bit.so NUGEN VisLM2_5.so
NUGEN VisLM2_7.1 64bit.so NUGEN VisLM2_7.so
Oresus_v1.2.so Oresus_v1.so
PPG Wave 3.V.so PPG Wave 3.so
Shred 1.06.so Shred 1.so
SIDizer_v1.4.so SIDizer_v1.so
SoloRackFX Multi InOut.x64.so SoloRackFX Multi InOut.so
SoloRackFX.x64.so SoloRackFX.so
SoloRack Multi InOut.x64.so SoloRack Multi InOut.so
SoloRack.x64.so SoloRack.so
Spire-1.1.so Spire-1.so

Some have collapsed to one because of that:
linvstmanage linvstmanager
arcDev.Blittr.so
arcDev.Cyclotron.X2.so
arcDev.Dubb.Box.RC1.so
arcDev.ET-200.so
arcDev.ET-301.so
arcDev.Resomatic.so arcDev.so
Mr. Alias Pro x64.so
Mr. Tater head.so Mr.so
MR.MUTILATOR.so
MR.WAVESHAPER.so MR.so

Actually, there is a system. ;)
The Qt API I've used gave me the filename up until the first period character, which then I added the ".so" extension to.
Simply didn't think of filenames having periods within their name.
Anyway, I've corrected and tested this as well (2d72f41).

[Improvement] Ease of install suggesstion

Install.sh

#!/bin/sh

mkdir build && cd build
cmake ..
make -j4
sudo make install

Because...Why not? 😃
This way it's 1 click / 1 command and no need to update README section in case anything will change 😄

Win-Win i think!

Manjaro required packages little overkill

As far as i see gcc-multilib is overkill (or maybe i missed something)

sudo pacman -S cmake make gcc git wine qt5-base gcc-multilib

If you run pacman -Qi gcc, it says that it both provides and replaces gcc-multilib, so just gcc should be enough?

Fix PayPal link on README.md

It redirects to (resulting in a 404):

https://github.com/Goli4thus/linvstmanager/blob/master/paypal.me/donate2goli4thus

Instead of:

https://paypal.me/donate2goli4thus

Your project is too cool to miss any donation :D

Cheers.

[Feature request] Remember main window size on program reopen

Not a big deal, still would be good usability improvement 😃

For example myself as big monitor owner always resize for some specific size (which is not as big as maximized, but still big enough to fit all cols in one view)

[optimisation] Verification speed

With current implementation full scan + verification of my VST folder with 2158 .dll files took:
8 minutes 36 seconds

I'm not by any means saying it's bad result, especially compared to wine checks - but i feel there might be room for optimization, perhaps some parallel processing!

Problem with non-existing pathLinkFolder

I've been making new installation and found this little problem (maybe confusing for new user, got even myself stuck for a moment).

I've install linvstmanager
Copied my linvstmanager_config.xml, which has

<pathLinkFolder>/home/x133/.vst</pathLinkFolder>

Selected Mismatch in right filter panel
Updated them all (successfull)
Selected Disabled in right filter panel
Tired to Enable them all and got completely stuck (nothing happens, nothing moves, no errors / warnings)

Obviously that was problem of not actually having ~/.vst in a first place, creating it and trying again have fixed "problem" 😆

There are two ways to be nicer here:

Auto-create folder written at config's pathLinkFolder
Give warning / error in that case, so user wouldn't scratch head too much 😄

Symlinks naming

Solutions

So the only idea I have now is:

no more path based suffix of any kind

still allow to add identically names VST.dll files to LinVstManager (differentiation is based on each VST's absolute path re it being unique)

Agree with both points

possibly highlight duplicate VST names (in name column) and allow user to rename only the internal name of tracked VSTs.

definitely, not possibly!
I think maybe give them some separate status even and / or at the very least keep duplicated names on top of list, so user would immedeately know that this is something to be sorted...

Reason:
This "name" that is shown in LinVstManager is derived from the base VST.dll filename.
But after that it is only ever used to:

be displayed in the table

be the name of the *.so link created in the link folder.

So if we allow the user to rename VSTs within LinVstManager (not the actual source VST.dll), then a user could give a unique name himself and that new name would end up being the so-link in the link folder and therefore the name that a DAW picks up (if that DAW likes picking up the filename instead of the embedded name within the dll).

In summary:

Inside wineprefix itself we must always keep NAME.dll = NAME.so
In link folder we can rename .so symlinks however we want and it will still work

Is this correct?
If it is - that i agree!

What do you think?
Would this be sufficient solution?

If i understood you correctly - i think this is brilliant solution! 👍

Theory

How do you currently get Renoise to load two VSTs with the same name of the dll file? Do you rename one of them intentionally?

I answered it directly in the middle of post #1 (comment) maybe missed the point of question, and you mean .so?
But it's same, basic idea - divide (by folder structure) and conquer! At least that what i had done with linvstmanage 😃

Make error

Hi!

First of all thank you for this project. It's nice to have a lighter way to manage linvst.

I*m having an error while trying to make the most recent version. And this is the cmake log I'm getting:

-- Configuring done
-- Generating done
-- Build files have been written to: /home/skmecs/builds/linvstmanager/build
╭─skmecs at g in ~/builds/linvstmanager/build on master✔ 20-08-30 - 13:17:55
╰─⠠⠵ make -j 4
[  6%] Automatic MOC for target linvstmanager
[  6%] Built target linvstmanager_autogen
[  6%] Building CXX object CMakeFiles/linvstmanager.dir/src/dialogrenamebatch.cpp.o
/home/skmecs/builds/linvstmanager/src/dialogrenamebatch.cpp: In constructor ‘DialogRenameBatch::DialogRenameBatch(const QVector<VstBucket>&)’:
/home/skmecs/builds/linvstmanager/src/dialogrenamebatch.cpp:93:86: error: ‘idClicked’ is not a member of ‘QButtonGroup’
   93 | Mode, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::idClicked), this, &DialogRenameBatch::slotModeChanged);
      |                                                              ^~~~~~~~~

/home/skmecs/builds/linvstmanager/src/dialogrenamebatch.cpp:94:90: error: ‘idClicked’ is not a member of ‘QButtonGroup’
   94 | tion, static_cast<void(QButtonGroup::*)(int)>(&QButtonGroup::idClicked), this, &DialogRenameBatch::slotLocationChanged);
      |                                                              ^~~~~~~~~

make[2]: *** [CMakeFiles/linvstmanager.dir/build.make:148: CMakeFiles/linvstmanager.dir/src/dialogrenamebatch.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:77: CMakeFiles/linvstmanager.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I'm on an Ubuntu Studio 20.04.

linvstmanager is back on aur

Hi! Just wanted to let you know that linvstmanager (and all the linvst bridges) are back on the AUR so that arch people may install it from there:

https://aur.archlinux.org/packages/linvstmanager-git/

Note, the package is now called linvstmanager-git :)

to install:
sudo pacman -S linvstmanager-git

ubuntu 19.10 - problem installing package dependancies

Hi there, was just trying to build this yesterday.

You seem to have put together specific instruction for ubuntu 19.10 however on my system the last command:

sudo apt-get install libwine-development-dev:i386

Fails to work. To try to get around that I ran the following command to install one of the missing deps of libwine-development-dev:i386 thereby letting me finally install it:

sudo apt-get install -y linux-libc-dev:i386

However by installing linux-libc-dev:i386 that then also breaks libc6-dev and thereby in turn build-essential and other dependancies which CMake also requires.

I cannot see how to get a working system back again, except for uninstalling the libwine-development-dev:i386 and also the linux-libc-dev:i386 as instructed by aptitude here

sudo aptitude -f install linux-libc-dev
The following NEW packages will be installed:
  linux-libc-dev{b} 
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,233 kB of archives. After unpacking 5,729 kB will be used.
The following packages have unmet dependencies:
 linux-libc-dev : Breaks: linux-libc-dev:i386 (!= 5.3.0-7629.31~1581434050~19.10~fea3067~dev) but 5.3.0-29.31 is installed
 linux-libc-dev:i386 : Breaks: linux-libc-dev (!= 5.3.0-29.31) but 5.3.0-7629.31~1581434050~19.10~fea3067~dev is to be installed
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     linux-libc-dev [Not Installed]                     

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Remove the following packages:                                        
1)     libc6-dev:i386 [2.30-0ubuntu2 (eoan, now)]                          
2)     libwine-development-dev:i386 [4.17-1 (eoan, now)]                   
3)     linux-libc-dev:i386 [5.3.0-29.31 (eoan-security, eoan-updates, now)]

     Install the following packages:                                       
4)     libc6-dev [2.30-0ubuntu2 (eoan)]                                    
5)     libwine-development-dev [4.17-1 (eoan)]                             

Accept this solution? [Y/n/q/?]

However without libwine-development-dev:i386 it would seem that your project cannot compile in it's final linking stages. So either way.... cannot build your project on ubuntu 19.10 here.

What can be done about it?

Scan window type tooltip needs update

Tooltips for VST type are misleading now, seems you forgot to update it with our latest changes 😃

VST2 and VST3 folders separated?

First of all thanks for your efforts with linvstmanager, I think it is a very useful tool.

My setup (in short):
I'm using bitwig and reaper nativly under arch linux (with everything updated to latest rolling releases).

Latest version of wine (5.4).
Aside: I have built the linvst3 from source (with the flags to enable window size)
-DEMBEDRESIZE

I have a question.
On the linux side I have my vst organized in two folders.
~/.vst (for the vst2)
~/.vst3 (for the vst3)

Not sure if that is the optimal setup, but I think its kind of a standard if you are building your own vsts (which I'm playing around with), I went with a default config.

My vst2 bridges goes under the ~/.vst/windows-bridged, and my vst2 bridges goes under the ~/.vst3/windows-bridged.

However: Using linvstmanager, there seems to be a single folder for storing all the bridges. Is there a way to separate the bridges (it seems to generate some naming conflicts when having both vst2s and vst3s of the same plugin).

Also, as I'm playing around with a custom bridge (built from source). Is there a way to experimentally apply the custom bridge to a single vst?

I ended up messing things up, so all my vst3s were marked "Mismatch".

As I'm pretty new to the whole vst bridging stuff, its not entirely clear if the you can have a custom .so bridge with the stock lin-vst3-servertrack, or if is possible to have multiple instances of lin-vst3-servertrack installed simultaneously. Maybe that is a question best answered by osxmidi.

Thanks in advance for any info.

Low rez icon in some scenarios

Sorry. best i can to catch this on screenshot, point is unlike other icons for some reason linvstmanager is pixelated here in KDE...
This is "Large icon" task switcher...

I have no idea why it happens, since we already made all possible sizes...

P.S. I rebooted after install (aka update icon cache)

VstDllCheck.exe

I followed your steps on clean Manjaro KDE on Virtualbox VM, here's what i found:

wine or wine-staging on system level - doesn't matter, same results
Previously i had VstDllCheck.exe placed at /usr/bin - this is cause, if it's in system folder it can not properly create ~/.wine for unknown reason.
If you place VstDllCheck.exe somewhere in $HOME - it can properly create full ~/.wine

That is not all!

Scan with VstDllCheck.exe actually works ONLY if you place it in system folder like /usr/bin, if it's not in there and placed at $HOME all actual VST .dlls will be filtered as mismatches which will give you empty list!

So....If there is no valid ~/.wine prior to use linvstmanager - only way to properly create it is to have VstDllCheck.exe placed somewhere inside $HOME and to actually use it it must be placed at system level like /usr/bin! Great! 🤣

Situation where orphaned links may lead to some workflow questions

Pretty funky and complex situation, i must admit, yet still may happen and raise some questions... 😃

Remove plugin from previous location (by Wine or manually)
Install / copy same plugin to other location
Open linvstmanager, on orphans detected notification - choose to not remove them
Remove orphaned plugin by selecting it and using Remove VST function
Add plugin (installed to that new location) with any method available to linvstmanager
It will correctly get No_So status - use Update function
It will correctly get Disabled status - try to use Enable function

You can't enable those anyhow, until physically removing those broken orphaned link from link folder...

I suggest little improvement for Enable function in case it's used on same name as broken orphaned link:

Force remove such broken link
Create new one as usual