User talk:Teimoso

Hello there, thanks for helping with improving the OpenMPT documentation. I quite like some of the changes you did. One idea to improve it even further would be to color-code the category column with colors that are similar to OpenMPT's default effect colors (e.g. yellow = pitch, etc.)

What I don't agree with is the term "module hack", this is neither official terminology, nor have I read it in the wild before. Maybe you ment to write "ModPlug hack"?

- Saga Musix (talk) 21:40, 28 September 2018 (CEST)

Thank you for your feedback! The color-coding doesn't sound like a bad idea; I'll try it out.

As for "module hack," now that you bring it up, I'm not sure where I got that term from. I'll replace it with "ModPlug hack."

-- Twomoso (talk) 23:34, 29 September 2018 (CEST)

I'm not sure how familiar you are with MediaWiki, but the best way to do the color-coding is probably via templates (e.g. {{eff-pitch|Tone Portamento}}) or custom HTML5 tags styled via CSS, but I am not sure if MediaWiki allows custom tags to be used easily. We use them in our pattern data formatter, but that does not go through the MediaWiki formatting.

Saga Musix (talk) 13:42, 30 September 2018 (CEST)

I just saw that you already did the changes, and they look very good. MediaWiki templates or custom HTML tags won't work here but we should at least not use inline CSS. I have added CSS classes to MediaWiki:Common.css which can be used like so: | class="eff-pitch" | Pitch

I would suggest to slightly rename some of the columns to be closer to the categories in OpenMPT. Right now you have "Misc" and "Pattern", but I would go for "Misc" and "Global". "Red" effects are "global" effects in OpenMPT. I have added eff-misc as a grey class for uncategorized effects.

Saga Musix (talk) 13:56, 30 September 2018 (CEST)

Thanks for adding the CSS classes for the effect reference. I updated the page to use them instead of the inline CSS.

I'm somewhat unsure how to handle the category naming. For now, I've changed "Pattern" and "Timing" to "Global (Pattern)" and "Global (Timing)".

I think the most obvious solution would be to name/color effects exactly as they appear in OpenMPT (with the uncolored effects labeled "Miscellaneous"), but some effects, like Arpeggio or Tremor, seem like they'd be easier to search for if they were under "Pitch" and "Volume" (respectively) instead of "Miscellaneous".

-- Twomoso (talk) 20:57, 30 September 2018 (CEST)

I don't think we need to be 100% consistent with the OpenMPT colors, which are not always 100% logical (the fact that sub-commands of Exx/Sxx cannot be colored differently for example). I think the current way these commands are represented is good. By the way, we have a new big OpenMPT release (1.28) coming up in a few weeks, do you think you would be able to finish your improvements until then so that they can be merged back into the manual? If you need any help, let me know. Saga Musix (talk) 11:17, 1 October 2018 (CEST)

I forgot about 1.28; I assume it will be pushed out somewhere in the week of October 14 - 20?

I should be able to get the page ready by the 14th, but I'm a little hesitant to make any promises. Since the S3M section is almost done, though, the IT and MPTM sections shouldn't take too long. Feel free to correct anything on the page that you think needs fixing.

I do have one last question (at least for the moment): should the MPTM section be a full reference (with everything from the IT section + the current MPTM section), or should it stay as is?

Good luck with the next release!

-- Twomoso (talk) 22:27, 1 October 2018 (CEST)

No rush, if the page is not finished in time, it can still be added in 1.28.02.00 or so. 14th is most likely the earliest possible release date, but it might also be released easlier.

Please keep the MPTM section as-is, since changing anything in the IT section requires the double amount of work otherwise, and one could easily forget to update both sections when making an update.

Saga Musix (talk) 12:21, 2 October 2018 (CEST)

I removed the "Special" memory type from the S3M reference, but I guess neither before nor after is really optimal, and having the extra "S00" entry in the table as before is probably the better option. Sxy really has the same kind of memory as any of the other commands with global memory, in the sense that S00 recalls this memory, but the individual sub-commands do have a specific meaning for parameter 0 (e.g. S30 sets a waveform), so I think it would make more sense to put a dash in those columns, just as before.

Saga Musix (talk) 23:58, 3 October 2018 (CEST)

The "Special" memory classification is sort of weird, but I feel iffy about giving S00 its own entry since (as far as I know) it's just the memory parameter for Sxy.

Maybe using a dash with hover-text containing something like "Memory can be called with S00" in the Memory column would be better? Like this:

Eff	Name	Mem	Description
S2x	Set Finetune	—	Considered a legacy command. Overrides the current sample's C-5 frequency with a MOD finetune value.
S3x	Set Vibrato Waveform	—	Sets the waveform of future Vibrato effects.
S4x	Set Tremolo Waveform	—	Sets the waveform of future Tremolo effects.

