Zompist Bboard Again

I've never really used SCAs, my lexicons have always been so underdeveloped that I can just apply sound changes by hand. But I've been adding a lot of new items to a couple of my lexicons recently, and at this point I really need to start automating things. I've been trying to use Zompist's sca2, and I feel that I'm not really getting the most out of it. Handling things like stress, footing, and tone is proving fairly challenging. But I've seen people here post lists of sound changes (if I'm not mistaken) for sca2 that are just impeccably organized and handle all these things with ease. Can anyone help me understand what I'm missing here?

do you have particular examples of problems you're running into?

i usually try to make sure every phoneme is representable by a single character (so using the ligature "ʦ" or the character "c" instead of "ts" or "t͡s", for example). sometimes i'll use numbers for just throwaway changes or exceptions, although the new version of the SCA allows you to put exceptions into the rules, which minimizes the need for this. i try to be consistent with diacritics (e.g. if "é" means /ˈe/ and "ê" means /ˈeː/, then "ó" needs to mean /ˈo/ and "ô" /ˈoː/). the other big thing is trying to do things in as many categories as is practical: if i find myself having to take up multiple lines with basically the same change but for different letters, i'll see if i can combine similar sounds that are going through the same process into one category. it's helpful to try to use consistent mnemonics to remember what this or that category means, although sometimes that's just not possible. lastly, of course, it requires trial and error, and you need to try different words with different phonotactics to make sure you're getting the result you expect out of the rules, and it's better if you do this testing frequently as you go rather than trying to pile everything in and then trying to figure out where the mistake was at the end.

one thing i do sometimes, that would have saved me a lot of trouble when i was younger if i had thought of it earlier, is (if it makes sense to do it for the sound changes i'm working with) i'll often make categories for each particular vowel that includes each combination of stressed, unstressed, short, long, etc. this is helpful for vowel changes that occur regardless of stress or length distinctions (and it's not necessary if your rules don't include such changes). so if i have the categories
A=aáàâãą
E=eéèêẽę
I=iíìîĩį
O=oóòôõǫ
U=uúùûũų
i can set up the rule U/O/_(C)(C)(C)A to turn every instance of /u/, whether it's short or long or stressed or unstressed or oral or nasal, into /o/ if it precedes a syllable whose nucleus is /a/. or i can set up the rule k/č/_I to palatalize /k/ before an /i/. again, not every language is going to use this, but i've found it to be pretty helpful on more than one occasion

i can't speak to tone as i haven't done a tonal language yet, and i'm not sure what you mean by footing, but as far as stress i've found it best to indicate it with vowel diacritics. this can admittedly become somewhat tricky to keep track of, so my sca files are often filled with comments, but the result is pretty clean rules. the simplest situation is one where you have a category for unstressed vowels and a category for stressed ones. let's say your language has no length distinction, no tense-lax distinction, no nasal vowels, no diphthongs, no vowel reduction in unstressed syllables, nothing that introduces any sort of vowel complication. all it has is the simple vowels /a e i o u/, and it uniformly stresses the final syllable. if your sound change rules shift the stress to the penultimate syllable, all you would need is a category for stressed vowels, a category for unstressed vowels, and the rules to shift the stress:

A=aeiou
Á=áéíóú

A/Á/_(C)(C)(C)Á
Á/A/Á(C)(C)(C)_

the first rule changes an unstressed vowel to a stressed vowel if it occurs in the syllable preceding a stressed syllable, and the second changes a stressed vowel into an unstressed vowel if it occurs after a stressed vowel. even if your language had length distinctions, nasal vowels, and so on, you don't need to worry about them if the sound change rules are never affected by those categories.

but if they are, then it makes sense to create more distinct categories. these are some of the category definitions from a project of mine that includes distinctions for stress, length, and nasality:

Ă=aeiouyæœǝαáéíóúýǽɶƏάąęįǫųʏᴂꭀɘᶐãẽĩõũỹꬱꭁэᾶ (all short vowels)
Å=āēīōūȳǣøⱻᾱâêîôûŷᴁǿƎ⍶ảẻỉỏủỷԙØᵊἀäëïöüÿԘǾӛἅ (all long vowels)
Ȁ=aeiouyæœǝαāēīōūȳǣøⱻᾱąęįǫųʏᴂꭀɘᶐảẻỉỏủỷԙØᵊἀ (all unstressed vowels)
Ǎ=áéíóúýǽɶƏάâêîôûŷᴁǿƎ⍶ãẽĩõũỹꬱꭁэᾶäëïöüÿԘǾӛἅ (all stressed vowels)
Ạ=aeiouyæœǝαáéíóúýǽɶƏάāēīōūȳǣøⱻᾱâêîôûŷᴁǿƎ⍶ (all oral vowels)
Ḁ=ąęįǫųʏᴂꭀɘᶐãẽĩõũỹꬱꭁэᾶảẻỉỏủỷԙØᵊἀäëïöüÿԘǾӛἅ (all nasal vowels)

Ȧ=aeiouyæœǝα (short unstressed oral vowels)
Á=áéíóúýǽɶƏά (short stressed oral vowels)
Ā=āēīōūȳǣøⱻᾱ (long unstressed oral vowels)
Â=âêîôûŷᴁǿƎ⍶ (long stressed oral vowels)
Ą=ąęįǫųʏᴂꭀɘᶐ (short unstressed nasal vowels)
Ã=ãẽĩõũỹꬱꭁэᾶ (short stressed nasal vowels)
Ả=ảẻỉỏủỷԙØᵊἀ (long unstressed nasal vowels)
Ä=äëïöüÿԘǾӛἅ (long stressed nasal vowels)

this level of distinction, where every possible combination of stress, length, and nasality is represented by its own category, is overboard for most conlang projects. i made it in mine because the project covers multiple languages across a language family over a simulated 2000-year period, and i was trying to keep the category definitions consistent across every single set of sound changes; even here, as i continue with the project, i wil likely find that certain categories never come up, and i will delete them from the category definitions. for every other conlang i've worked on besides this outlier, i've generally just created the categories as i need them while developing the rules

as you can see, the characters for the individual sounds can be difficult to keep track of once you get beyond simple /a e i o u/, since you have to stick to precomposed unicode characters for SCA to work correctly (as opposed to ad hoc creations like <x̃> which are really two unicode codepoints and which the SCA will process as two separate characters), but with rewrite rules at the beginning and/or end of your sound change rules you can pretty quickly turn them back into readable IPA or a romanization. as long as you can keep track of the category symbol (A, Á, Ā, etc.), the clarity of the individual sound symbols (ᴂꭀɘᶐã) isn't as important

I don't use Zompist's SCA² a lot (my go-to sound change applier is still Alice's GSCA 0.5), but here are two tricks I use frequently that may still be helpful:

- If your SCA has a way to use them (and SCA² does), nonce categories are often much quicker to implement and easier to keep track of compared to complex predefined categories. They're most useful though if you can also use them in replacement function (which SCA² can't do AFAIK), because then you could write a broad shift that results in some partial mergers in a single rule. Here's some SCA² pseudocode for i-umlaut that doesn't work but shows what I mean:
[aeou]/[eiei]/_(C)(C)i

- SCA² can do simple exceptions in its rule syntax (s/h/_C/_[ptk] = [s] becomes [h] before a consonant other than {p,t,k}), but if you need to build more complex exceptions, it's often a good strategy to define a blocking character in the relevant environment, execute a general sound change, and then remove the blocker. For example, if [s] becomes [h] everywhere except word-initially, word-finally, or before {p,t,k}, you could write the following:
/;/#s_
/;/_s#
/;/_s[ptk]
s/h/V_
s/h/_V
;//_

i still do all my sound changes by hand. one advantage of my method is that i have memorized the diachronics for all of my major languages, and just by looking at a proto-language word, i can tell if it will merge with some other proto-language word, and where in the history it will happen. im tolerant of homophones in the daughter languages if they are just recently merged, but if two words with completely different senses are homophones for thousands of years, i'm more likely to toss one of the pair out.

whereas i couldnt do that if all my languages' sound changes were just letters and symbols on a screen.

if you decide to make the switch i would at least recommend maintaining some knowledge about which list is which, so you can get a feel for thigns like this when deriving many languages at once.

Stress is hard. I usually represent it with a postvocalic spacing character and write rules that can count syllables from word boundaries. Adding the stress character to all syllables (or all eligible syllables) and incrementally removing it until there's only one stress character left basically works, and makes it easy to see if your sound changes have bugs, which they inevitably will.

Splitting sound changes across multiple files is reasonable, and makes it easier to keep track of all the categories and possible characters. I wish SCAs had some kind of "section declaration" feature - basically, you'd declare a section and then enumerate all characters possible at that stage of the language (probably by defining them in categories), and the SCA would, upon hitting a section boundary, forget all enumerations and categories defined in previous sections, and after reading the new enumerations and categories, throw an error if it's asked to apply a sound change to a word that contains an unfamiliar character. Another common source of bugs IME is just forgetting shit.

I haven’t yet figured out a good way of doing stress and the like in SCAs. At the moment, for one set of changes, I’m manually assigning stress with an apostrophe after the vowel, and then ignoring that and manually accounting for syllables when needed, but it’s tricky. The alternative is a diacritic, which invariably ends up like Ḁ=ąęįǫųʏᴂꭀɘᶐãẽĩõũỹꬱꭁэᾶảẻỉỏủỷԙØᵊἀäëïöüÿԘǾӛἅ (to quote GreenBowtie). Mind you, it ends up like that anyway. It is for this reason that I am currently creating a new SCA, with proper multigraph support. Also proper support for syllabification and suprasegmentals, though I have no idea what the best way of doing that is. (I did have an implementation, but as it happens I removed it just a few minutes ago, because — to quote the commit message — it was ‘very buggy and practically unusable, to the extent that I avoided it even for a set of heavily stress-dependent sound changes’.)

Nortaneous wrote: ↑Sun Apr 11, 2021 9:24 am Splitting sound changes across multiple files is reasonable, and makes it easier to keep track of all the categories and possible characters. I wish SCAs had some kind of "section declaration" feature - basically, you'd declare a section and then enumerate all characters possible at that stage of the language (probably by defining them in categories), and the SCA would, upon hitting a section boundary, forget all enumerations and categories defined in previous sections, and after reading the new enumerations and categories, throw an error if it's asked to apply a sound change to a word that contains an unfamiliar character. Another common source of bugs IME is just forgetting shit.

Ooh, good idea! I’ll see if I can add this to my SCA.

bradrn wrote: ↑Sun Apr 11, 2021 9:41 am

Nortaneous wrote: ↑Sun Apr 11, 2021 9:24 am Splitting sound changes across multiple files is reasonable, and makes it easier to keep track of all the categories and possible characters. I wish SCAs had some kind of "section declaration" feature - basically, you'd declare a section and then enumerate all characters possible at that stage of the language (probably by defining them in categories), and the SCA would, upon hitting a section boundary, forget all enumerations and categories defined in previous sections, and after reading the new enumerations and categories, throw an error if it's asked to apply a sound change to a word that contains an unfamiliar character. Another common source of bugs IME is just forgetting shit.

Ooh, good idea! I’ll see if I can add this to my SCA.

The rewrite of my SCA that I'm (slowly) working on will do this.

bradrn wrote: ↑Sun Apr 11, 2021 9:41 am I haven’t yet figured out a good way of doing stress and the like in SCAs. At the moment, for one set of changes, I’m manually assigning stress with an apostrophe after the vowel, and then ignoring that and manually accounting for syllables when needed, but it’s tricky. The alternative is a diacritic, which invariably ends up like Ḁ=ąęįǫųʏᴂꭀɘᶐãẽĩõũỹꬱꭁэᾶảẻỉỏủỷԙØᵊἀäëïöüÿԘǾӛἅ (to quote GreenBowtie). Mind you, it ends up like that anyway. It is for this reason that I am currently creating a new SCA, with proper multigraph support. Also proper support for syllabification and suprasegmentals, though I have no idea what the best way of doing that is. (I did have an implementation, but as it happens I removed it just a few minutes ago, because — to quote the commit message — it was ‘very buggy and practically unusable, to the extent that I avoided it even for a set of heavily stress-dependent sound changes’.)

Also watch out for Unicode normalization and multigraph loading issues. I haven't used any SCA in forever, but IIRC the one I do use has huge issues around that - in addition to normalization issues, I think it fails to recalculate multigraphs after sound changes, so writing sound changes to assemble multigraphs doesn't work. (That is, you can't shift apostrophe to combining acute; you instead have to write a e o i u > á é ó í ú / _', ' > 0.)

Nortaneous wrote: ↑Sun Apr 11, 2021 10:18 am

bradrn wrote: ↑Sun Apr 11, 2021 9:41 am I haven’t yet figured out a good way of doing stress and the like in SCAs. At the moment, for one set of changes, I’m manually assigning stress with an apostrophe after the vowel, and then ignoring that and manually accounting for syllables when needed, but it’s tricky. The alternative is a diacritic, which invariably ends up like Ḁ=ąęįǫųʏᴂꭀɘᶐãẽĩõũỹꬱꭁэᾶảẻỉỏủỷԙØᵊἀäëïöüÿԘǾӛἅ (to quote GreenBowtie). Mind you, it ends up like that anyway. It is for this reason that I am currently creating a new SCA, with proper multigraph support. Also proper support for syllabification and suprasegmentals, though I have no idea what the best way of doing that is. (I did have an implementation, but as it happens I removed it just a few minutes ago, because — to quote the commit message — it was ‘very buggy and practically unusable, to the extent that I avoided it even for a set of heavily stress-dependent sound changes’.)

Also watch out for Unicode normalization and multigraph loading issues.

Not sure why normalization would be an issue, could you elaborate please?

I haven't used any SCA in forever, but IIRC the one I do use has huge issues around that - in addition to normalization issues, I think it fails to recalculate multigraphs after sound changes, so writing sound changes to assemble multigraphs doesn't work. (That is, you can't shift apostrophe to combining acute; you instead have to write a e o i u > á é ó í ú / _', ' > 0.)

I know mine doesn’t have this problem, though. (It represents everything as multigraphs internally, only converting back to display the results, so — in Haskellish pseudocode — a rule like ["a", "'"] → ["aˊ"] would be no different to a rule like ["a", "b"] → ["c"].

bradrn wrote: ↑Sun Apr 11, 2021 10:22 am Not sure why normalization would be an issue, could you elaborate please?

The mapping of graphical representation to underlying codepoints isn't one-to-one - it's possible for multiple underlying sequences of codepoints to have identical graphical representations. This is trivially true (and not really a problem) for cross-alphabet homographs like Latin and Cyrillic <a>, but where it becomes a problem is in the handling of diacritics - a + combining acute is (or should be) graphically identical to precomposed a-acute.

You probably want something like NFD, but there could be difficulties with normalization diacritic reordering. If a sound change adds, say, an overdot to s-underdot, NFD will reorder this to 0073 (s) 0323 (underdot) 0307 (overdot). But probably this is a minor user footgun rather than a bug, and any sound changes that behave incorrectly (for example, writing a rule that applies to all overdotted consonants without defining s-underdot and expecting it to behave equivalently to s) are just incorrect.

edit: Another fun thing which I've just noticed is that conceptually identical characters can still have different codepoints after NFD normalization, as shown here - E-macron + grave and E + macron + grave are both NFD-normalized to E + macron + grave, but E-grave + macron is NFD-normalized to E + grave + macron.

Nortaneous wrote: ↑Sun Apr 11, 2021 9:24 amStress is hard.

That's why it's called "stress"

If it helps, a few SCA² rules for handling stress.

Stress falls on the first syllable in proto Tarandim, and then every other vowel gets secondary stress. Then unstressed vowels are lost.
Here's how I handle it:

/'/#_(C)(C)V
/'/'_(C)(C)V(C)(C)V_(C)(C)V
V//_'

Basically I came up with these with debugging, running test words and seeing if stress gets placed correctly. They're not complete, btw (these don't handle long words correctly, but that doesn't matter --- words are still short at this stage, so I favored readability over accuracy...)

I do have to take into account the symbol I use for stress later on, for instance:

b/w/V_(')V
g/r/V_(')V

Ok, I've gotten a lot of very helpful advice so far that I'm definitely going to keep in mind, so, thank you everybody! I'm still having some difficulties though, so I'm gonna try to describe my specific problem in more detail.

In several of the languages I'm working on, metrical structure plays a big role and conditions lots of vowel shifts. In turn, the the metrical structure is itself conditioned by syllable weight. For example, in Proto-Yonutian footing is right-to-left, weight sensitive and iambic, with extrametrical final syllables and stress assigned to the rightmost foot head. On the way to Proto-Western Yonutian, wowels then drop out in various places conditioned by the foot structure: all vowels after a light stressed syllable, all final vowels, certain vowels in metrically weak positions within the foot, vowels in unfooted syllables between certain consonants. So, for some example (ignoring other changes):

soboqtes > soboqtes
so(ˈbōq)[tes]

soboqtehi > soboqteh
so(ˈbōq)te[hi]

kedemas > kedems
(keˈdē)[mas]

kedemahi > kedemah
ke(deˈmā)[hi]

pamfesutumbo > pamfsutumb
(pām)(fetū)(ˈtūm)[bo]

pamfesutuso > pamfsutus
(pām)fe(suˈtu̅)[so]

I have... no idea how to code this.

I'm not sure I get your stress rule... Why are soboqtehi and kedemahi stressed in different places?

Honestly, I have no idea how you would go about implementing this stress system. Possibly your best bet is to do what I’ve done for my current set of sound changes: manually add a special character after the stressed vowel in the input, then use that for stress-sensitive sound changes. So your input will no longer be soboqtes, soboqtehi etc., but rather soboʹqte, soboʹqtehi etc.

Ares Land wrote: ↑Mon Apr 12, 2021 5:08 am I'm not sure I get your stress rule... Why are soboqtehi and kedemahi stressed in different places?

I’m assuming it’s because (ke.de) = (L.L) fits into an iambic moraic foot, whereas *(boq.te) = (H.L) doesn’t, so /te/ must remain unfooted.

I'll give it a shot -- I was able to write sca2 rules for Latin stress (except I can't find the file now, of course) which isn't terribly dissimilar from these.

bradrn wrote: ↑Mon Apr 12, 2021 6:28 am I’m assuming it’s because (ke.de) = (L.L) fits into an iambic moraic foot, whereas *(boq.te) = (H.L) doesn’t, so /te/ must remain unfooted.

Yes, this is why

bradrn wrote: ↑Mon Apr 12, 2021 6:28 am Possibly your best bet is to do what I’ve done for my current set of sound changes: manually add a special character after the stressed vowel in the input, then use that for stress-sensitive sound changes.

I honestly hadn't even thought of that, but you might be right. Of course, I'd need to mark every head syllable of a foot as well, since they play a role too.

Okay, you can try this out with the sca2.

These rules work with the words you listed above.

The trick is that the SCA can insert symbols where you need them. I use it first to mark syllable boundaries, then to tell heavy from light syllables, and then for moraic foot boundaries. Once it's done that work it can place a stress mark easily.

These are very nice stress rules by the way and now I want to steal them