Added a script in Various

[tormyvancool]

Added the script tormyvanvool_VSTs-VSTis Extractor.lua in Various

[cfillion]

• The Various category seems unsuited for this script. Why not FX?
• The @description tag is for the display name of the package. It should closely match how it appears in the action list (minus author prefix & file extension) like VSTs-VSTis Extractor. A longer description/help text can be specified using the appropriate @about tag.
• Letters in the version name, such as "3.1 FERRETS", makes the version a pre-release. If this is not intended, the version should be just 3.1.
• The syntax of the @screenshot tag is one link per line optionally prefixed with a description.
• The @changelog tag must contain the release notes of the current version only.
• You're using the image/png MIME type, but the base64 blob actually contains JPEG data?
• Surely bundling 88KB of JS for the jQuery dependency is not required for the few things this script does, just vanilla JS should do the trick just as well (and likely faster)...
• If you really want jQuery, at least please upload it in clear as a separate file rather than base64-encoded...
• Some .ini files are omitted, such as reaper-auplugins.ini, reaper-auplugins-bc.ini, any of the Linux filenames, LV2, DX...
• <inst> means "instrument" (eg. AUi), not "installed".
• PRs should be based on a fresh feature branch, not from master.
• Consider using the package editor (https://reapack.com/upload) instead of hand-crafting PRs.

[tormyvancool]

• The Various category seems unsuited for this script. Why not FX?
  It's not an FX. It's a documentation process.

• The @description tag is for the display name of the package. It should closely match how it appears in the action list (minus
  author prefix & file extension) like VSTs-VSTis Extractor. A longer description/help text can be specified using the appropriate @about tag.
  I will fix it.

• Letters in the version name, such as "3.1 FERRETS", makes the version a pre-release. If this is not intended, the version should be just 3.1.
  I will fix it.

• The syntax of the @screenshot tag is one link per line optionally prefixed with a description.
  There are 2 videos up there. SHould I put 2 @screenshot lines?

• The @changelog tag must contain the release notes of the current version only.
  It wasn't clear this at all. I will fix it.

• You're using the image/png MIME type, but the base64 blob actually contains JPEG data?
  I will fix it, although it's working I never realized it

• Surely bundling 88KB of JS for the jQuery dependency is not required for the few things this script does, just vanilla JS should do the trick just as well (and likely faster)...
  Speed is not an issue for this purpose. I wills ay with jQuery

• If you really want jQuery, at least please upload it in clear as a separate file rather than base64-encoded...
  If it works like the [data] and became crazy with it etc, I prefer to keep it into the script as it is worked for some year now.

• Some .ini files are omitted, such as reaper-auplugins.ini, reaper-auplugins-bc.ini, any of the Linux filenames, LV2, DX...
  Strange because it was tested against AU by users and detected the MAC/Linux plugins. However I can't test these file types.

• <inst> means "instrument" (eg. AUi), not "installed".
  I will fix it since everywhere Instrument is abbreviated INSTR

• PRs should be based on a fresh feature branch, not from master.
  I will check it

• Consider using the package editor (https://reapack.com/upload) instead of hand-crafting PRs.
  I will see it after the corrections

[cfillion]

It's not an FX. It's a documentation process.

This is a script repository, so nothing in the FX category is an effect. The category is for FX-related scripts such as this one. 😉 (Effects are in the separate JSFX repository.)

There are 2 videos up there. SHould I put 2 @screenshot lines?

Like this:

-- @screenshot
--   English https://www.youtube.com/watch?v=J5Ko4uIya9w
--   Italian https://www.youtube.com/watch?v=OqNFQt3hOC8

It wasn't clear this at all. I will fix it.

The documentation explicitly says this: "Sets the changelog for the current version. The changelogs of previous versions are preserved."

If it works like the [data] and became crazy with it etc, I prefer to keep it into the script as it is worked for some year now.

It's easy to add additional files when using the package editor. Base64 makes it hard to review the code.

(And I maintain that a 88KB dependency is excessive for just 40 lines.)

[tormyvancool]

It's not an FX. It's a documentation process.

This is a script repository, so nothing in the FX category is an effect. The category is for FX-related scripts such as this one. 😉 (Effects are in the separate JSFX repository.)

There are 2 videos up there. SHould I put 2 @screenshot lines?

Like this:

-- @screenshot
--   English https://www.youtube.com/watch?v=J5Ko4uIya9w
--   Italian https://www.youtube.com/watch?v=OqNFQt3hOC8

It wasn't clear this at all. I will fix it.

The documentation explicitly says this: "Sets the changelog for the current version. The changelogs of previous versions are preserved."

If it works like the [data] and became crazy with it etc, I prefer to keep it into the script as it is worked for some year now.

It's easy to add additional files when using the package editor. Base64 makes it hard to review the code.

(And I maintain that a 88KB dependency is excessive for just 40 lines.)

Working on this.

For the CHangelog:
yes it is kept by a system that had already it.
But ReaPack doesn't have it. Hence there is the whole history

About jQuery:
I will not change it.
I will keep it as it is because in this way the page is fully portable.
Even on PCs not having internet (often happens in Studios) the page si working as it must work. It's not an option.
Just by copy the page into a pen-drive and bring it on another PC you can always open it and use the content.
Broken pages etc it's not what I want for my script.

This is a Project Requirement so I keep it like that. No one dies at the end. It's a tool made not only to help migration but for DR (Disaster Recovery).

[cfillion]

But ReaPack doesn't have it. Hence there is the whole history

The changelog of every released version is stored forever in the XML index.

Even on PCs not having internet (often happens in Studios) the page si working as it must work. It's not an option.

This has nothing to do with requiring internet access?

Removing jQuery means using just the standard JavaScript DOM API. Nowadays it's very portable – jQuery is mostly a vestige of ancient times (when Internet Explorer was causing headaches)...

(Just to be clear: my gripe here is that having a huge dependency base64-encoded is a pain to review. It being technically unnecessary on top is secondary. Feel free to release this script on your own repository instead of here to skip this step.)

[tormyvancool]

But ReaPack doesn't have it. Hence there is the whole history

The changelog of every released version is stored forever in the XML index.

It's not about my script, as this is the first time I'm uploading it to your ReaPack. For now, the script is hosted in my own repository. I'm unsure if ReaPack’s architecture maintains the changelog when the file moves to a different repository.

Even on PCs not having internet (often happens in Studios) the page si working as it must work. It's not an option.

This has nothing to do with requiring internet access?

Access to jQuery: internet is required.
Project requirement: having only 1 file to port. No internet access required. Full functionality

Removing jQuery means using just the standard JavaScript DOM API. Nowadays it's very portable – jQuery is mostly a vestige of ancient times (when Internet Explorer was causing headaches)...

I will see if I can get exactly what I want with minimal intervention. With jQuery it was very minimal.

[cfillion]

Basically:

$('button.reset').on('click', function() {

...becomes:

document.querySelector('button.reset').addEventListener('click', function() {

Same result, self-contained, modern and ~88KB lighter!

Project requirement: having only 1 file to port.

Of course. I didn't suggest otherwise.

[tormyvancool]

Basically:

$('button.reset').on('click', function() {

...becomes:

document.querySelector('button.reset').addEventListener('click', function() {

Same result, self-contained, modern and ~88KB lighter!

Project requirement: having only 1 file to port.

Of course. I didn't suggest otherwise.

JS is just so clunky. Actions that should be seamless aren't. jQuery solved so many issues, not only the old clunky IE (that was ignored by everyone at certain pont) ... That's why it was left where it was and we got jQuery and all the other libs derived from it.
It stumbles upon itself. I would live with jQuery forever to be honest. 28kB never killed a system :-)
BEside this, JS didn't works as I wanted it to work. Too many hiccups and I reminded I already faced out this in the past. So the best thing was to incorporate jQuery and use it. It worked as a charme from day 1.

HNOTE: Having said that, consider I have not clue about what you said "my gripe here is that having a huge dependency base64-encoded is a pain to review". I'm not aware about what operations you have to do to test it.
My guessign is that you test everything on a virtual machine to avoid strange things, ant the base64 decode itself up there. But my idea ends up there.

[tormyvancool]

All correction (but Jquery) have being made.