Currently only an operating system requirement can be specified (per individual file). Scripts can manually test for REAPER/SWS compatibility by checking at runtime whether a particular API function exists or by testing the version with the new reaper.ReaPack_CompareVersions API (v1.2beta2+).

I think I could add this @requires feature in ReaPack v1.3. ReaPack currently handles incompatible packages by hiding them away. I think it would be better to show them but with a clear error message upon installation attempt. They would need NOT to be installed when synchronizing with the option to install everything is ON though, because that would be annoying (getting errors every time...).

Hi guys.
I just remove StigeT (Sonic Anomaly, supermaalima) plugins from Reateam repository because they were very outdated and with old/no GUI. Nowadays SonicAnomaly has his own repository and I hope it is easy for him make different updates for his great plugins.

You can still hold his old plugins (just not allow to remove JSFX if ReaPack ask you to remove these JSFX as obsolete).
For adding new stuff:

Hi guys.
I just remove StigeT (Sonic Anomaly, supermaalima) plugins from Reateam repository because they were very outdated and with old/no GUI. Nowadays SonicAnomaly has his own repository and I hope it is easy for him make different updates for his great plugins.

You can still hold his old plugins (just not allow to remove JSFX if ReaPack ask you to remove these JSFX as obsolete).
For adding new stuff:

Another idea:
Option to select script section(s). User may select sections himself. Let's say there are scripts 'Save time selection' and 'Restore time selection'. Some people would like to run this scripts from midi editor, some users - from from media explorer, others - from both midi efitor and media explorer.

Another idea:
Option to select script section(s). User may select sections himself. Let's say there are scripts 'Save time selection' and 'Restore time selection'. Some people would like to run this scripts from midi editor, some users - from from media explorer, others - from both midi efitor and media explorer.

What do you mean by selection? If you mean to register the same script in more than one Action List section or to bundle multiple scripts in a single package then the answer is yes, with reapack-index's @provides tag.

cfillion thanx very much, will try it soon!
As for last idea: I mean user can optionally choose sections himself (main/midi/media_explorer..):
script A - main, script B midi editor, script C - main and midi editor

There is nothing stopping them from loading or removing the script into any Action List sections manually in REAPER. (Of course ReaPack won't know about this so, when uninstalling, the script will remain in the sections where it was manually added.)

As we might be approaching a next version of of ReaPack, and due to ongoing discussions regarding Reaper extensions needing to be more easily available, especially for new users, I'd like to recapitulate and retrigger some thoughts already discussed here in the past.

1) ReaPack should be distributed and installed with a new installation of Reaper by default.

2) ReaPack should always be available as the top entry in the "Extensions" menu.

3) Very commonly used and "unreplaceable" stuff like SWS and MidiToReaControlPath should be (easily) available via ReaPack.

4) VSTs should be manageable by ReaPack. I suppose such VSTs could be located in a folder in the Reaper Ressources which accordingly should automatically be added to the VST search path.

5) It should be (easily) possible to create "pure description ReaPacks" that provide descriptions for extensions that are either not managed by ReaPack or are in a format (e.g. VSTs) that don't allow for adding an internal description.

7) ReaPack should be usable to (easily) allow volunteers to provide description texts for the Reaper stock plugins (JSFX and VST).

8) Reaper should (automatically and obviously in favor of new users) be provided with functions to "context sensitively" show the descriptions of the installed extension and plugins (maybe ReaScripts, Themes etc, as well, but I am a newbie regarding such). E.g. "F1" on a JSFX plugin installed in the Track's FX chain.

9) There should be a "recommended" repository managed by a group of volunteers, containing decently tested and description-providing extensions.

1) ReaPack should be distributed and installed with a new installation of Reaper by default.

3) Very commonly used and "unreplaceable" stuff like SWS and MidiToReaControlPath should be (easily) available via ReaPack.

It's OK with me if the devs decide to do that. As for SWS and MIDIToReaControlPath to be available through ReaPack, it's up to their maintainers to make it so.

