Use a different plugin ID from the forked source `jpcima/ysfx`

tkna91 commented 2 months ago

Is your feature request related to a problem? Please describe.

It seems that JoepVanlier/ysfx uses the same plugin ID as the following forked source, so that only one of the VST3 plugins can be used when using REAPER or Renoise. https://github.com/jpcima/ysfx

https://github.com/user-attachments/assets/c1bb7332-e2ec-4b46-b8a6-cc452d9c9b24

Describe the solution you'd like

I wish I could solve this problem by separating the plugin IDs. I apologize for the inconvenience, but please review and investigate.

Additional context

Environment:

OS: Arch Linux x86_64
WM: sway
ysfx-saike-mod-git 0.0.22.r0.gf160367-1
ysfx-git 1:0.0.0.r244.8077347-4
reaper 7.22-1
renoise 3.4.4-1
linux 6.10.8.arch1-1
pipewire 1:1.2.3-1
mesa 1:24.2.1-1

JoepVanlier commented 2 months ago

Thanks for bringing this to my attention! I thought I had already changed this by updating the product name in the cmake file, but it seems I likely need to add a plugin name as well.

I will look into this tonight. I'll report back when I know more.

JoepVanlier commented 2 months ago

Does this fix it? Linux 64-bit VST3.zip

tkna91 commented 2 months ago

REAPER solved the problem. Renoise does not seem to work. (I did reload the plugin) I am not sure, does it not accept VST3i?

https://github.com/user-attachments/assets/ec8dcd04-ce55-40af-9799-6d300380eafa

tkna91 commented 2 months ago

I don't know if this is the cause, but it seems to work in the previous VST3 state.

https://github.com/user-attachments/assets/982917a6-d846-4ff6-a020-2d3510e88a25

JoepVanlier commented 2 months ago

Maybe to go back a few steps, why do you need to install them side by side? I don't think I changed the file format, so things should be forward compatible.

This is a bit of a conundrum. Changing the plugin name now, would break the projects of people that have already made projects with the current one. That said, I agree that I should probably use a new name to make sure I don't clash with other forks and/or the original and it's better to probably rip off the band-aid early.

I think the best course of action is to rename the plugin once now to ensure that people who have existing projects, do not lose their older projects; but that people that have none can just delete the old version and move on with the new one. What do you think?

Could you please try the following build with the name ysfx-s: Linux 64-bit VST3.zip

See if that one shows up correctly.

tkna91 commented 2 months ago

Indeed, in my case, I only reported it because I had a question about the fact that I could only use one of them, even though they have different names, but for practical purposes, I have no problem with it so far. If it were possible to handle it interchangeably with the previous ysfx plugin, I think I might rather have the same plugin ID. But since the names are different, would that not be the case?

I tried ysfx-s and REAPER looks fine. I checked a little more in Renoise and it seems that you have to add it to both Plugin and TrackDSP to use it as a VST3 instrument.

https://github.com/user-attachments/assets/0958bb67-af3b-45a8-835e-335ce39b7579

The master in the repository seems to be fine and can be used as a VST3 instrument by simply adding it to Plugin.

https://github.com/user-attachments/assets/5605d88d-4700-40e2-b493-a95ea8d4408d

JoepVanlier commented 2 months ago

I have found out a bunch more stuff. It seems renoise keeps a cache, even if you enter rescan VSTs. So to do a clean test, you should ideally, really hard clear the cache for every test. That means closing renoise, and deleting some files (or moving them). The problem with not doing that is that things may show up that are actually in a weird state. For instance, you may see a cached effect version in the instrument, that will load, but then show an error message. Something like this:

Anyways, on linux those files should be located in ~/.renoise/V3.x.x/. The files to delete/move are called CachedVST3s_x64.db and CachedFailedVST3s_x64.db. Relaunching renoise after this will trigger a rescan.

It's possible that you were already doing this, but for me this was confounding my testing locally, so it's good to make sure.

It also seems that in the plugin window, renoise only allows VSTis, while in the sampler effect window it only allows non-VSTis. Renoise is not alone in this. I've since learned many other DAWs do this. This means I will have to build two unique variants of the plugin (which I will happily do).

Here is another zip to test: Linux 64-bit VST3.zip

You will need to add both VST3s. One will be called ysfx-s and the other ysfx-s FX.

Remember to hard-clear your cache first. Also, thank you so much for your help with this.

tkna91 commented 2 months ago

I did this.

uninstall ysfx-saike-mod
add the following
- $HOME/.vst3/ysfx-s.vst3
- $HOME/.vst3/ysfx-s FX.vst3
Exit Renoise
delete the following
- CachedVST3s_x64.db
- CachedFailedVST3s_x64.db
Start Renoise
Renoise->Preferences->Plug/Misc->Rescan

A quick check appears to show no problems!

https://github.com/user-attachments/assets/077c55d7-57f6-4f76-a4a9-89af58accdde

tkna91 commented 2 months ago

Coexistence with ysfx, the previous forked source, appears to be fine. Since ysfx is not vst3i, it was probably not originally available in Plugins.

https://github.com/user-attachments/assets/5c342f60-6824-4721-bc9b-8aeb718d99d5

After merging to master, you can close it as you wish. This is useful. Thank you!

JoepVanlier commented 2 months ago

Resolved in https://github.com/JoepVanlier/ysfx/pull/47