An alternative could be a dash and another footnote (e.g. "—^‡"), or perhaps adding actual text after the dash (e.g. "— (Yes if S00)"). The former's not much different than just including "sub-commands of Sxy have '—' memory" in the current Effect Memory footnote, though, and the latter bloats the memory column size (as well as being somewhat confusing).

-- Twomoso (talk) 04:29, 4 October 2018 (CEST)

Yeah, that seems better. Saga Musix (talk) 12:24, 4 October 2018 (CEST)

---

Some parts of the effect reference (like the IT Effect Commands section's "Volume Column Effect Memory" note) describe the behavior of commands when related Compatible Playback settings are disabled. Should they be removed or kept?

The Compatible Playback article already explains the differences and is linked at the beginning of the effect reference, so I think duplicating the information from that page is unnecessary (especially since Compatible Playback settings generally aren't meant to be changed).

-- Twomoso (talk) 22:53, 5 October 2018 (CEST)

In general this is indeed the better way to go, in particular since it won't even make people aware of something they shouldn't change at all. Saga Musix (talk) 23:51, 7 October 2018 (CEST)

In the S3M section, I marked all effects not present in Scream Tracker 3 as "not an original Scream Tracker 3 effect" to prevent misinformation. I'm wondering which (if any) effects are specifically MPT hacks so they can be marked as such.

More importantly, I think the effect reference is otherwise finished. There shouldn't be any problems or missing information compared to the existing effect reference, but I'd like you to review the page to make sure it's suitable to replace it.

-- Twomoso (talk) 06:10, 9 October 2018 (CEST)

I think all of the non-ST3 effects were previously available in other S3M-compatible trackers such as Impulse Tracker, the only one I'm not sure about is volume-column panning.

I will have a look in the following days to correct any mistakes I can find. Many thanks for your efforts! Saga Musix (talk) 22:43, 9 October 2018 (CEST)

Were there not any Sound Control commands supported by other Scream Tracker 3-compatible trackers/players?

-- Twomoso (talk) 02:41, 10 October 2018 (CEST)

The only possibly supported Sound Control command can be S91, as that was introduced by Impulse Tracker, the rest are of course MPT additions. Saga Musix (talk) 19:28, 10 October 2018 (CEST)

Sorry to bother you, but are you satisfied with the page? The release of 1.28 seems to be coming close, so I thought I'd ask.

-- Twomoso (talk) 07:38, 14 November 2018 (CET)

If you look at the edit history, you will see that I made a few changes but apart from that it looks pretty good. I want to go through it one more time before merging it into the manual, probably during the weekend.

Saga Musix (talk) 19:27, 14 November 2018 (CET)

Oops; I checked the edit history prior to November 11 but didn't think to do it now for some reason. Thanks for helping out!

-- Twomoso (talk) 22:36, 14 November 2018 (CET)

As a general comment, I undid some changes in particular in the volume column descriptions where you removed the short effect descriptions and entirely referred to their effect column counterparts; Since I think that this information should be easy to look up without having to scroll between sections, I added the basic descriptions back.

Saga Musix (talk) 23:06, 14 November 2018 (CET)

Makes sense.

I'm only conflicted about using the xx parameter notation for effects that only take one digit, since I feel like it's misleading.

-- Twomoso (talk) 01:07, 15 November 2018 (CET)

All of those commands take 2 digits in the XM format (0-15), that's why I changed it back.

Saga Musix (talk) 19:40, 15 November 2018 (CET)

Oh, that explains why the other sections weren't changed... my bad.

-- Twomoso (talk) 20:02, 15 November 2018 (CET)

I have now merged the reference. Many thanks for your efforts once again! Saga Musix (talk) 16:31, 9 December 2018 (CET)

Hurray! I'm glad the reference has been accepted.

-- Twomoso (talk) 21:29, 9 December 2018 (CET)

Regarding your latest edit, adding a slash in br tags is not needed, as MediaWiki uses HTML5. The slashes are only required for XHTML. (Personally I'd be happier if XHTML was still alive but oh well...) Saga Musix (talk) 21:14, 11 December 2018 (CET)

I changed it mostly to stay consistent with other pages, but I did think it had a more relevant purpose ('cause why else would XHTML enforce it?). After searching around some, it seem there's not really a reason to use one over the other if MediaWiki does indeed use HTML5. A Wikipedia help page about line breaks says MediaWiki automatically converts any valid br tags into <br />, but I wasn't able to find anything about it in the MediaWiki documentation itself, so I'm not 100% sure if it's true.

In any case, a "Find & Replace" or similar action can easily change the tags, so in case <br> is (or becomes) preferred it shouldn't be difficult to switch over (maybe one day we'll get a new YHTML standard).

-- Twomoso (talk) 19:50, 12 December 2018 (CET)

The reason why older pages use the slash is that back when the wiki was first edited, MediaWiki was indeed using XHTML. Saga Musix (talk) 20:44, 12 December 2018 (CET)