Quote:

Originally Posted by mschnell

2) ReaPack should always be available as the top entry in the "Extensions" menu.

Currently the order of that menu depends on the order in which the extensions are loaded. It's "gentleman-like", nobody fights for a better spot, so I like that.

REAPER loads ReaPack before SWS when they are both installed into the same UserPlugins folder.

I mean, I could force ReaPack's menu to be at the top even if SWS gets loaded first. But there is no guarantee that some other extension won't do the same thing afterward (put its menu above mine) and we'll be back to square one.

Quote:

Originally Posted by mschnell

4) VSTs should be manageable by ReaPack. I suppose such VSTs could be located in a folder in the Reaper Ressources which accordingly should automatically be added to the VST search path.

I can do that, in fact I already wrote the code when we discussed about this previously. But I can't beautifully change the VST search path to include the resource folder. I feel like that's a blocker.

Quote:

Originally Posted by mschnell

5) It should be (easily) possible to create "pure description ReaPacks" that provide descriptions for extensions that are either not managed by ReaPack or are in a format (e.g. VSTs) that don't allow for adding an internal description.

7) ReaPack should be usable to (easily) allow volunteers to provide description texts for the Reaper stock plugins (JSFX and VST).

I hear you, I haven't forgot about your FR. It won't happen in this v1.2 release. This is a big and complex change and I want it done properly or not at all. Perhaps in v1.3, but I don't promise!

Quote:

Originally Posted by mschnell

8) Reaper should (automatically and obviously in favor of new users) be provided with functions to "context sensitively" show the descriptions of the installed extension and plugins (maybe ReaScripts, Themes etc, as well, but I am a newbie regarding such). E.g. "F1" on a JSFX plugin installed in the Track's FX chain.

I already added API functions for this, so it can be done. In REAPER itself or in individual scripts. ("Show ReaPack about dialog for the focused JSFX.lua" uses that API)

Quote:

Originally Posted by mschnell

9) There should be a "recommended" repository managed by a group of volunteers, containing decently tested and description-providing extensions.

I think this should be the ReaTeam repositories. If you or anybody find broken or badly documented packages, you're welcome to send Bug Reports or, even better, Pull Requests to make it better!

I feel that Reaper is one of the greatest pieces of software around, and a decent part of this is it's extensibility. And here ReaPack is a wonderful (and IMHO necessary) tool.

But it is not visible to new users, you only get to know about ReaPack (and with this to a whole world of extensions and - extremely important - instructions and descriptions of same enabling selection and usage) after e.g. following discussions in the forum.

That is why I strongly suggest (to Cockos) to install PeaPack by default , visible at a very prominent position.

Moreover to use it's power in the most comfortable way (e.g. providing context help for supported JSFXes (and hopefully other stock plugins and extensions) "out of the box")

Regarding the ReaTeam repositories, IMHO there should be a place where decently tested packages are found and the test should include the documentation provided. New users should be able to benefit from the extensions in there as they are easily found and can be used without asking in the Forums what to do, which to install, and how to work with same. (Right now, I don't want to send deletion request for all ReaTeam packages that don't feature decent MarkDown documentation .)

The issue for a new user when confronted with all this stuff is:
- Do I know it exist? (easy installation)
- What is it? (Description)
- Is it dangerous? (well tested)
- Is it useful to me/ how to use it? (Tutorials, documentation, showcases)

The issue for a new user when confronted with all this stuff is:
- Do I know it exist? (easy installation)
- What is it? (Description)
- Is it dangerous? (well tested)
- Is it useful to me/ how to use it? (Tutorials, documentation, showcases)

