Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 7:13 am
It's linked on the main page for Brassica, which advertises it as supporting multiple features that the online version doesn't have!
Page 4 of 13
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 8:00 am
Oh, I have a change that does /t/ > /s/ before /i/, which works fine; but later a change of /u/ > /y/ in certain circumstances, and a subsequent change of /t/ > /s/ before /y/, but this last one doesn't work.bradrn wrote: ↑Tue Jul 12, 2022 11:42 pmIt does apply them in order. Could you supply more details as to your specific problem please?Rounin Ryuuji wrote: ↑Tue Jul 12, 2022 8:59 pm Can the sound change applier be made to apply the steps in a specific order, rather than apparently all at once?
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 8:40 am
Sorry, but I can’t any such link. Could you please share a screenshot of where you’re looking, or at least give me a URL?dhok wrote: ↑Wed Jul 13, 2022 7:13 amIt's linked on the main page for Brassica …
This is very fair, though. I really should add a warning that the online version doesn’t support all features. (And find some time to implement the most important ones, too!)… which advertises it as supporting multiple features that the online version doesn't have!
Hmm… could you share the precise rules, please?Rounin Ryuuji wrote: ↑Wed Jul 13, 2022 8:00 am Oh, I have a change that does /t/ > /s/ before /i/, which works fine; but later a change of /u/ > /y/ in certain circumstances, and a subsequent change of /t/ > /s/ before /y/, but this last one doesn't work.
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 8:59 am
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 9:15 am
It is noted as being downloadable from a Github repository:
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 9:25 am
You have some typos. The last few rules should be:Rounin Ryuuji wrote: ↑Wed Jul 13, 2022 8:59 amI've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].
Code: Select all
ʉ́ᵝ j ʉ̀ᵝ / ýᵝ ì j / _ ; added in spaces
; skip a few...
j / ʎ / _# ; match at end of word rather than beginning
OK, something is going badly wrong here, because for me that links to https://github.com/bradrn/brassica. Moreover, it has linked there ever since I first uploaded it to my webserver. I’m not sure how you got to exSCA from that.
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 9:53 am
Oh, thank you, it works now.bradrn wrote: ↑Wed Jul 13, 2022 9:25 amYou have some typos. The last few rules should be:Rounin Ryuuji wrote: ↑Wed Jul 13, 2022 8:59 amI've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].
Re: Brassica SCA [online version]
Posted: Wed Jul 13, 2022 3:14 pm
Not sure either, but I have downloaded the desktop-side Brassica now. Thanks!bradrn wrote: ↑Wed Jul 13, 2022 9:25 amYou have some typos. The last few rules should be:Rounin Ryuuji wrote: ↑Wed Jul 13, 2022 8:59 amI've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].
With the former rule, you accidentally created ýᵝìj as a single multigraph; with the latter, you put the symbols the wrong way around.Code: Select all
ʉ́ᵝ j ʉ̀ᵝ / ýᵝ ì j / _ ; added in spaces ; skip a few... j / ʎ / _# ; match at end of word rather than beginning
OK, something is going badly wrong here, because for me that links to https://github.com/bradrn/brassica. Moreover, it has linked there ever since I first uploaded it to my webserver. I’m not sure how you got to exSCA from that.
Re: Brassica SCA [online version]
Posted: Sat Jul 16, 2022 1:17 pm
(Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)
Re: Brassica SCA [online version]
Posted: Sat Jul 16, 2022 7:22 pm
Oh, I fully agree. The current font certainly isn’t ideal — its main virtue is that everyone has it installed. A font selector will be added in the next release.dhok wrote: ↑Sat Jul 16, 2022 1:17 pm (Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)
Re: Brassica SCA [online version]
Posted: Sat Jul 16, 2022 7:55 pm
That is wonderful of you.bradrn wrote: ↑Sat Jul 16, 2022 7:22 pmOh, I fully agree. The current font certainly isn’t ideal — its main virtue is that everyone has it installed. A font selector will be added in the next release.dhok wrote: ↑Sat Jul 16, 2022 1:17 pm (Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)
Re: Brassica SCA [online version]
Posted: Sat Jul 16, 2022 8:16 pm
Thanks muchly for the upcoming font selector!
Another idea that occurred to me, since we're basically coding in a bespoke programming language, is the ability to group changes into higher-level blocks that can be toggled off and on. This could eventually be expanded to make it easier to work on families as a group rather than individually. (Though you've probably thought of something like this...)
Let's say I've got a massive family that ranges over 4000 years with a lot of more-or-less binary branching and clades nestled within clades. Then I might write something like
But suppose I'd like to see what Proto-Everyone-But-A looked like--maybe I want to see what sorts of paradigmatic repairs are going to show up in all the downstream clades. I think you might want some sort of syntax like this:
Here, block #beta on could be switched to off--and presto, you're looking at Proto-Everyone-But-A.
At that point maybe it would need to look like a text editor, but perhaps not. Another option, and perhaps a simpler one that requires less programmer-brain, might be to introduce some sort of keyphrase syntax like intermediate[A]. This could signal to the program that it should add an "Apply: A" button under 'Apply' which would apply all rules up to A, but effectively comment out anything that follows. I don't know Haskell and don't know how much of a pain in the rear this would be.
Another option for what this might look like from the user's end that occurs to me is that, just as the user defines categories at the start of the rule file, the user could define rule blocks within the rule file, then specifically tell the program which ones are run. For example, suppose we were making a rule file for the Algonquian languages. We could introduce some keywords: child, inherits and history. Languages that branch off early will just be declared as:
This would produce a tag ar that could be used to define a block of changes applying only to Arapaho:
(The on keyword here is very much just a suggestion. The idea is that it would tell the program to create an "Apply (Arapaho)" button under the 'Apply' button. Switching to off would take the button away, if you're working with a large family.)
The keyword inherits could be used to help keep daughter clades in check. For example, all the (non-Blackfoot) Algonquian languages east and south of Arapaho and Cree merge PA *r and *θ, and all of those minus Cheyenne and Menominee also merge *h and *ʔ before a consonant. (While Algonquian doesn't lend itself too well to the tree model, we'll pretend it does for the purposes of what I'm sketching out; we'll name these clades "alpha" and "beta" as a proof of concept.) Then:
This would take a bit more finagling with keywords and block declaration, but it would let the user work on a related group of languages as a family and not in isolation, and fits much better with the way historical linguists actually think about sound change in a comparative context.
Another idea that occurred to me, since we're basically coding in a bespoke programming language, is the ability to group changes into higher-level blocks that can be toggled off and on. This could eventually be expanded to make it easier to work on families as a group rather than individually. (Though you've probably thought of something like this...)
Let's say I've got a massive family that ranges over 4000 years with a lot of more-or-less binary branching and clades nestled within clades. Then I might write something like
Code: Select all
; changes shared by everyone except branch A
T / D / N_
[k g] / [ts dz] / _[i e]
; except branches A and B
[ɨ ɤ] / [i e]
p / f / _ / N_
; except branch C
θ / f
[k g] / [kʷ gʷ] / _u
u / i
Code: Select all
; changes shared by everyone except branch A
block $alpha on {
T / D / N_
[k g] / [ts dz] / _[i e]
; except branches A and B
block $beta on {
[ɨ ɤ] / [i e]
p / f / _ / N_
; except branch C
block $gamma on {
θ / f
[k g] / [kʷ gʷ] / _u
u / i
}
}
}At that point maybe it would need to look like a text editor, but perhaps not. Another option, and perhaps a simpler one that requires less programmer-brain, might be to introduce some sort of keyphrase syntax like intermediate[A]. This could signal to the program that it should add an "Apply: A" button under 'Apply' which would apply all rules up to A, but effectively comment out anything that follows. I don't know Haskell and don't know how much of a pain in the rear this would be.
Another option for what this might look like from the user's end that occurs to me is that, just as the user defines categories at the start of the rule file, the user could define rule blocks within the rule file, then specifically tell the program which ones are run. For example, suppose we were making a rule file for the Algonquian languages. We could introduce some keywords: child, inherits and history. Languages that branch off early will just be declared as:
Code: Select all
child ar[Arapaho:on]Code: Select all
history(ar)
(R)V // _#
[o ō] / [i ī]
k // _
p / k
r / n
s / n / #_
history(ar).endThe keyword inherits could be used to help keep daughter clades in check. For example, all the (non-Blackfoot) Algonquian languages east and south of Arapaho and Cree merge PA *r and *θ, and all of those minus Cheyenne and Menominee also merge *h and *ʔ before a consonant. (While Algonquian doesn't lend itself too well to the tree model, we'll pretend it does for the purposes of what I'm sketching out; we'll name these clades "alpha" and "beta" as a proof of concept.) Then:
Code: Select all
child ar[Arapaho:on]
child cr[Cree:on]
child alpha[Alpha:on]
child ch[Cheyenne:on] inherits alpha
child men[Menominee:on] inherits alpha
child beta[Beta:on] inherits alpha
child mes[Meskwaki:on] inherits beta
child oj[Ojibwe:on] inherits beta
history(alpha)
θ / r
history(alpha).end
history(ch)
[o ō] / [i ī]
[h N] / / _C
; etc. etc.
history(ch).end
history(men)
ʔ / h / _[p k]
š / s
;etc. etc.
history(men).end
history(beta)
ʔ / h / _C
history(beta).end
history(mes)
N / / _C
hr / s
nr / t
history(mes.end)
Re: Brassica SCA [online version]
Posted: Sat Jul 16, 2022 8:53 pm
Ooh, I love this idea! Thanks for the suggestion! I’ll definitely have to implement this soon.dhok wrote: ↑Sat Jul 16, 2022 8:16 pm Another idea that occurred to me, since we're basically coding in a bespoke programming language, is the ability to group changes into higher-level blocks that can be toggled off and on. This could eventually be expanded to make it easier to work on families as a group rather than individually. (Though you've probably thought of something like this...)
Re: Brassica SCA [online version]
Posted: Sun Jul 17, 2022 8:14 am
IIRC from when I was playing with building desktop-side applications, getting the program to add buttons in real-time is a hassle, so maybe there should be a drop-down menu under or next to the 'Apply' button that has the child tags. You may have intuited that the post I made last night was somewhat stream-of-consciousness, as better ideas for how to handle family-wide diachronics came to mind.
In real life, also, clades are not always entirely clean cuts--consider Aragonese, which is indubitably a Western Romance language about halfway between Catalan and Spanish, but which avoided intervocalic voicing (which the rest of Western Romance underwent). That doesn't mean that it isn't sensible to fit it within Western Romance in the program. Rather, we might write something like this:
I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions. (Although, just as categories form blocks, maybe we'd also need to build children within blocks, as something like this?
If we use a drop-down menu, maybe the 'on/off' switch on clades is no longer necessary.
But this sort of structure, which allows clades but also exceptions, would essentially smuggle the wave model of sound change into an architecture built on the tree model. To complement the history structure, we might also be interested in creating, effectively, a function constructor, which fires only when called. Suppose we were doing Indo-European and wanted to model laryngeal development. The laryngeals, of course, cheshirized *mostly* the same way everywhere but there were enough edge cases that the results were plenty messy. At the same time, though, we'd prefer not to write almost exactly the same sound changes for every dozen or so branches of IE. So instead, we could do something like this:
Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade (or maybe multiple, as case(a b c)), which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)
My presumption is that in the code, clade inheritance and calling a sound law would get treated very similarly, but they're conceptually distinct and distinct enough in reality (tree model vs. wave model) that allowing the user to separate them is probably ideal.
(And yet another addendum...) for a large enough family, this may also imply that we might want to make categories somewhat daughter-specific rather than having a one-size-fits-all structure that has to be reworked for every daughter. Consider a toy family with the vocalic proto-inventory of Finnish: *i *y *e *ø *æ *u *o *ɒ. Daughter 1 is marked by extensive palatalization, and the operative distinction in the vowels is front vs. back; daughter 2 is marked by rounding, and the operative distinction is rounded vs. unrounded. (And I just noticed that if we have a children...children.end block declaration, we can probably kill the 'child' keyword...)
(Hmm, I should goof around with Haskell...)
In real life, also, clades are not always entirely clean cuts--consider Aragonese, which is indubitably a Western Romance language about halfway between Catalan and Spanish, but which avoided intervocalic voicing (which the rest of Western Romance underwent). That doesn't mean that it isn't sensible to fit it within Western Romance in the program. Rather, we might write something like this:
Code: Select all
child WR[Western Romance:on]
child IR[Ibero-Romance:on]
child Cat[Catalan:on] inherits(WR)
child Arag[Aragonese:on] inherits(WR IR)
child Port[Portuguese:on] inherits(WR IR)
categories
T = p t k
D = b d g
V = i e ɛ a ɔ o u
;etc.
end
history(WR)
except(Arag): T / D / V_V
except(Port Cat): [ɛ ɔ] / [ie uo]
;etc.
history(WR).end
history(Arag)
uo / ue
lj / ll
;etc.
history(WR).end
Code: Select all
children
child WR[Western Romance:on]
;etc.
children.end
But this sort of structure, which allows clades but also exceptions, would essentially smuggle the wave model of sound change into an architecture built on the tree model. To complement the history structure, we might also be interested in creating, effectively, a function constructor, which fires only when called. Suppose we were doing Indo-European and wanted to model laryngeal development. The laryngeals, of course, cheshirized *mostly* the same way everywhere but there were enough edge cases that the results were plenty messy. At the same time, though, we'd prefer not to write almost exactly the same sound changes for every dozen or so branches of IE. So instead, we could do something like this:
Code: Select all
children
child anat(Anatolian)
child core(Core IE)
child gr(Greek) inherits core
child sk(Sanskrit) inherits core
child bt(Baltic) inherits core
children.end
categories
T = p t k ḱ kʷ
D = b d g ǵ gʷ
Dʰ = bʰ dʰ gʰ ǵʰ gʷʰ
Tʰ = pʰ tʰ kʰ ḱʰ kʷʰ
N = m n
R = m n w r l y
H = h₁ h₂ h₃
C = T D Dʰ N R H s
E = e o
Ṛ = ṃ ṇ u ṛ ḷ i
V = E Ṛ a ā ē ō
end
block laryngeals
e / a / h₂_
e / o / h₃_
e / ē / _h₁
e / ā / _h₂
e / ō / _h₃
case(gr)
[h₁ h₂ h₃] / [e a o] / [#C]_[CṚ]
case.end
case(sk)
H / i / C_[C#]
T / Tʰ / _H
case.end
case(bt)
/ h₁ / V_D
[Dʰ] / [D] / _
V / Vˀ / _H[C#]
; where Vˀ has to be defined in or just before history(bt) fires, but this case gets skipped until then
case.end
except(anat): H / / _
laryngeals.end
history(gk)
law: laryngeals
law: centumization
Dʰ / Tʰ
Tʰ / T / _VTʰ
history(gk).end
My presumption is that in the code, clade inheritance and calling a sound law would get treated very similarly, but they're conceptually distinct and distinct enough in reality (tree model vs. wave model) that allowing the user to separate them is probably ideal.
(And yet another addendum...) for a large enough family, this may also imply that we might want to make categories somewhat daughter-specific rather than having a one-size-fits-all structure that has to be reworked for every daughter. Consider a toy family with the vocalic proto-inventory of Finnish: *i *y *e *ø *æ *u *o *ɒ. Daughter 1 is marked by extensive palatalization, and the operative distinction in the vowels is front vs. back; daughter 2 is marked by rounding, and the operative distinction is rounded vs. unrounded. (And I just noticed that if we have a children...children.end block declaration, we can probably kill the 'child' keyword...)
Code: Select all
children
proto(Proto)
alpha(Alpha) inherits proto ;front vs. back
beta(Beta) inherits proto ; rounded vs. unrounded
children.end
categories(proto)
S = p t k
Z = b d g
N = m n
F = s x h
R = w l y
C = S Z N F R
V = i ü e ö æ u o å
categories(proto).end
history(proto)
; allophonic stuff operative in the proto-language that's a pain to write in the input lexicon can go here
history(proto).end
categories(alpha)
Vf = i ü e ö æ
Vb = u o å
C = C tʃ dʒ ts dz š ; some way of appending to an existing category without overwriting it?
categories(alpha).end
history(alpha)
[k g t d s] / [tʃ dʒ ts dz š] / _[Vf]
history(alpha).end
categories(beta)
Vr = ü ö u o å
Vn = i e æ
C = C kʷ gʷ xʷ
categories(beta).end
history(beta)
[k g] / [kʷ gʷ] / _[Vr]
[ü ö] / [i e]
history(beta).end
(Hmm, I should goof around with Haskell...)
Re: Brassica SCA [online version]
Posted: Sun Jul 17, 2022 9:24 am
It shouldn’t be terribly hard… I’m already doing something not too different for the syntax highlighting. Adding and removing buttons certainly is a bit of a pain, but not horribly so.
These ideas seem reasonable, though I’ll have to see how easy they are to implement.I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions.
…
Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade, which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)
Indeed you should! It’s a great language, and gives a very interesting perspective on programming too. (Your mental model of it seems a bit off at the moment, though ‘everything is a function’ isn’t such a terribly bad approximation.)(Hmm, I should goof around with Haskell...)
Re: Brassica SCA [online version]
Posted: Sun Jul 17, 2022 9:34 am
Yeah, I am not asking to be in the driver's seat, here--I know I have programmer brain (App Academy accepted me, although I turned them down), but just haven't built much. These are general ideas for tools that it might be useful to have in a future iteration, but only you'll know what works with the code, so I certainly won't complain if things can't make it in or have to be structured in a different manner. I think what I'm trying to reach towards here is a structure that encourages the user to think about *families*, rather than a collection of descendents that develop in vacuums. (Working on families was of course possible with prior SCA's like Haedus or Zomp's, it just involved reusing a lot of changes.)bradrn wrote: ↑Sun Jul 17, 2022 9:24 amIt shouldn’t be terribly hard… I’m already doing something not too different for the syntax highlighting. Adding and removing buttons certainly is a bit of a pain, but not horribly so.
These ideas seem reasonable, though I’ll have to see how easy they are to implement.I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions.
…
Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade, which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)
I am starting to have enough additional ideas that maybe I just need to learn Haskell and write a competitor. Sorry about the stream-of-consciousness posting style; as is so often the case with these things, using a forum post or chat room as a rubber duck is very useful way of refining the idea.
(the idea that just popped up--and I will try my best to shut up now [is there a way to donate to development?]--is to allow absolute chronologies to be defined as well as relative ones. The keyword would be something like year, taking a single integer. A parameter in the options would allow the user to type in an integer representing the terminus. E.g. if we decide that a vowel shift begins in 1500, then we can type year 1500 right before that vowel shift is executed. If we type "1500" into the parameter box and apply sound changes, all sound changes in the history of the language are applied *until* the program hits the 'year 1500' string, which brings the process to an end early. This way, intermediate stages don't require their own clades.)
(sorry sorry I really will shut up now)
Re: Brassica SCA [online version]
Posted: Sun Jul 17, 2022 12:23 pm
Re: Brassica SCA [online version]
Posted: Sat Sep 03, 2022 2:33 pm
I see there have been updates to the branch on Github--are we getting a desktop release with a font selector soon? Would be really, really useful.
Re: Brassica SCA [online version]
Posted: Sat Sep 03, 2022 8:16 pm
Yes, indeed we are! As of five days ago, HEAD now contains a font selector. (Not sure when I’ll be ready to make a release, but I’m getting there…)
Re: Brassica SCA [v0.0.3]
Posted: Fri Sep 16, 2022 10:49 am
Brassica v0.0.3 is now out! Get it from the release page, or try it online at http://bradrn.com/brassica as usual. Release highlights include:
Note there is one minor detail left to resolve: the Brassica API has also been wholly revamped, and is now actually usable for the first time ever, but alas, I do not have the permissions to upload the library to Hackage yet. I will let you know when it is available there.
As for what’s next… well, I’d love to implement dhok’s idea of toggling blocks on and off, but even more than that I want to find a better solution for suprasegmental and autosegmental stuff, because the current ‘features’ system is horribly confusing. I also want to add some way of backreferencing between categories, but that’s less of a priority unless anyone can come up with a sound change which absolutely requires backreferencing to work. (In fact, this goes generally: please send me any sound changes you can’t implement in Brassica if you find any!) That being said, I’m very busy at the moment, and probably won’t be able to get much more work done on Brassica for some time.
- The online version has been largely brought to parity with the desktop version, and now includes the paradigm builder and live results view, amongst other features
- Brassica can now process MDF dictionary files (as used by tools including SIL Toolbox and Lexique Pro)
- Rules can be marked as sporadic or otherwise nondeterministic, in which case both the result of applying the rule and the result of not applying the rule will be visible
- Three example sound changes are distributed with both the desktop and the web version
- A precompiled binary for Linux is now distributed (currently only the CLI interface, alas)
- The CLI interface has been wholly updated to improve ease of use (especially on Windows)
- Font customisation for both sound changes and words is now allowed in the desktop interface
Note there is one minor detail left to resolve: the Brassica API has also been wholly revamped, and is now actually usable for the first time ever, but alas, I do not have the permissions to upload the library to Hackage yet. I will let you know when it is available there.
As for what’s next… well, I’d love to implement dhok’s idea of toggling blocks on and off, but even more than that I want to find a better solution for suprasegmental and autosegmental stuff, because the current ‘features’ system is horribly confusing. I also want to add some way of backreferencing between categories, but that’s less of a priority unless anyone can come up with a sound change which absolutely requires backreferencing to work. (In fact, this goes generally: please send me any sound changes you can’t implement in Brassica if you find any!) That being said, I’m very busy at the moment, and probably won’t be able to get much more work done on Brassica for some time.