Note: This version of the manual has been superseded (http://forum.openmpt.org/index.php?topic=4387.0).Thanks to
uncloned and
Jojo for hosting this download. They have both provided a stable site for uploading/downloading files for ModPlug and music, and i for one thank them for their contributions.
Now for the news...
OpenMPT Offline Help Manual 1.00 (http://clones.soonlabel.com/public/modplug-manual/MPTOHM1_0.rar) for MPT 1.18.02: Site 1
(Download size = 13.8 MB)
This release is 99% error-free, and includes all corrections and many of the suggestions offered by MPT users. There is a "beginner's" section (though veterans of MPT might find some nuggets of info or friendly reminders), a full Reference Section which details all of ModPlug's elements and functions, appendices ripe with lists of important go-to data, a glossary for new track composers, and a full index.
Here is a more detailed description of changes since the .85 beta OHM:
Pagination: Every page numbered. (When submitting posts about corrections, pls include the page number...)
Corrections/clarifications: Added small changes in wording throughout the manual.
Text: the overall readability has been augmented by increasing the line spacing, justifying the text, and reducing hyphenation -- except for the list paragraphs, and the Reference section excluding the Audio Reference. The idea is that the first section of the OHM should read like a schoolbook, while the Reference section should be more encyclopediac in structure. The FX commands list in Appendix A was also reworked for visual ease, and throughout the manual Channel FX commands were given the same font as the Appendix. All of these changes alone increased the page count by about 10%.
General Options: Altho i did not write up a section devoted entirely to the General Options ("miscellaneous" settings in the General tab of the Setup Options), throughout the manual i have mentioned them in relation to their subjects. For example, "Always Center Active Row" is mentioned in the paragraph on playback highlighting.
Tempo & Speed: Modes are now table-ized in a more compact form.
Instrument Import: After testing, i included a brief mention of importing SoundFont banks.
Instrument Panning: Included a mention of the concept of "pan swing" as it relates to Random Variations and Pitch-Pan.
Instrument Advanced Attributes: Included brief mention of resampling.
Folder Tree; Chapter inserted after Instruments but before Patterns, with info on the functionality of the Folder Tree.
Pattern - Order List: Included mention of contextual menu which can be used to assign patterns in the Order List.
Pattern - Note Events: Moved details of Note Stops to the Reference section on Channel Processing. The remaining table should suffice for beginners.
Sequences: Included mention of same song concept that Jojo brought up. Also mentioned limitations of playback vs. sequences.
Compatibility Export: Added a list of hacks that are not included in a Compat Export. These were verified by Jojo, who understands the code far better than i.
Known Issues: Added list of issues that MPT has with plugins or apps. Gleaned from my own experience as well as the Bug Report section of the forums.
Contributors: Special thanks given.
Reference: Added effect commands that can modify certain parameters (such as NNA control) in their respective paragraphs.
Reference - Samples Page: Reorganized and corrected, as GUI has been modified. Auto Vibrato also tested and written up, and corrected thanks to Jojo -- altho i found it didn't work QUITE as he suggested :wink:...
Reference - Instruments Page: Tested and wrote up Pitch-Tempo Lock. Wrote up subsection on the Status Bar for this page.
Reference - Soundcard Options: Researched and wrote up the settings for Resampling, including the waveform Finite Impulse Response algorithms. I will forget all this information as soon as possible (!).
Reference - Song Properties: Completed descriptions of the settings. Transferred the description of the IT "Old Effects" to the IT FX list in the appendix.
Reference - MIDI Map: Completed and moved for better page layout.
Reference - Keyboard Split: Included graphic for understanding how it works.
Reference - Other Contextual Menus: Added the complete list of contextual menu items from the Folder Tree.
Reference - Audio & MIDI: Finished the knowledge base of audio and MIDI as it relates to MPT. Heavy, some math, but very concise and pertinent info that i think will add to the not-quite-a-newbie user's knowledge for manipulating sound with ModPlug. Lots of research went into this....
Glossary: A decent list of terms that may come up for the reader, in which he may not be clear on, or in which distinctions have gone unspecified (such as "plugins" vs. "VSTs").
Appendix - FX commands: Corrections and updates made.
Index: A complete index of all subjects in the OHM. Regrettably, creating a hyperlinked index would take weeks more, and it will be very difficult when changes had to be made in the future. OpenOffice Writer has a nifty way of indexing in the structure i like, but there is no way to hyperlink the page numbers except MANUALLY linking every one of them. And when i would modify the index later, the hyperlinks would not be retained. So for now the PDF file will not have a linked index.
Table of Contents: I thought about a linked ToC, which can be more easily done with OpenOffice, but it would be rather superfluous (more work for little gain). As far as functionality, a good index beats a ToC -- all a ToC does is prepare the reader with an outline of what he's about to read; he wouldn't use it to look for detailed info. For now i will opt out on that for this release.
Printable PagesHere is a list of page ranges in case you'd like to print up only certain information from the OHM .pdf file to keep on the side as a handy reference. Remember this only applies to the OHM 1.0 -- future editions may change these pages.
Channel FX (IT/MPTM)..........140-146
Channel FX (MOD)....................130-132
Channel FX (S3M)....................137-140
Channel FX (XM).....................133-136
Clipboard (copy & paste), Reference 105-106
Compatibility Mode tables...........
Envelope Loop table.................23
General page, Reference.............60-63
Hexadecimal, interpreting...........1
Index...............................159-168
Instruments page, Reference.........73-77
Keyboard shortcuts, definitions.....151-158
Macros, Reference...................95-96
Macros, using.......................36-41
MIDI CC#s, standard.................149-150
MIDI Input, enabling................128
MIDI Output, enabling...............129
Note FX.............................148
Note Stop descriptions..............122-123
Note Stop table.....................31
Order List, using...................28-29
Pattern page, Reference.............64-65
Samples page, Reference.............69-72
Tempo Modes.........................11
Tunings, Reference..................92-93
Tunings, using......................54-56
VSTs (plugins)......................49-53Releasing your own version of the OHMOver at the ModPlug page at sourceforge.net, the source files for the OHM can be found here (https://downloads.sourceforge.net/project/modplug/OpenMPT%20Offline%20Help%20Manual/MPTOHM%20Source%20Docs.rar?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fmodplug%2Ffiles%2F&ts=1285101671&use_mirror=freefr). Included in the source archive file (at the link above) are the original OpenOffice document (.odt), the Master File and its subdocuments, images used (most in .jpg format), and other files related to my research for this manual (usually encapsulated html files). If you have no use for anything other than the PDF, you can delete all the other files. I have not attempted to save the file in any format except the one in which i worked. If you don't have OpenOffice and need to access the .odt, you can download the full package at openoffice.org. It is free (it's the open-source version of Microsoft Office) but it's a hefty download.
Undoubtedly some of you may wish to translate the OHM, convert to another format, or just simply present it a different way. YOU ARE FREE TO DO SO -- this manual and all files in the archive file at the link above is open to the public to do with whatever they wish. However, i ask that, if you make changes to your copy of the archive, you rename it so as not to confuse either Googlers or future users of MPT. Also, when uploading changes to the source, DO NOT DELETE THE
SOURCE IMAGES. You may, however, update them for your own version in case of chages to the GUI or if you have a better graphic to clarify the concept even more.
For the devs and admin, any changes to MPT should be recorded in the SUBDOCS of the master file (not my completed version), and of course these changes should be included in the changelog for MPT as well, so authors of other versions of the OHM can easily keep up with updates and new features. When the OHM is updated for a coinciding release of a new MPT build, change the first line of the first subdoc to the current build version (e.g. 1.18.10 or whatever), then save the master document (OHM Master.odm) as a .pdf or .html.Which brings us to alternate versions of the OHM. I'm sure no one in these forums minds if you release your own version, but let us agree to a naming format so everyone knows which does what.
>>When providing a link to your own version of the OHM, title the file something distinctive and perhaps a bit "proprietary", such as "MPT OHM - Rakib v1.1" or "Uncloned OHM 1.2b - Professional Edition".
>>If it's a translation, make that clear also in the file name: "MPTOHM 1.0 (Espanol)" or "MPTOHM_Deutsch_jojo_v1.5" or the like.
>>If you are converting it to another format, changing the extension isn't enough. Use "ModPlug_HELPFILE_1.18" or "OHM_WindowsCHM."[/list]
The object is to differentiate other versions from the "original", "official" PDF, and if possible, to help googlers or users know what they're downloading.
I would also like to ask that if you make your release available, make it AS EASY AS POSSIBLE to download. Avoid DL sites where you have to register or which are not trustworthy (y'know, like FILEPLANET!).
For now, this brings to an end a 2-year-long project. I intend to keep up with corrections and updates, just not as often. I have devoted hundreds of hours (and fortunately no money) to its writing, and i hope it helps for years to come. I think i can see that the help manual, even the beta versions, has helped to attract a few young (or at least new) trackers to ModPlug. This was the goal -- to make using MPT as easy as possible to learn. I had about 2 years between finding MPT, and composing good tracks with it. That's WAY too long. Hopefully this manual will shorten that learning time for new composers.
I intend, however, for there to be an OHM 2.0 several months down the road, which will include:
1. A Quick-Start section, for those who'd rather not read before trying it out!! :D
2. A fully LINKED index (somehow!).
3. Addenda on using some of the more complex plugins with MPT (still waiting on those write-ups!).
4. Hopefully many new features that our devs have introduced.
5. Sound examples for Channel FX.
You are still free to critique this edition, but if it's really nitpicky, you might wanna do your own release of the OHM. Correctional observations are always welcome, as is praise i guess (altho i wonder how much that accomplishes! :LOL:).
Now to get back to writing MUSIC!
Stickied and unstickied. :)
Thanks LP!
As a reminder to everyone, corrections should be requested in this thread. If i or someone else makes the correction (or any we find), we'll let you know in the FIRST post, and update the link when necessary... 8)
Wow! What a great work, have really seen that you have put on a great work to make this manual. And it turned out really great. Im impressed by the result.
My question is, is there any plans to include this help file in the official Modplug package? It sure would help many new (and old) users.
One error that I've found is that OpenMPT is now licensed under BSD and not GNU.
And when It's out I very much would like to improve the help file.
I have found another error (page 125, Frequency Rate Calculation)
[...] the actual pitch may be 440 Hz (A-5)[...]
That would be A-4
I'd never dare to call OpenMPT "99% bug-free" and the same applies to any other program or documentation as well, including yours. ;) There are still some major and minor errors which need to be fixed.
And for the sake of making the manual look professional and for preserving it for a long time, some person could convert it to TeX.
Impressive work and the first ever(?) more or complete English OpenMPT manual. Yes there are many things that need improvements in the OpenMPT documentation as whole, but hopefully this acts as a stepping stone for further improvements.
Here's some notes found on quick look:
Page 57, "When using portamento commands when...."
Incorrect. Portamentos are tick-based also when using custom tuning.
Page 96, section 5: Tuning type:
"Group Geometric: (not functional)"
Where does that come from? As far I see it works as planned; it's a different question how useful it is.
Page 96, section 8: Finetune steps:
"If this value is 0, it will use MPT's default algorithm for determining portamento."
Incorrect. If value is zero, then there's no finesteps between notes and one portamento step while increase note by one. In general: to change one whole note, there has to be (finesteps + 1) portamento steps.
Page 97, section 2: Capture
"2. Capture: Checking this box allows you to enter the MIDI controller automatically by physically manipulating it"
I don't understand what that means. What capture does is that it prevents the MIDI event from being forwarded to the further MIDI mapping directives(if any). For example if there are three directives mapped to single MIDI event and the first one(highest in the list) of these has capture enabled, the two others won't get the MIDI event.
Page 97, section 3: Pattern record
"3. Pattern record: Checking this box allows you to enter the plugin controller automatically by manipulating its GUI item with the mouse."
Incorrect. Pattern record causes the MIDI mapping directive to write the corresponding action to pattern as PC notes (given that pattern record is enabled in pattern tab).
Page 97, section 9: MIDI message
"A non-editable field probably interesting only to programmers and MIDI experts. It shows the message that is sent to the plugin to be controlled."
Not really the message sent; just a string representation of the settings aimed to give quick overview of the directive.
Page 3:
"A Windows-compatible, 32-bit computer, the newer the better" - OpenMPT works on 64-bit machines as well, it's just a 32-bit application. As far as I know, it also runs on Win95.
"You are also prompted if you wish to keep the previous settings you had saved with the older version of MPT." - Not sur who told you that, but it's wrong.
"NOTE: As with all open-source software" -
as if that was only the case with OSS! Note that the installer automatically backs up all settings when upgrading.
Page 6:
I'm still not content with your description of the buffer length. Especially since you try describe how good DirectSound is, however since DirectSound is only emulated in Windows Vista/7, meaning that hardware-accelerated DirectSound is not possible anymore without using special drivers. It doesn't really matter if you choose WaveOut or DirectSound on a Vista/7 system. I'm not even sure if WaveOut would be better.
Generally, I'd try to rewrite this as follows:
- The lower the buffer size (latency), the better
- However, not all systems can cope with low buffer sizes
- If available, choose a low-latency ASIO driver. This also gives much better visual/audio synchronization
- If not, choose DirectSound or WaveOut.
- DirectSound might be the better choice especially on old systems, while it doesn't make much of a difference on more recent systems.
Same goes for the polyphony description. You're talking about "high-end" and "low-end", and again I can say: A gamer with the latest hardware will most definitely consider my laptop as "low-end", however it can handle 256 channels of polyphony.
Page 12/13: somehow doubles the reference on the sample tab. I'd remove the redundant information, especially since it's incomplete and the chance is high that this will get even more incomplete with future versions of OpenMPT.
Page 14: Typo. "mutlisample"
Page 22: "The Release Node is available only to IT and IT-type tracks" is not true anymore for OpenMPT 1.18.03. The release node is only available in MPTM.
Page 29: Concerning the picture, I have got only one thing to say (http://hyperkind808.files.wordpress.com/2010/07/340x_no_comic_sans_please_thumb.jpg?w=369&h=473). Same goes for "Pump Demi" or "Bauhaus 93" or whatever the font on page 61 is called on your computer. (Generally I'd say you're too many type faces and bullets icons anyway).
Page 48: "With MPT, you can use up to 32 tracks (the default is 8)" - Wrong. The default is 4.
Page 49: "MPT may be able to translate the data into a track format, but it will only use General MIDI Instrument 00 (Piano) as its sole sound source" - Wrong. You can specify the instrument by either using the MIDI export dialog or by specifying the correct bank/patch parameters in the instrument editor.
Page 50: I'd like to generally exclude MOD and S3M from the VST stuff. Yes, it cannot be loaded, but who cares about the usage then? Simply mention it once at the beginning of the chapter or so that MOD and S3M don't support plugins.
Page 71: I wonder if a more complicated definition of "convert sample sign" can be found, and if it's correct at all. I'd simply say it "treats the sample data as signed or unsigned data", much like in the RAW import dialog.
Page 103: " This option converts the track to IT format and resets all settings to the IT default. This is useful for updating older modules for editing." - Given that it resets default tempo, speed and other things: No, it doesnt help with updating older modules. However, it does help if you want to write a new module based on the samples of an older module.
Page 105: "Negative numbers do not have any effect." - Wrong. The sample and pitch envelopes (when not in filter mode) can be inverted by using negative amplification.
Page 107: " There seems to be an unlimited number of Undo's but it is based on available RAM." - There are 100 pattern undo steps and 100 undo steps for each sample.
Page 123: Again, a wrong description of sign conversion. If an unsigned sample would only fill the upper half of the editor, it would be a 7-bit sample. A signed sample is saved as a 2's-complement number, an unsigned sample simply as a binary number. But I don't think the reader should be bored with technical details which a programmer is supposed to know.
QuoteMy question is, is there any plans to include this help file in the official Modplug package? It sure would help many new (and old) users.
In its current state not at least. It's far too big, however that can "easily" be fixed by exchanging all WinXP Luna screenshots by screenshots using the Win2k theme and saving them in PNG instead of JPEG. Yes, it's multiple times smaller and looks 100 times better.
Page 86: Description of "apply octave transpose" is misleading. All it does is applying MPT's octave transpose the same it's apply for entering notes via the computer keyboard, i.e. if base octave is set to 3, all notes are transposed down by an octave.
Page 88: Description of when to apply "Fast Volume Slides" is also misleading. Simply go for something like "When enabled, volume slides will work like in early versions of Scream Tracker. Normally you would not want to enable this. It's automatically set for old files which need it." - The "unless you are updating an older S3M track" part is very wrong, because doing so would break the tune.
Again, you tried to add too many details in the sentence "For MODs assembled with ProTracker 1.0 - 1.9" - why didn't you just write "ProTracker 1.x" like the flag says? ProTracker 1.9 does not exist. And even worse: "this box will already be checked, but you can also enable it" - there is absolutely no way to determine whether a MOD was made with ProTracker or not, and it's not possible to determine the version of PT used as well. This flag is never set automatically, and can only be enabled by the user, if wanted.
Page 120: MOD/XM don't have channel volume, so "using Cxx for MOD tracks, plus Axy for XM tracks" is wrong. Also, I wonder about the separation here, because MOD also has the Axy command.
Page 124: " but is different in that Tremolo acts upon the sample output,
while Tremor acts upon the channel output." where did you get that from? both commands modify the sample output.
"Tremor is also controlled in a different way than Tremolo" - well duh, it's two different effects, so obviously they are controlled differently. :) A slightly more informative description would be that Tremor rapidly toggles the sample volume.
Page 152: Talking of "continued notes" is a bit confusing, I think, especially since it might be confused with the NNA action "Continue". "Background notes" might be a better term.
Talking of a "third envelope" is also a bad idea, since there's natural way to order envelopes. But since the S7D/S7E description is wrong anyway, here's a new one:
S7D - "Enables the pitch envelope and forces it to be treated as pitch control"
S7E - "Enables the pitch envelope and forces it to be treated as cutoff control"
Page 153: "Plugin designations go from 01-00 (100)." as said before, 100 is not displayed as "00" or anything else weird, but simply "100". Yes, it can be that simple. :)
Page 154: The velocity command does not exist anymore.
Thanks to everybody for the eagle eyes! I will save this page and make corrections in the next version, soon to be released both at the sourceforge site and as a PDF.
Thanks also for all of your praise and support too. Now that i'm practically finished, there's a void left. Fortunately i've been helping Tassel of Blue out with her music and she's about to release her 4th album, so i'm not left bored.
Remember, if you ever spot any corrections that need to be made for this document, don't hesitate to bring it to my attention in this thread...
SPECIFIC COMMENTS:
Quote from: "Jojo"I'd never dare to call OpenMPT "99% bug-free" and the same applies to any other program or documentation as well, including yours.
:lol: True enough!! Altho 18.03 is rather stable, when i first started writing this manual, i RARELY had any problems with "normal" use -- sample-based tracks mostly in the IT format. I will use a different wording, and try not to be such a shill! :P
Quote from: "Jojo"Page 29: Concerning the picture, I have got only one thing to say. Same goes for "Pump Demi" or "Bauhaus 93" or whatever the font on page 61 is called on your computer. (Generally I'd say you're too many type faces and bullets icons anyway).
Frankly, for me, it's still too boring. I wanted to make the "visuality" of the text interesting, and not so rigid. You are free to industrialize your version when the docs are made available...
:wink:
Quote from: "Relabsoluness""Group Geometric: (not functional)"
Where does that come from? As far I see it works as planned; it's a different question how useful it is.
Then you'll have to let us know what it does and how to use it. When i initially wrote the post on Tunings (before the OHM was started), i could not get this to work, and didn't seem to be any different than "Geometric". BTW, if you could, can you post your reply to this in the old Tuning post i wrote (so the info for online searchers stays in one place)?
And also Relabs, thanks for your help on the MIDI Mapping dialog. There was no documentation on it, and i couldn't access my MIDI keyboard (when i had it), so i was making educated guesses at all that.
QuoteNow that i'm practically finished, there's a void left.
Well, there's always plenty of stuff to be done, be it finding errors in the text or keeping the manual up-to-date. It's not like the developers do have to do all of this just because they know their code - we seriously have better things to do than reading the manual all night long. :)
Quote
Frankly, for me, it's still too boring. I wanted to make the "visuality" of the text interesting, and not so rigid. You are free to industrialize your version when the docs are made available...
You call it industrialized, I call it professional. :)
Quote from: "Jojo"You call it industrialized, I call it professional.
I've seen very technical "professional" manuals with a very eye-catching approach to its text and syntax.
Yeah, but overused fonts like really Pump Demi don't contribute to that... A professional manual does not have to look boring, but it also shouldn't look like something I've pulled of in Photo Impact five years ago.
Quote from: "Harbinger"Then you'll have to let us know what it does and how to use it. When i initially wrote the post on Tunings (before the OHM was started), i could not get this to work, and didn't seem to be any different than "Geometric". BTW, if you could, can you post your reply to this in the old Tuning post i wrote (so the info for online searchers stays in one place)?
In groupgeometric, ratios in range [0, group size - 1] are independent ratios and all others are determined by the following relation:
for all i, ratioAt(i + groupSize) / ratioAt(i) == groupratio.
To see example of groupgeometric, see "debug crab" in the the compo entries (http://forum.openmpt.org/index.php?topic=3041.0&) (search for "Get the votepack here!").
Quote from: "Jojo"Page 3: ...
"You are also prompted if you wish to keep the previous settings you had saved with the older
version of MPT."
Not sur who told you that, but it's wrong.
This came from you. I quote:
Quote from: "history.txt"Installer/release package
[Imp] <Jojo> User is asked if they want to keep personal settings.
And there was nothing in the 18.03 notes to say it had been revised.
I don't just make this stuff up.:)
Quote from: "Jojo"Page 50: I'd like to generally exclude MOD and S3M from the VST stuff. Yes, it cannot be loaded, but who cares about the usage then? Simply mention it once at the beginning of the chapter or so that MOD and S3M don't support plugins.
I thought about simply excluding these references, but a MOD track with a plugin can serve a purpose: since MPT has the ability to Render by Channel or Pattern, a MOD composer can use plugins to create his own VST-altered samples. This info should stay....
Quote from: "Jojo"Page 71: I wonder if a more complicated definition of "convert sample sign" can be found, and if it's correct at all. I'd simply say it "treats the sample data as signed or unsigned data", much like in the RAW import dialog.
There is a more complicated definition -- yours. You have a terrible habit of assuming users know what you know, or understand something just because of the terms used. It took me forever to understand WHAT an unsigned sample was, HOW it could be used, and WHY someone would want a sample unsigned. After looking at the waveform of one (in which all of the values occupied the upper half of the Sample Display), i got it. Now i need to help others without "high-end" computer knowledge understand it. With that said, you may have misunderstood MY definition because i left out an important number; it should now read, "Subtracts
128 from each sample point, which shifts the waveform to the opposite phase, but without inverting it, which is necessary for .raw samples." Perhaps you'd like me to define "phase" for the young ones?
Quote from: "Jojo"Page 123: Again, a wrong description of sign conversion. If an unsigned sample would only fill the upper half of the editor, it would be a 7-bit sample. A signed sample is saved as a 2's-complement number, an unsigned sample simply as a binary number. But I don't think the reader should be bored with technical details which a programmer is supposed to know.
That may be true of a
sample (a point in a waveform), but it is not true of the whole waveform. I did some tests with unsigned waveforms, determined what was being done, and wrote it in such a way that users who know nothing about unsigned waveforms can understand. Fortunately, i understand what you mean by two's-complement binary number, but i can't throw that term around in a manual designed for trackers. It has to be explained in a way that can be backed up visually. Perhaps i need pix to help...
Quote from: "Jojo"Page 86: Description of "apply octave transpose" is misleading. All it does is applying MPT's octave transpose the same it's apply for entering notes via the computer keyboard, i.e. if base octave is set to 3, all notes are transposed down by an octave.
Your explanation was even more confusing. But i did clarify a little better...
Quote from: "Jojo"you tried to add too many details in the sentence "For MODs assembled with ProTracker 1.0 - 1.9" - why didn't you just write "ProTracker 1.x" like the flag says? ProTracker 1.9 does not exist. And even worse: "this box will already be checked, but you can also enable it" - there is absolutely no way to determine whether a MOD was made with ProTracker or not, and it's not possible to determine the version of PT used as well. This flag is never set automatically, and can only be enabled by the user, if wanted.
That was no affirmation that 1.9 existed, but rather that any ProTracker version that fell within this range was the subject. Nitpicky, Jojo. Plus, i wrote the OHM as if English is not the best language of the MPT user; "1.x" can be confusing if you didn't pass or never took algebra.
Concerning the automatic setting of ProTracker MODs: since i don't work with MODs of any kind, i assumed that MPT could tell, in the same way other module flags are read, that an opened MOD was a ProTracker 1 MOD. Perhaps when you made this feature available, you could have mentioned the fact that MODs are not saved with this flag.
Quote from: "Jojo"Page 152: Talking of "continued notes" is a bit confusing, I think, especially since it might be confused with the NNA action "Continue". "Background notes" might be a better term.
I can agree on your opinion of the term "continued notes," but "background notes" is even more confusing. Another term should be sought, perhaps "trailing notes" or "fading notes".
Quote from: "Jojo"Talking of a "third envelope" is also a bad idea, since there's [no] natural way to order envelopes. But since the S7D/S7E description is wrong anyway, here's a new one:
S7D - "Enables the pitch envelope and forces it to be treated as pitch control"
S7E - "Enables the pitch envelope and forces it to be treated as cutoff control"
Well it's not a pitch envelope if it can used for filtering, now is it? It's best to keep referring to it as an ancillary, as-needed envelope, so i will continue to refer to it as the 3rd envelope, but taking your point into consideration, i will properly quantify it in other paragraphs discussing the envelope usage.
All other points are valid and have been adjusted for the source release docs.
Quote from: "Harbinger"This came from you. I quote:
Quote from: "history.txt"Installer/release package
[Imp] <Jojo> User is asked if they want to keep personal settings.
And there was nothing in the 18.03 notes to say it had been revised.
Right, the changelog for 1.18.02.00 was wasn't put together very well. This concerns the uninstaller, not the installer.
QuoteYou have a terrible habit of assuming users know what you know
No need to tell me, I know that! :nuts: And yes, I love nitpicking.
QuotePerhaps when you made this feature available, you could have mentioned the fact that MODs are not saved with this flag.
Well, it's the kind of expert feature that users who need it know how to use; the rest (probably 99%) can safely ignore it. PT1.x modules are relatively rare and play well enough with this flag disabled most of the time.
Quote"fading notes"
not much better than "continued" IMO since a background note is not necessarily fading at all. Maybe "old notes" would be the most understandable and illustrative one?
Quote
Well it's not a pitch envelope if it can used for filtering, now is it? It's best to keep referring to it as an ancillary, as-needed envelope, so i will continue to refer to it as the 3rd envelope, but taking your point into consideration, i will properly quantify it in other paragraphs discussing the envelope usage.
How about "Pitch/Filter Envelope" then? That's even what the tooltip for this envelope says, and it's probably the best name for it.
If a person does not know the difference between unsigned and signed samples, I think is actually no textual description that can really make them grasp the meaning. Hopefully those two pictures help to remove all uncertaincies:
Sample as a signed waveform(http://sagagames.de/ithumb/show/signed16085vf18.png)
Sample as an unsigned waveform(http://sagagames.de/ithumb/show/unsigned18516xs75.png)
Good pix. I think what's not clear is that the MPT's horizon line no longer represents 0 in an unsigned waveform..
I believe i have stumbled across another problem with uploading the source docs for the OHM at sourceforge. All the images used by the subdocuments are linked -- not embedded. This makes it easy to update images or upgrade them to better quality without affecting the text body.
The problem is, these links in the OOo files seem to be absolute-addressed, not relative-addressed. What this means is that when i upload the files, the images are going to be looking for MY C drive! I have tried changing their links to relative addresses ("/OHM images/image.jpg"), but when i check back they've reverted to absolute addresses again.
I have also brought an example to the library and tried the load the page with images; it's definitely NOT keeping the relative addresses. We got a problem...
I don't want to go back thru and reset the links AFTER they've been uploaded; that will take a LONG time. But i need to keep them linked, especially if users wish to create an HTML or .HLP file from them.
Any ideas? (For now i will mosey on over to OpenOffice.org to see if they have any workarounds..)
Quote from: "Harbinger"Good pix. I think what's not clear is that the MPT's horizon line no longer represents 0 in an unsigned waveform..
Well, it does, because technically OpenMPT only "knows" signed waveforms. :)
About the document issues, I'm still all in for copying all the text over to a (new) wiki. There are several ways to generate PDF documents (http://www.mediawiki.org/wiki/Extension:Pdf_Book) from single wiki pages as well as whole categories, so an "offline manual" could be generated automatically. And we wouldn't have all those issues with the pictures...
Another thing which I have thinking about is that we could just add a quickstart guide to the openmpt package which only consists of the most important chapters of the manual (f.e. the stuff about how sampling works and such could be left out). That way, the openmpt distribution would not be bloated too much, and the interested users could still download the full document if they want the other chapters.
I agree about the Quick Start guide. After compiling all that i knew and all that could be done with MPT, this is quite a heavy read! I have also considered putting together a Quick Start guide, which i think would be helpful, but i'm kinda burned out of technical writing right now...
I consider a Wiki version an offshoot of the source docs. I want to be able to make the source docs as easy to modify, build, or update as possible, at least as well as the source code for MPT. All versions should stem from the source text. Myself, i'm not too keen on Wiki's format nor its "look". And i'd like a slightly bit more control (that is, veto power) by devs.
And i want to sort this out before i hand over the source docs. I don't want to log in one day, even if i'd been gone for 6 mos., and find the spirit of the source docs bastardized -- at least in the original files. The docs should be editable by anyone, with edits vetoed by the current devs if the edits are not helpful or educational. Of course, anyone should be able to take the original docs, and do whatever they want to them for their own build. (The only they can't do is take credit for the source manual.)
After checking over at openoffice.org, they say that relative links are saved just not shown, but when i open the doc in this computer (which is not my home computer) even with all the images sources in the same folder level, none of the images show up.
Quote from: "Harbinger"I consider a Wiki version an offshoot of the source docs. I want to be able to make the source docs as easy to modify, build, or update as possible, at least as well as the source code for MPT. All versions should stem from the source text. Myself, i'm not too keen on Wiki's format nor its "look". And i'd like a slightly bit more control (that is, veto power) by devs.
Sorry, but I have to disagree on all points here.
- You want the manual source to be easily editable and to be open to everyone. That's partically the principle of a wiki. Everyone can contribute, so the wiki is even "more open" than the sourcecode, where patches first have to be approved by one of the main devs.
- Using aforementioned extensions to MediaWiki, it's probably a matter of seconds to update/build the offline manual.
- You want control by project admins. That's given since pages can be locked to be editable only by certain user groups, and changes can be reverted easily by us if we feel that something's wrong. There are extensions which provide sighting for articles (this is used on the German Wikipedia for example), but I am not to keen on that. I don't really expect any vandalism, apart from spam bots maybe (but that only happened once and then never again to the German OpenMPT wiki, and it's running for about two years already). It's not like we have to expect a huge user base editing the wiki, so keeping an eye on the edits should be fairly simple.
Working with wikis is great, because you never have to edit the whole document, and everyone can work on their own part at the same time. There's no problems with two people working on different articles at the same time, unlike when editing one single document file as you probably do it now. About the "look", well it can be customized but that's not really my goal. The German Wiki (http://sagamusix.de/openmpt/Hauptseite) is an almost unmodified MediaWiki (with some changes done to the background and logo and a custom extension to display+highlight patterns). If you don't like the look, you can still use the offline manual, which is not bound to the wiki's look - It's merely generated from the wiki articles.
Would Google docs be an option?
We were about to join all the scattered modplug resources into one page again, and then we should move out to Google Docs? No thanks. (Needless to say I'm also not a very big fan of WYSIWYG software).
Quote from: "Jojo"We were about to join all the scattered modplug resources into one page again, and then we should move out to Google Docs? No thanks. (Needless to say I'm also not a very big fan of WYSIWYG software).
Well it was just a thought, I thought it'd be a good compromise between what you and Harbinger desire.
Well, i must defer to you, Jojo, concerning these matters -- you know far more about capabilities and limitations of various "means" out there. As long as you understand what i'm looking for, then i'll let you figure out the best way to make these wishes happen (and yours too)...
I'll get back to you on the upload to sourceforge.... 8)
You can now download the OHM source here (https://downloads.sourceforge.net/project/modplug/OpenMPT%20Offline%20Help%20Manual/MPTOHM%20Source%20Docs.rar?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fmodplug%2Ffiles%2F&ts=1285101671&use_mirror=freefr) at Sourceforge. (This may change in the future, however; keep your eyes open here.) The DL size is almost 40MB and unpacks to a size of about 66MB.
The archive is in RAR format, and requires WinRAR 2.9 or above (or a program that can de-archive RAR 2.9 files). That application is shareware but completely usable. (edit by LPChip: 7-zip can also open .rar files and is completely free. There are more archivers that support the winrar fileformat too. A portable one could be peazip)
The document list of the original source is as follows (others may be added in the future by various devs):
OHM Master & Subdocs (folder): This contains the OpenOffice.org (OO) files that contain the source text; however, while the Master Document (which combines all the chapters into one build) is in OO's native format, the subdocuments are in Word 97 format, so each should be openable in WORD 97 and later. (They are also openable in WordPad, but you shouldn't edit in this format as they will not retain all of the layout settings.) The Glossary is also in this folder in OO's native format.
> MPT OHM Images (folder): Within the Subdocs folder are the images that are used in the chapters. MAKE SURE THIS STAYS IN THE ROOT LEVEL OF THE SUBDOCS. Otherwise the images may not appear (which may not be a problem if you only wish to edit the text). There may be a problem with the subdoc's link system -- see below for more info.
>> Image Sources (folder): Within the Images folder are some images that are composed of layers in either PSD format (Photoshop) or XCF (GIMP). If you are editing or updating the images, check with these and edit the layers so you don't have to re-create the images. (Not all of the document's graphics have layered counterparts in this folder.)
MPT Research (folder): Within this folder are the various sources of info (mostly third-party) i used to learn how everything worked in MPT. These are presented here for verification of the knowledge base that MPT relies on. I decided to put them together in the source release, so future editors/translators would not have to go looking all over the internet for the pertinent data. This folder contains subfolders and a variety of files that went into the making of the OHM, including my own test results.
MPT OHM 1.0 & Glossary (PDF): The original build of 1.00. This document is included to give editors and translators an idea of the intended layout. Of course, you are free to create your own layout, even making no changes to the graphics or text, but this file gives an idea of how the original OHM looked. (OHM Updates will be added to this sourceforge folder for download.)
Miscellaneous help files (TXT or RTF): The original source folder includes the following:
> A .txt file that describes how to fix your registry if your computer won't open extension-assigned files with MPT automatically,
> A .txt file that describes how to use "problematic" or complex VSTs with MPT (i've included notes for using Roland's "Orchestral" VSTi).
If you wish to make your own changes for inclusion into the trunk build, edit the individual subdoc and ask the devs for inclusion (unless of course you are a dev!). Also check the first post in this thread for more reminders on building your own version...
KNOWN ISSUE: There may be a major problem with viewing the graphics on your computer. All of the subdocs are LINKED to the images; they are not embedded like the PDF release. This is why you have to keep the Images folder in the same folder level as the subdocs. However, i could not set the links to be relative rather than absolute. This means that OpenOffice will expect to find the images from MY personal computer, not yours. I tried it with both WORD 97-2000 format (.doc) and OpenOffice 3.2.1 format (.odt), but neither would make the links relative. (If anyone has a way to fix this, please let us know...)
WORKAROUND: There are only two things you can do to get the images to show if they are not linking:
1. The easiest option -- create a set of folders on your own computer with this hierarchy, mimicking my computer:
"C:/Documents and Settings/Kelley/Documents/Text Files/MPTs Offline Help Manual/OHM Master & Subdocs"
and put the "MPT OHM Images" folder into the "OHM Master & Subdocs" subfolder. To make it easy to navigate to that folder if you should need to, put an alias of the Images folder into the folder where you are keeping the Subdocs (unless you want to just put all the subdocs into the "Master and Subdocs" folder)...
2. The worst option -- go thru EVERY image in EVERY subdocument and change the link to match that of your computer. Do this by double-clicking on the image to open the Picture dialog, click on the "Picture" tab, and edit the "File name" field. Count on about 4 hrs worth of work.
The reason we want to have the images linked rather than embedded is twofold. First, if changes need to be made in the future (and they undoubtedly will), you only have to change the image rather than the whole subdocument. Secondly, many of you might wish to transcribe the OHM into other file formats, like a Windows Help File or an HTML page. These formats use linked images as well, and make for much more easily buildable and editable documents.
With that said, you are free to build your own OHM from these documents and embed the graphics to alleviate the problems with linked graphics.
BTW, the documents are up-to-date for MPT 1.18.3, altho i have not built a PDF from it yet.
Note to devs: if you'd rather not have an archived source, you're welcome to disassemble the archive and put the files right there in the OHM folder at sourceforge. You may also delete any files you think are superfluous, the only ones i want to remain are the original .docs that make up the chapters and the graphics folder, so users can create their own versions easily.
Quote from: "Harbinger"The archive is in RAR format, and requires WinRAR 2.9 or above (or a program that can de-archive RAR 2.9 files). That application is shareware but completely usable.
7-zip is free software and compresses the file much better (~30mb in the .7z format).
Good that the sources are out now, that's a good start for transferring all the text to a wiki, as soon as more important things are done.
Good to know. I do like 7Zip better anyway, it's much more flexible with archiving and de-archiving. :)