docs: create new schelp with the content of old html broken help files

[fmiramar]

Most part of the help files from the MCLDFFTUGens are HTML files located at a MCLDUGens/Help folder, which turns out to be missing documentation files by the IDE. I have created this schelp file with the contents of the HTML and put them on the correct help folder MCLDUGens/HelpSource.

[mossheim]

thanks, can you delete the html file too?

[fmiramar]

thanks, can you delete the html file too?

Sure, I am going to check for others MCLDFFTUGens that have broken help files and commit the changes all at once.

[dyfer]

Hello @fmiramar What's the status of this PR?

[fmiramar]

Hi @dyfer

after these considerations from Josh Parmenter should I continue to pull requests to this repo ?

[dyfer]

Hi @fmiramar

My understanding is that the developers agree that sc3-plugins is not an ideal way to maintain 3rd-party plugins, but we currently don't have a full-fledged replacement ready.

IMO we should still maintain the plugins that are here if possible, providing bugfixes and updating documentation etc. We probably won't be accepting new plugins though (unless other devs think otherwise).

Eventually, once we have a system in place (a package manager that can distribute binary plugins for multiple platforms), my understanding is that we would split up sc3-plugins into smaller packages and transfer maintenance duties as appropriate. All that is to say, that any updates we make in the meantime would migrate to these new repositories. When that would happen is unknown at this point.

[dyfer]

In other words, the updates to documentation, especially converting the HTML files, are definitely welcome :)

[fmiramar]

Sure! I will try to finish it ASAP

BTW I am organizing a list of documentation improvements/changes that IMO are interesting (main repo and plugins). What is the process for collaborating in this case? Should I first open an issue or should I pull requests straightforwardly ?

[dyfer]

Should I first open an issue or should I pull requests straightforwardly ?

I think that depends on the scope of changes... If it's something like reorganizing multiple files, then opening an issue might be better first, so that you can get feedback from others before making actual changes