Hello all,
cubaxd and me are finally working on setting up the new English OpenMPT Wiki.
The wiki will be based on the OHM by Harbinger (http://forum.openmpt.org/index.php?topic=4387.0) and will eventually serve as a basis for generating a quick start guide that can be included with OpenMPT.
Luckily, thanks to Harbinger, all the content is already there - it's just in the wrong place. Now, the plan is to
- proof-read existing texts (there are still many minor and not-so-minor wrong facts in the OHM) and
- transfer them to the wiki afterwards.
- All screenshots should also be re-done for a more consistent look and decreased file size.
The wiki structure will be set up by us first, then converting / transferring articles can be started. For the latter, we need your help. I am looking for people that would be willing to spend some time proof-reading texts from the OHM and then copy them to the wiki. Requirements are:
- Some experience with OpenMPT. If you feel very confident with you knowledge about a certain part of OpenMPT, you are more than welcome than proof-reading / uploading texts from that section. Of course you don't have to be an expert in everything (who is that, anyway?), so if you feel unsure about an article you are copying, you can simply ask here.
- Basic experience with MediaWiki. MediaWiki uses a rather uncommon markup system that doesn't look like HTML or BB Codes. MediaWiki doesn't come with a WYSIWYG editor, but provides some buttons for inserting MediaWiki markup. It's really simple, but if you have never worked with MediaWiki software (f.e. on Wikipedia), you should have a look at their help sites (http://www.mediawiki.org/wiki/Help:Editing_pages).
This may sound like some big requirements, but they are really basic. The more people help, the less work it is for everyone of us. I'm looking forward to your responses.
Im in!
Would be glad to help.
Also I ;D
Me Mio = IN
Thanks for your interest. The wiki is in progress of being set up, and some articles have already been copied over for testing the look and layout of the pages. While doing so, I thought I should probably set up a preliminary style guide that should be taken care of when transfering articles:
- Apostrophes: "VST's", and even more so "VST´s" is not a correct english plural. Plurals go without an apostrophe (or even accent as in the latter example), so please remove those when you spot them.
- Prefer writing out words over informal style, f.e. "you will" instead of "you'll", or "cannot" over "can't". It simply looks better in such a document.
- Replace passages written in CAPS by bold print or italic print where it makes sense.
- Always use "MIDI", not "Midi".
- Similarly, "ModPlug" should be preferred over "Modplug".
Hell, even i'll help wherever i can! :D
Keep in mind folks, i'm about 90% done with the 1.19 CHM version and i do have a lot of updated OHM subdocs ready to upload. It'd been better if Jojo had sent me a PM requesting the latest version of the OHM subdocs, but we'll forgive him this time :P !
I intend to transfer all the non-Reference documents to the CHM Helpfile, but keep the Reference section as a separate PDF. If MPT 1.20 is less than a few months off from release, i'll hold off and update what i have with the new features. Eventually this will hopefully spawn a single HTML file for those who aren't or don't want to be online when they're tracking, but like the navigation features available in HTML. Of course, none of this has any bearing on the OpenMPT Wiki assembly.
One last thing:
I encourage you if you want to know the correct pluralization of ENGLISH acronyms, you read this from the Wikipedia page (http://en.wikipedia.org/wiki/English_plural#Irregular_plurals):
Quote
Plurals of symbols and initialisms
Individual letters and abbreviations whose plural would be ambiguous if only an -s were added are pluralized by adding -'s.
mind your p's and q's
A.A.'s and B.A.'s
the note had three PS's
Opinion is divided on whether to extend this use of the apostrophe (http://en.wikipedia.org/wiki/Apostrophe_(mark)) to related but nonambiguous cases, such as the plurals of numerals (e.g., 1990's vs. 1990s) and words used as terms (e.g., "his writing uses a lot of but's" vs. "his writing uses a lot of buts"). Some writers favor the use of the apostrophe as consistent with its application in ambiguous cases; others say it confuses the plural with the possessive (http://en.wikipedia.org/wiki/Possessive_case) -'s and should be avoided whenever possible in pluralization, a view with which The Chicago Manual of Style concurs.
...
Acronyms (http://en.wikipedia.org/wiki/Acronyms) are initialisms (http://en.wikipedia.org/wiki/Initialisms) that are used and pronounced as if they were words. For example, we have AMTRAK, HAL, LEM, NASA, and NATO. These contrast with the different variety that are read aloud one letter at a time: {C.I.A., C.S.M., D.O.D., E.U., G.C.M., G.P.S., I.B.M., N.A.C.A., N.S.A., R.C.A., R.P.M., S.S.T., T.W.A., U.S.S.R., W.P.A., etc.}
The most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix. This works well even for acronyms ending with an s, such as with CASs (pronounced "kazzes"), while still making it possible to use the possessive form ("'s") for the acronyms without confusion. The old, old style of pluralizing single letters with "'s" was naturally extended to acronyms when they were all commonly written with periods. This form is still preferred by some people for all initialisms and thus "'s" as a suffix is often seen in informal usage.
"VSTs" is universally accepted, but according to this article, my education was right, acronyms are to be pluralized with 's to eliminate ambiguity. "VSTis" could be construed as a typo of "VST is" or "overread" as "VSTs" for those who read quickly. Since VSTi is the universal term for a VST-based instrument, then the only question is whether to PROPERLY pluralize it or pluralize it to the whim of one or two.
If an argument is to be made that the pluralization of VSTi may be confused with the possessive form of VSTi, then i defer to the context of the sentence in which "VSTi's" is found.
If there is still disagreement after this, perhaps we should take a vote by the members of the forum.
Other than that, i'm totally in agreement with Jojo's standardization guidelines.
That article also says:
Quote from: http://en.wikipedia.org/wiki/English_plural#Plurals_of_symbols_and_initialismsThe most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix.
"VSTis" is pretty pronounceable, so there are arguments for both cases. We could simply go for "VST instruments", there is no doubt in how to pluralize that. It would also make distinction between effects and instruments easier, because the difference would be more than just a single letter.
QuoteI intend to transfer all the non-Reference documents to the CHM Helpfile
I hope you have not spent too much time figuring out how to create CHM files, because I can just use the wiki to create DocBook documentation (next to PDF/ODF export), which then can be compiled into CHM files.
Quote from: Jojo on August 30, 2011, 20:21:26
That article also says:
Quote from: http://en.wikipedia.org/wiki/English_plural#Plurals_of_symbols_and_initialismsThe most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix.
"VSTis" is pretty pronounceable, so there are arguments for both cases. We could simply go for "VST instruments", there is no doubt in how to pluralize that. It would also make distinction between effects and instruments easier, because the difference would be more than just a single letter.
No, "VSTi" is not pronounceable, unless you're pronouncing it as "vist-ee" or the like. I've always read it and prounced the term "V-S-T-I" one letter at a time.
I believe the first sentence of a guidelines paragraph should be the one that carries the most weight, unless it can be shown that exceptions can be found...
Perhaps we should start a vote...
Quote from: Jojo on August 30, 2011, 20:21:26QuoteI intend to transfer all the non-Reference documents to the CHM Helpfile
I hope you have not spent too much time figuring out how to create CHM files, because I can just use the wiki to create DocBook documentation (next to PDF/ODF export), which then can be compiled into CHM files.
Uh, yeah, as a matter of fact i have. Like i said, "i'm about 90% done with the 1.19 CHM version ". It will be done a lot sooner than you can export one from the Wikipedia documentation. Plus, i have added a few more things which are not present in the current OHM, not just updated info.
Concerning any progress on the help manual front, since i have been the one to do the most assembly of something everyone can use to shallow out the learning curve, i would appreciate PMs concerning anyone's intentions of help files that will be made public. I have a lot more than what you see in the OHM or what's been uploaded at sourceforge, such as notes, images, etc.
YOU can save yourself alot of work.
Sorry, I misunderstood the word "pronounceable". Anyway, I'm still with "others say it confuses the plural with the possessive -'s and should be avoided whenever possible". If somone else has an opinion, state it here.
It would be helpful if you could at least provide an updated TOC if the new documentation is not ready yet - currently we have set up a slightly altered TOC with page references, which would need to be updated if any page numbers have changed.
I have a myriad of other projects going, but i will try to fit it into my schedule. I guess i can put off trying to complete and touch-up the CHM, and focus on compiling all the changed documents and images now that other versions are to be made available. Give me a week. 8)
Current wiki main page with reordered TOC:
(http://sagagames.de/ithumb/thumbs/wiki-current4170uv34.jpg) (http://sagagames.de/ithumb/show/wiki-current4170uv34.png)
Pretty snazzy!
I especially like that the ONLINE help is called the OpenMPT Wiki page. I was always concerned that new users would misunderstand the OHM as the online version rather than OFFLINE.
Now if we can get these pages written up and some of the new sensible FRs coded, we'll be the number one tracker out there!
Quote from: Jojo on August 30, 2011, 21:33:52It would be helpful if you could at least provide an updated TOC if the new documentation is not ready yet - currently we have set up a slightly altered TOC with page references, which would need to be updated if any page numbers have changed.
After reviewing my copy of the docs, i realized i only made a couple of small changes to the current OHM source docs, mostly corrections mentioned by Jojo, including the use of %APPDATA%. Shortly after 1.19.01 was uploaded, i went about starting the CHM version (Windows Helpfile), and imported all the OHM docs into that project. While i did make corrections and updates, i made them to the
CHM not the OHM. Therefore the source docs do not have all the updates and edits needed for the Wiki page authors.
The upshot of all this is that i can upload nothing of real import to the effort; that is, you'll have to use the OHM source docs that are currently at sourceforge. I will update the source docs AFTER the CHM is complete, and i "retrodate" (as opposed to update) my source docs before uploading to sourceforge. IOW, i will continue making edits to the CHM, then when i'm done, go back and edit the OHM based on my work in the CHM. Capiche?
This means of course it will take more than a week, more like a few months, unless i can get my schedule cleared and interest piqued. Do what you can with what is there at sourceforge...
OK. I guess retrofitting changes into the Wiki shouldn't be much of a problem, just a lot of work probably. Though on the other hand, as advised in the first post, people should proof-read texts before submitting them anyway, so there is a chance that at least some corrections will make it on the wiki before you get to release an updated version anyway.
I can help with the pictures / design if you need any. looking at the ohm, I think so, I'm a graphic designer, and I often come on this webpage so send me a message.
Well, in the first place I wanted to keep it simple. Exporting from MediaWiki to PDF currently truncates most CSS styles (only a few like colours and such are actually converted), so article designs must be kept simple. I haven't checked yet if the same is true for DocBook export (which could be used for generating a CHM file), but I guess it will be.
Quote from: Exhale on September 09, 2011, 08:36:13
I can help with the pictures / design if you need any. looking at the ohm, I think so, I'm a graphic designer, and I often come on this webpage so send me a message.
If you use MPT, most of what's needed is screenshots of the various dialogs, examples, and other GUI images that show the new user what to expect or look for when using MPT. Jojo has requested (and i concur) that these should be formatted as PNG files for clarity and minimal size. And while i have created
new graphics in PNG, older images are still in JPG, only because i haven't needed to update them. Feel free to complete these updates (but use fresh images -- don't convert JPGs to PNG; that defeats the purpose).
The only problem is, we'll need a standard. Since i was the only one creating the images, i just used my system, which i'll admit may not be that universal in appearance. Now that everyone is contributing to the transfer and maybe updating or adding new docs and images, the GUI appearance for example graphics and screenshots should have a uniform look.
Other than that, images for headers and such i'm sure can be requested by Jojo or other contributors...
Quote from: Harbinger on September 13, 2011, 19:35:09
The only problem is, we'll need a standard. Since i was the only one creating the images, i just used my system, which i'll admit may not be that universal in appearance. Now that everyone is contributing to the transfer and maybe updating or adding new docs and images, the GUI appearance for example graphics and screenshots should have a uniform look.
What about using Windows Standard theme? It's
standard, and OpenMPT uses Windows' native GUI. Maybe look ugly, but controls are shown correctly, without white areas between them and similar problems with themes.
Well, "Standard" depends on the Version of Windows you're using. On XP it's luna, which is ugly and luna screenshots tend to be big. Personally I'd want to keep all screenshots in Win2k style. That's available on all OSes from Win98 through Win7.
Quote from: Jojo on September 14, 2011, 21:14:42
Well, "Standard" depends on the Version of Windows you're using. On XP it's luna, which is ugly and luna screenshots tend to be big. Personally I'd want to keep all screenshots in Win2k style. That's available on all OSes from Win98 through Win7.
Personally I am always talking about the better known Windows Classic theme, Luna on XP it's the
default. Also, starting from Vista, the classic theme it's under the name of Windows Standard instead classic, just as a note.
I've never liked the Win 2K look, but if it's easily accessible to all, then let's go with that. Only problem is, on XP, how do i enable this theme? Be specific, for everybody now and in the future....
Quote from: Harbinger on September 19, 2011, 13:49:23
Only problem is, on XP, how do i enable this theme? Be specific, for everybody now and in the future....
Rightclick desktop, Properties, Appearance. As seen here (http://attachments.techguy.org/attachments/184623d1293351015/display-apperance.jpg). In Vista/7, it's rightclick desktop, Personalize.
Quote from: Jojo on September 19, 2011, 14:18:03
Rightclick desktop, Properties, Appearance. As seen here (http://attachments.techguy.org/attachments/184623d1293351015/display-apperance.jpg). In Vista/7, it's rightclick desktop, Appearance.
Actually, in windows 7/vista its different. You rightclick the desktop, choose personalize, Choose Window Color, then choose "advanced appearance settings" to get to the same dialog.
Well ok, then it's "Personalize" in english installations, not "Appearance". Still, all you have to do is to scroll down in the preview list to the "Ease of access themes".
Thanks to the big help of Rakib and jmkz, a large amount of articles has already been copied over to the new wiki. Thanks a lot for that! PDF export still has various issues, most of them appear to be problems with the render library. I hope they can be resolved at some point. :\
Ehm... in OHM source docs there's a glossary. I'd get integrated into wiki, but there's two choices. One is add each term as single page, and the other add as first one but like "Glossary:_YourTermHere" and a special page called Glossary and all terms listed in it like this (http://wiki.openmpt.org/index.php?title=Special%3APrefixIndex&prefix=Manual%3A&namespace=0).
What do you think?
I don't think that there's a need for glossary. Afterall, the wiki is searchable (and has categories in which all articles are sorted in), and the PDF version has an index, which can be used for quickly browsing the manual - and of course every PDF viewer has search functionality.
I actually think it would be nice with a glossary, this wiki is not only about modplug tracker but music generally. It has so many terms that could be handy for anyone that wants a 101 course in music theory.
Quote from: Jojo on October 15, 2011, 17:44:42
I don't think that there's a need for glossary. Afterall, the wiki is searchable (and has categories in which all articles are sorted in), and the PDF version has an index, which can be used for quickly browsing the manual - and of course every PDF viewer has search functionality.
I mean for something like this (http://wiki.openmpt.org/Active_row) (and so on), not a
glossary at all, make terms searchable through wiki.
Quote from: Rakib on October 16, 2011, 13:03:01
I actually think it would be nice with a glossary, this wiki is not only about modplug tracker but music generally. It has so many terms that could be handy for anyone that wants a 101 course in music theory.
Yes!, I agree too, for example, newcomers are not familiar with how it behaves OpenMPT with their objects, and even music theory were important. I think it would be useful for mostly these people.
Uhm, you know that the terms are already searchable if they are simply mentioned in an article, yes? So as long as for example the article about the pattern editor mentions the term "active row" in some way, it will appear in the search results if someone searches for that term.
The reason i created the Glossary in the first place was because i wanted a new user who had no musical or tracking experience (but had the drive to learn) to quickly find the definitions for words that he may not be too sure of. I decided to make it a separate PDF so that he could go right to that instead of navigating to a new place in the OHM (which meant he would have to navigate back to where he was reading, and he may have lost his page). What i eventually wanted to do was make any one of these glossarized terms linked so he could go to it, find out what he needed to know, then choose the "Back" button or shortcut and go right back to his starting point.
Ideally any term that we want glossarized for new users, i would want those terms colored differently and hoverable, so that if a user moves his mouse over the term, after a second or two, the definition would pop up in something like a tooltip. That way he doesn't have to navigate anywhere else. On the other hand if a user doesn't need to know the definition or need any clarification, the text coloring does not distract from his reading and if he's the kind that moves the mouse cursor over the line he's reading the tooltip doesn't pop up immediately. This i was hoping was one of the advantages of HTML...
I agree with you Harbinger, if anybody know how to do this in html please show us how.
That's what HTML elements like <abbr> (abbreviation), <dfn> (definition), <acronym> etc. are for. For example <abbr title="et cetera">etc.</abbr> - however, I doubt that any of those are exported to PDF with the PDF generator I'm using, let alone with a hover tooltip.
Forget the PDF version for this effect. I wanted to see this for the online help pages... :D
Quote from: Harbinger on October 17, 2011, 19:56:02
The reason i created the Glossary in the first place was because i wanted a new user who had no musical or tracking experience (but had the drive to learn) to quickly find the definitions for words that he may not be too sure of. [...]
That's exactly what it's needed and wanted to, an all-in-one wiki for anyone 8)
Well I don't want to disappoint you, but the "all for really everyone" approach doesn't work. Putting all knowledge about music production, sound theory, whatever, no matter how well categorized / etc. it is, is pointless. With a all-in-one website, you confuse people more than helping them, so there must be clear restrictions of what goes into the wiki and what not.
There are already more than enough audio related wikis (which I have no problem linking to), and there is google, so if someone goes "WTF is an Tape Loop", there is no need to explain this on the wiki, other than in a subordinate clause of the original text where this is mentioned.
I just mean that anything applicable to OpenMPT should be (at some point) on the wiki.
As long as i am using MPT, i will maintain my own OHM/CHM for the current version, but i will probably always be behind the most recent build of MPT by a few months or even a year, and i will not update unless there are big changes or additional features (such as those coming up in 1.20). I imagine Jojo or someone else will keep the Wiki pages more up-to-date, but he will apply his own filter of what should be included there. The details of MPT (which i call the MPT Reference) will usually not be found in the Wiki version, as this is for quick reference of MPT's usage rather than detailed info on such esoterica as the dialogs, the minutiae of plugin workings, the menu descriptions, etc. As the devs continue to improve or fix MPT, they will generally probably not include all the details of their improvements in the Wiki (altho you'll be able to see what they've done in the version log).
But i agree -- i want to maintain a record of practically anything having to do with MPT, which was my whole purpose in creating the OHM. I want new users to be able to jump right in, intermediate users to figure why they can't get done what they want done, and veteran trackers to understand exactly what's going on with MPT as they try to stretch the limits of its features.
So, it may not find its way to the Wiki, but i will try to maintain it in my OHM or Reference PDF. Of course, as Jojo says, some questions to new users may be too broad to be made "MPT-specific" and should be left to the new user to go find out at other web pages...
Whats the link to find all the todos again?
It's in the first paragraph on the main page.
http://wiki.openmpt.org/Main_Page
It is up now!
Yep, and I'd like to emphasize that the pattern editor help is still rather sparse; it will probably stay like that for the OpenMPT 1.20, depending on when I (and anyone else willing to help) will find time to copy over texts from the OHM or write up completely new texts.