IMHO those are issues for all users, even advanced ones. There are so many great scripts and packs, beside configuring REAPER to death you can deal a lifetime with exploring and understanding all those scripts. This FR would solve a part of the problem:https://forum.cockos.com/showthread.php?t=159461
I would suggest a 5 star system in the action list so you can give your lifesavers 5, tools 4, useful 3, maybe useful 2 and good to know 1 stars e.g.
Regarding your point 2 and 4 - description, documentation and showcasing - this is a job of the script writers and fans. For some there exist wonderful threads or even github pages / wikis (the smart split tools e.g.). X-Raym makes a wonderful documentation within his scripts which is important in case someone wants to modify or just understand it. Maybe a kind of codex can help here to bring all the different styles of documentation in line?

FWIW, I made a copy of the DLL before running sync, restarted Reaper (5.65pre16) and got this (image), no biggie just thought I'd let you know. I've never seen an app complain about a copy of a file before.

@Edgemeal This verification exists to prevent REAPER from loading two ReaPacks at the same time. It also prevents new users from installing it in the wrong directory (eg. Plugins in Program Files) or under an arbitrary filename by mistake.

Im running Reaper(64) v5.62
with ReaPack v1.2
in this folder C:\Program Files\REAPER\UserPlugins
I have relaunched several times
I went to the menu editor and RESET all menus

Still not showing up in the menu
Not showing up in Actions list

Nothing too exotic about my installation. It's not a portable install. I did notice that UserPlugins did not exist so I created it.

I'm running windows 10 (up to date)

Any ideas?

Okay when I was reading through everything, I did notice that someone mentioned something about a roaming profile. Is this the Reaper installation default? Am I the only one in this thread who has this folder?
C:\Users\[uname]\AppData\Roaming\REAPER\UserPlugins

Anyway, seems to be working now.

Might be a good idea to mention this possibility in the installation guide.

This is a bugfix update mainly for compatibility with the resource path encoding changes of REAPER 5.70 on Windows. This release includes a few other fixes and changes as well.https://reapack.com/release-notes/v1.2

@Christian: what is the suggested way to add an external "MIDI functions.lua"?
Would I put it in the folder "MIDI Editor" or "Functions"?
And how to I tell ReaPack that a script is depending on "MIDI functions.lua",
simply by adding @provides 'MIDI functions.lua' to the script?

First put @noindex as header in the function file so reapack-index won't think it's a package of its own.

Then, yes, put @provides MIDI functions.lua in the header of your script to add it to the file list. It can be in any folder of your repository. For example: @provides ../Functions/MIDI functions.lua.

Note that only one unique package may own a particular filename on the user's computer. If you need to share this function file among multiple packages it must be installed under a different name for each. Using reapack-index this can be done like this: @provides ../Functions/MIDI functions.lua > The Script Name/MIDI functions.lua.

First put @noindex as header in the function file so reapack-index won't think it's a package on its own.

Then, yes, put @provides MIDI functions.lua in the header of your script to add it to the file list. It can be in any folder of your repository. For example: @provides ../Functions/MIDI functions.lua.

Okay, great! The spaces in the file are no problem? Or will I need to put the filename in '' ?

Quote:

Originally Posted by cfillion

Note that only one unique package can own a particular filename on the user's computer. If you need to share this function file among multiple packages it must be installed under a different name for each. Using reapack-index this can be done like this: @provides ../Functions/MIDI functions (path on the repository).lua > ../Functions/MIDI functions (unique name of your choice).lua.

Sorry, I'm confused, is a package a single script or a complete repository?
Let me explain, what I got. I have several transpose scripts. They all will use a function in MIDI functions.lua. Will this work?

Spaces are fine. Each line in Browse packages is a package. Packages may contain multiple scripts and files. Repositories contain multiple packages. Everything with a @version number and metadata is a package.

I meant that to reuse a file in multiple packages it must be saved under a different filename for each:

But in the case of your transposition scripts there are two better ways. First they could be released as a single package sharing the same version, changelog and other metadata.

Additionally it can be made as a single source file on the repository and have ReaPack install that 10 times under different names. (Assuming the scripts are all identical except for the interval variable.) Like this:

I see, I think I had a completely different understanding of packages.
Packages usuall carry one script, but they are not limited to do so.
They are somewhat container. The example above is pretty clever!