... but does it really worth it ? I mean is that really that faster to parse ? (theoretically yes because there is less lines, but how much milliseconds for 1000 scripts ?)
all Heda's scripts and mine have these header so it will be a real pain to rewrite all of them... so you have to understand that we are a bit cold at the idea of updating our whole databases...
And it breaks a bit the initial style hehe :P
----
I am for downloading the whole pack.
It is the current solution I propose. Way simpler for everyone.
Under "installing scripts" I mean two actions:
1) download/unzip whole repo (with functions, graphics etc), replace existed if need
2) add/remove scripts to action list by editing reaper-kb.ini file
So only second action should be customized while setup/later updating.
After some pm`s from different users:
I still think not anyone like header even if it most comfortable to get all possible info about script. I didn`t add it myself yet, because I feel it unuseful (mostly I can`t add any script related info like forum thread or release date), and only need for database creating (which also I don`t need since author and script name is enough for me as for regular user, anyway I can google any info about that, I guess Cockos forum always will be first link in results).
I know, to have all related info about script is good...but really who need it? User just wants script works however and by whoever it was written.
Quote:
Originally Posted by cfillion
mpl, can you accept the authorization request for Travis-CI on ReaTeam I sent the other day
One benefit of the different syntax is that it allows strict mistake detection:
Code:
* Key Name: This line is discarded by the parser -> no error
* @author X-Raym
* @version 1.0
* @changelo (2015-11-27)
* + Initial Release
I see three solutions:
1. I use your syntax instead (key: value is as easy to parse as @key value, it's just a bit more ambiguous with normal english)
I don't mind but I can't check for invalid keys if I do that unless every possible (and unused yet) keys are registered too.
2. Compatibility layer: supported keys are understood in your format too (but no error reporting for those)
3. Conversion tool
Key Name: Value --> @key_name value
cfillion, X-Raym, please, let me know, again, which way we use header inside extension (How it will looks like and what the benefits of using it related to extension?).
Just thinking, I didn't add header and after filling whole repo I don't feel my scripts missed something, they just work and that is enough for me. So maybe forget temporary about metadata and concentrate on basic operations?
Version is needed for releasing stable updates and Changelog (optional) to show what changed in a dialog similar to REAPER's(?). Since the extension simply installs everything in the background Author etc is not currently used.
So Version is really the only one required for the basic functionality.
Quote:
Originally Posted by mpl
Didn`t saw anything, can you send again?
It should be in Profile > Organizations > Settings > Third-party access:
EDIT: About the Action List/reaper-kb.ini, the changes only take effect after REAPER is restarted.
For now I think the extension should focus on downloading and updating the files, and let the user load them in his Action List manually.
Well, it is not bad if we don't have proper debug for keys as they are rarely buggy (it is often written from script to script with copy paste).
Focusing on the system that is already in place will be easier for us.... And you will be able to make tests on hundreds scripts pack without waiting :P
I noticed some of your scripts have their Version tag below a blank line. These tags are not detected (I have to draw a line between the header and the code):
Code:
--[[
* Author: ok
* License: ok
* Version: the parser stops before getting down here...
--]]
This would work instead:
Code:
--[[
* Author: ok
* License: ok
*
* Version: ok
--]]
EDIT:
Quote:
Originally Posted by X-Raym
Well, it is not bad if we don't have proper debug for keys as they are rarely buggy (it is often written from script to script with copy paste).
Well, in half of my scripts "last version" is, Last Version & Last Version Dates not included in the scripts header, but only included on changelog.
I was tired to write infos twice --'
Would it be too much to ask to have version infos taken from first entry in changelog ?
--[[
* Script name (if file name will be rewrited by someone)
* Lua script for Cockos REAPER (let any human found this knows what is this code for)
* Author: Michael Pilyavskiy (mpl) (also if someone wants to rename or if we`ll decide to exclude scripter names from common script name to make Action List clean)
* Author URL: http://forum.cockos.com/member.php?u=70694(as basic contact)
* Licence: GPL v3
* Version: 1.0 (I think it is better way to point this directly, and changelog could be described below the header if user really interested what was changes since last version)
]]
(empty line)
(code)
Since I use script for that (of course I didn`t it manually), I can edit common repo scripts this way, if this header is ok.
There are desciptions already in some non-selfexplainable scripts but as a comment or another way, I`ll add it to desciption prefix later.
Script Name - I firstly look at your first script in first folder:
Quote:
/** * Display selected tracks and takes color in the console
* EEL Script for Reaper
* Displays tracks and takes color in RGB and HEX values in the console.
* Author: X-Raym
* Author URl: http://extremraym.com
* Reposotory: GitHub > X-Raym > EEL Scripts for Cockos REAPER
* Repository URl: https://github.com/X-Raym/REAPER-EEL-Scripts
* Source URl: https://github.com/X-Raym/REAPER-EEL-Scripts/Display selected tracks and takes color in the console.eel
* Licence: GPL v3
* Forum Thread: Script: Display selected tracks and takes color in the console
* Forum Thread URl: http://forum.cockos.com/showthread.p...57#post1480557
* Version: 1.0
* Version Date: 2015-15-02
* REAPER: 4.76
*/
So I though parser will automatically guess first line as reascript name (there is no prefix / no another prefix / "ReaScript name" prefix).
I don`t think I should add whole header mostly with empty values, but only minimum fields + what I think header for current script should comes with. I also don`t put supported version since I supposed user installed latest official releases of REAPER and SWS, so I willn`t get expected bugreport.
I also did put /* instead /**. Why did you use what?
The script script my repo, you should check the last one hehe :P
Okay for the minimum header fields,
But really what make parsing easy is that all pattern matching are the same,
if it has to be adjust once time for prefix, one time for line number... Not very easy and extensible.
And I know it because I already made a script header parser :P
Note that I also use ReaScript Name:
instead of just Names or just ReaScript
so anyone can find that it is a ReaScript (for REAPER)... and that it is its name (which can differ from its file name, action name, undo name etc...)
EDIT : Oh yeah, and I think Repo URL is important for cfillion
I should point somehow anyway what language used for this script.
Repository URL (why lower L?) - ok.
So
Quote:
--[[
* ReaScript Name: Bypass all FX except instruments on all tracks
* Lua Script for Cockos Reaper (I don`t think it should be parsed, who cares it is lua or eel script. So I added it if someone will download single script, delete its name with extension and willn`t know what extension add)
* Author: Michael Pilyavskiy (mpl)
* Author URL: http://forum.cockos.com/member.php?u=70694
* Repository URL: https://github.com/MichaelPilyavskiy/ReaScripts
* Licence: GPL v3
* Version: 1.0
]]
(empty line)
(code)
is ok (for now replacing such thing not so painful for me as its automated)?
@mpl Search and Replace in All folder and subfolder files in Notepad++ :P (other code editor have feature)
then, a simple commit like the other, using GitHub APP.
mpl, all 65 scripts on your repository are passing the metadata test: http://sprunge.us/TOfB
This mean they can all be indexed and installed using the manager without further modification.
On ReaTeam/ReaScripts I added a version tag to most of the script in the metadata branch. Test results after the change: http://sprunge.us/bQEH (20 failures).
The remaining scripts don't have any information at all...
(I used 0.2015.12.25 format on the scripts without existing version numbers. Versions are sorted numerically so the zero is important to not shadow a future v1 release)
I don't think I can enable travis on the repository myself as it requires admin rights. Can you go on this page: https://travis-ci.org/profile/ReaTeam and enable it on ReaScripts for me?
------
Quote:
Originally Posted by X-Raym
Would it be too much to ask to have version infos taken from first entry in changelog ?
Well, the content of a multiline tag must be indented to be understood unambiguously:
Code:
--[[
* Changelog:
* This indented block of text is the changelog content.
* There is no ambiguity with the next line:
*
* This line is not part of the changelog.
--]]
In some of your scripts (for example this one: https://github.com/X-Raym/REAPER-Rea...tems%20end.lua) the changelog is both below an empty line and with unindented parts. It is not practical to parse...
I think I could write a short script to fix this AND add the missing Version tag since you are using this same syntax almost everywhere. I think it's simpler to do this rather than adding tricky workarounds in the parser.
Quote:
Originally Posted by X-Raym
EDIT : Oh yeah, and I think Repo URL is important for cfillion
I use git directly to get this information. It can be in the header too but for the indexer it's not necessary.
Quote:
Originally Posted by mpl
So I though parser will automatically guess first line as reascript name (there is no prefix / no another prefix / "ReaScript name" prefix).
I'd prefer if everything is prefixed the same way. But right now the manager does not need these tags anyway (only version and changelog are used) so any style is ok.
Quote:
Originally Posted by mpl
I don`t think I should add whole header mostly with empty values, but only minimum fields + what I think header for current script should comes with.
I think that's the right thing to do: tags with empty values risk causing validation errors in the future because they are considered as boolean flags (but as long as they are unused they are just silently discarded).
------
About user-configurable repositories (which is almost finished, by the way):
I think the easiest way to subscribe to a new repository would be to have a special file written by the repo maintainer downloaded then imported into the extension by the user (a bit like REAPER licenses are):
File Name.ReaPackRemote
Code:
Developer Name
https://github.com/dev_user/ReaScripts/raw/master/index.xml
Extension Menu > ReaPack > Import new repository...
The first line determines the name of the folder where the scripts will be downloaded. It would have to be a unique value for every repository.
Please push your header changes on the metadata branch instead of master so it will be added to the pull request and automatically re-tested by travis. https://github.com/ReaTeam/ReaScripts/pull/2
Quote:
Originally Posted by mpl
Parser will just ignore that line, right? Or I should add some prefix also?
Done.
Now header for my and for common repo should be parsable. I see you already started adding headers manually, but I added it automatically by script, so it looks same as my and X-Raym repos. I added header roughly by Lua script, which parsed scripter name and script name into related fields. So, it needs to edit some of them more or less, I just added strong header to make all scripts at least parseable.
I`m not competely understand what Travis is (I understood, that is for checking synthax or something but how related to extension?), so if these things only useful to build extension and you need them, I can give you admin rights (you`re already have write permissions, is`t it?). Note, I still new to github so I can flounder in git actions and damage something (I think I already did something non-expected by myself and merged metadata to master, is that so?). I gave you green light by adding to owners so do what you want/need
Sexan, here my thoughts:
1) I can add this if Tritone not against it (I wrote him pm already)
2) What it counts, and why 1 minute instead, say, project state change + mouse context changes + transport play/rec time?
3) difference from "split at time selection"?
Oh, I'm not very good at explanations, timer counts time and afk is set to 1 minute which can be modified (don't know what actual time is good but for me 1 min after I'm gone is good),but if you have better explanation please use it.
Smart split is very different then "split at time selection" :
it is combination of it with "split at edit cursor", when using sws "split items at time selection (if exists) else edit cursor" you can't split at edit cursor within time selection .
This one allows editing at time selection and while time selection still exists it allows to split anywhere at edit cursor.
So its a 1 shortcut to do split at edit cursor and time selection without of limitations of not being able to split at edit cursor in the time selection.
my script
sws split at timeselection edit cursor
so the short summary , there is no action (1 shortcut) that allows splitting IN the time selection unless using more shortcuts.
btw SWS is required because I'm using "Make crossfade at left of edit cursor"
Interesting stuff in this thread! Keep up working on it!
I am not sure if I have anything useful and interesting enough to contribute to the script repo, most of my scripts are completely specific to my own workflows but I can take a look if I happen to have something worth sharing.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
I`m not competely understand what Travis is (I understood, that is for checking synthax or something but how related to extension?), so if these things only useful to build extension and you need them, I can give you admin rights (you`re already have write permissions, is`t it?). Note, I still new to github so I can flounder in git actions and damage something (I think I already did something non-expected by myself and merged metadata to master, is that so?). I gave you green light by adding to owners so do what you want/need
Many thanks! Travis is for checking new commits and pull requests so we can know if the metadata are parsable and ok before contributions are merged.
This is part of the build system to generate the package database the extension is using.
You can run the build scripts on your own computer (the code is written in Ruby so it must be installed beforehand) with these commands:
Code:
cd Path/To/ReaScripts
bundle install # installs the metadata parser, reapack indexer and their dependencies
bundle update # updates the parser and indexer if I made change to them
bundle exec rake # checks the metadata of every script (this is what Travis runs)
bundle exec rake index # generates or updates index.xml for the extension
The last command (rake index) must be ran once in a while to release updates to the users, as "index.xml" contains the full list of scripts in a machine-readable format for the extension.
(I developed the tools on OS X, but it should work fine on Windows too)
In summary:
1. The scripts must have at least a Version tag and optionally a Changelog tag. For now everything else is ignored.
2. Travis ensures every new contribution on the repository matches the first rule.
3. The repository must be processed once in a while in order to generate a file named "index.xml" using command `bundle exec rake index`
4. The extension download and read that index.xml file to know what it must do on the user's computer.
EDIT: Oops, in the last commit you deleted the build system files (Rakefile, Gemfile, .gitignore, .travis.yml and index.xml). No trouble, thanks to git nothing is lost.
I thought it is something auto generated from metadata branch since there aren`t headers in scripts inside this branch (or they written another way). As you see, I cnanged all headers in master, so be free to add to master what you need.
cfillion, I didn`t got it: should every repo holder install all of this to make it compatible wit extension? If so, it look some complex to me (and for X-Raym, I guess) since I didn`t figured out what should I do step-by-step. Also, can we exclude these files from zip package, for example when user download it directly from github (I remember I saw "gitignore" or something)?
Sexan, just ran smart split and get sexan_SmartSplit.lua:52: bad argument #1 to 'GetMediaItemInfo_Value' (MediaItem expected), just selected 2 items and ran. Please fix possible bugs and make a good description since script name/first run not self-explainable. I also didn`t get what project timer do. If it should counts time when project is opened, I don`t understand why did you add 1 minute timer. And if it counts "action" time when user do something with this project (which is true) then your script not implemented correctly (it counts also time when project "sleep").
Sorry for writing this. When I add any script to repo I test it, so I can`t add it if it has bug at first run and if I don`t understand what it does actually while there is no any description so I can`t use it.
I'll confess I've only skimmed this thread, but it sounds like good work is being done toward creating some sort of central repository for ReaScripts. If what I've done seems worth adding, please let me know how to package it to fit your format.
Cheers,
Mike
__________________
Write music faster with Tbon. https://github.com/Michael-F-Ellis/tbon
Mac mini, 2.3 Ghz core i7, 16GB Ram, Linnstrument #437, Technics P30
"What survives every change of system is melody." -- Igor Stravinsky
never mind,I see this is way over my abilities to maintain,I will remove the links.I can't reproduce that bug with split item, I'm using it daily for a long time now an not seen any bug (especially that kind of error which is crucial for a script to work)
Nevertheless looking forward for this tool.
Interesting stuff in this thread! Keep up working on it!
I am not sure if I have anything useful and interesting enough to contribute to the script repo, most of my scripts are completely specific to my own workflows but I can take a look if I happen to have something worth sharing.
Michael Ellis, firstly, nice idea.
As you can see, I don`t add any python script since it needs so much additional actions for regular user (should I mention python slow as hell?). Even install of this already painfull, while all of this could be rewrited and wrapped into single (and relatively simple) EEL/Lua script so user will not need to install anything and just use it from action list.
Anyway, if someone will rewrite it into EEL/Lua and point your name in scriptname/credits - is it will be ok for you?
Michael Ellis, firstly, nice idea.
...
Anyway, if someone will rewrite it into EEL/Lua and point your name in scriptname/credits - is it will be ok for you?
Thanks. If someone wants to rewrite it, that's perfectly ok with me.
__________________
Write music faster with Tbon. https://github.com/Michael-F-Ellis/tbon
Mac mini, 2.3 Ghz core i7, 16GB Ram, Linnstrument #437, Technics P30
"What survives every change of system is melody." -- Igor Stravinsky