Following the example demo provided by Michael Becker, I’ve built a Tinderbox file that parses text data from my iOS workout tracking app, then creates notes and attributes that let me analyze and plan my workouts.
Next steps include more functionality AND adding Posters to graphically display the data.
Comments and ideas welcome!
Workout Repcount processing.tbx (551.6 KB)
Small observation, in the Logging functions:
function LogDate(s){var t=date("today");
Log(t.format("l")+" "+t.format("t")); };
An input ‘s’ is defined but not used, so likely not needed. Bear in mind the app expects an input, even if only an empty string, for each defined input. I suggest (line breaks for clarity of reading†):
function LogDate(){
var t=date("today");
Log(t.format("l")+" "+t.format("t"));
};
Unless LogDate() is meant to only be used to generate inline text sent to the log, you might consider adding a line break "\n" after formatted data, or at least a space, else the next log input will butt up against the end of the date time string.
Not a big deal, as you don’t appear to actually use this function. 
†. Layout issue like this are entirely a matter of personal choice. As long as you meet Action Code syntax rules the app’s code parser ignores line breaks. This is why, in a multi-line piece of code, line terminators (the semi-colon) are needed else successive lines are (mis-)read as a single exprtession.
I suggest adding a definition for your user attributes, especially if sharing with others. Names are not always as indicative—or memorable—as we assume when making them. For instance, the meaning of $Vol isn’t guessable.
Of course, if I had the RepCount app (I don’t) I might know. . In that vein, why not—in your shared demo—add a note that holds un-parsed data. That way more people can try out and (learn from) your code even if their own task is different.
$bodypart doesn’t appear to be used. Your ‘Future Work’ note hint at this “…e.g., Matrix Lat Raise = Shoulders, …” where i’m guessing "shoulders might be the $bodypart value.
None of the above are errors/bad practice, just odd things noticed when perusing the code. Kudos to you for sharing and for getting as far as you have. the slope seems steepest at the start. The more pre-existing structure you have, things get a bit easier.
A couple more minor observations from stamp “Process Repcount”
//create Startdate from first line of Text
Attribute names are case sensitive. A good habit to acquire—whatever your personal attribute naming strategy is to use the correct casing of the attribute you are describing. Checking further down the code, the comment actually refers to StartDate not Startdate (the latter would be a different attribute). Now, while the code is fresh in mind, that might seem a snippy observation but it draws on experience. Months from now, you might be chasing a glitch which turns out to be a mis-named (mis-cased!) attribute reference. i’ve certainly done that in the past.
Again for future self, it might be useful to comment what your regex are ding. the first seem to look for aline starting with a single letter character (upper OR lower case) followed by zero-or more of any character. The next seems to look for a line containing (should that be starting with?) one or more successive digit characters, zero or more white space, a single ‘x’, zero or more white spaces then one of more digits.
As said these are minor things (but you asked ). Overall it looks good. Well done!