goli4thus / linvstmanager Goto Github PK
View Code? Open in Web Editor NEWGraphical companion application for various bridges like LinVst, etc.
License: Other
Graphical companion application for various bridges like LinVst, etc.
License: Other
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...
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
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
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.
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.
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?
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
It seems that the aur for arch is gone...
(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.soSome 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).
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!
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?
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.
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)
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!
I've been making new installation and found this little problem (maybe confusing for new user, got even myself stuck for a moment).
linvstmanager_config.xml
, which has<pathLinkFolder>/home/x133/.vst</pathLinkFolder>
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:
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:
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! 👍
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 😃
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.
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
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?
Hi
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.
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!
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! 🤣
Pretty funky and complex situation, i must admit, yet still may happen and raise some questions... 😃
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.