6.26 周四

早上:肯德基 1.画画 上午: 1.画画，画的精神大崩溃 中午:吉野家 下午: 1.漫无目的的过了，打了打游戏，奥日、死亡细胞、空洞骑士 晚上吃的，和家里人下馆子 晚上: 1.看了去年9.13-9.15的嘟文 2.遛达回家的

8点多躺下 9点多在玩肉鸽 10点出头睡的

6.25 周三

早上:吃的罗森寿司+周二多买的一瓶咖啡+魏家凉皮的粥 早上:梳理自己？刷星屑（这个有）？，忘了 上午: 1.多邻国，卷 2.死亡细胞 中午:达美乐披萨，意大利面+奶油蘑菇汤+鳕鱼粒+咖啡+小热狗（没吃完，辣酱太辣了，还有我点多了） 下午:去医院取报告 因心情烦躁大量嘟嘟 四点到家，看了得有1小时视频（可能也未必到，期间吃西瓜，刷星屑） 晚饭:吃了一角饼配了4瓣蒜+几片玫瑰肠 晚上: 1.画画 2.同人尝试失败，又发现大问题，不会上色阻碍了我，要去学

6.23 周一

早上: 来上班的路上就一直刷嘟嘟，偶尔发一两条自己的想法 早上喝的瑞幸咖啡+吃的瑞幸的面包 上午: 1.做多邻国，任务做完了，经验刷到500多了 2.刷嘟嘟，在星屑表达自己 中午吃的吉野家 午休:在星屑表达自己 下午: 1.在星屑表达自己 2.玩fsn 晚上吃寿司郎 晚上: 1.玩星屑 2.画画 画了有1小时

6.24 周二

早上: 1.刷星屑 2.欣赏自己昨晚的画 早饭:罗森寿司+星巴克咖啡（瓶装）+微凉凉皮的粥 上午: 1.画画 2.多邻国 中午:吃的手工水饺 下午: 1.画画 2.死亡细胞 晚上:吃的西瓜，意犹未尽 1.画画 2.洗了头 3.画的效果不佳，很早就睡了，大概9点多

6.22 周日

昨天:感受很好，很充实，我觉得我对人生的理解与感受又有突破了 早上: 1.心情不好，我去排解了，排解完了 2.在星屑梳理自己的感受并发表大ego 上午空腹在医院抽血，抽了一上午 吃饭前买了瑞幸，果蔬汁 中午吃的回转寿司，寿司+咖喱乌冬，非常好吃的一顿饭，给我吃爽了 下午睡了3个半小时 晚上吃了土豆丝+杂粮粥 1.自从睡醒后一直玩星屑，表达自己+间歇摄入网友动态 2.吃完饭又在呜呜表达口味 3.到睡觉的点了（大概有9点半左右）开始更新光遇，大更，更完了带小号跑 4.玩着光遇开始伤春悲秋 5.不继续玩了，下了，又在星屑表达自己，陷入回忆，拾取回忆中美好的碎片

180天发9首歌的创作过程分享（3） 4.《Pulse of a Dizzying Glow》（Trance） https://open.spotify.com/album/5qhgeeTQdRnXP2DLyOdw3V

已经忘了是怎么决定第四首歌做trance的，大概是想着除了pop还有什么曲风是可以比较突出人声的吧。在这之前一共也没听过几首trance，以至于参考歌找得都不太准，找的三首参考歌只有一首是真正的trance（如果有很喜欢这种曲风的同学读到这里，私密马赛）。

说到参考歌这个事情我应该是一个反面教材。理论上确定要做什么风格的时候应该把参考歌也定下来了，而我经常歌做完了才想起来：忘找参考歌了。然后根据已经做出来的东西去找相似的参考歌（倒反天罡……）。

后来我反思这个事情，觉得可能是因为参考别人的歌对我来说不够直观，所以内心有点抗拒。更直白点说，扒歌水平不够，复刻不出来。

当然做之前还是会去听一些这个曲风的东西，但谈不上参考，只是找找感觉，试图获取对这个曲风的简单印象而已。能抓到一点印象已经烧高香了。真想快速学习怎么编写的话，还是找点视频教程来看比较适合我。

看视频的时候总是抱着一种我能偷点什么的心情，这是一种兼顾轻松和高效的心态，推荐大家试试看。如果你想的是我要学习了，那可能容易累，甚至很难开始。但如果想象自己是来偷东西的，那就不一样。首先你得快速浏览，不能太纠结，从一大堆视频封面标题里面选一两个最顺眼的点进去。然后你在看的过程中会有一种，往好听了说叫求知若渴，往难听了说叫急功近利的兴奋感。最后，如果偷到了东西（马上在自己的工程里试一试），会格外开心。如果没偷到，就当跑一趟锻炼了身体，增长了见识（。）

不过基本上看完一个视频不太可能什么收获都没有，或多或少总有一点你之前不知道的事情，只是能不能立即应用的差别。所以我很推荐看完一个视频觉得有帮助的话就把感想记下来顺便收藏一下，有点像读书笔记的概念。

做这首歌的时候已经是2月份了。其实毕业后的180天真的过得很快。感觉刚毕业没多久就到元旦了，接着就过年了，过完年就2月了，而4月就截止了……我记得我当时非常急躁。因为觉得照这个速度下去肯定做不完9首歌。加上trance又是一种很狂躁的曲风（根据我片面的理解），所以我的状态加倍狂躁。vocal录得不好，混音做得也不仔细。属于比较勉强的过审。过审的时候是半夜快两点了，立刻关了电脑倒在床上，心情是我需要改变路线了……

（真的很仓促，混音和母带的时间记录都是不准确的……）

5.《Transparent Daydream》（House） https://open.spotify.com/album/1plEsqHIpCBRFZ4bvqjHB5

做完第四首歌，我非常确定要让脑子冷静点，所以打算做一首风格清新一点的。还有就是非常重要的：累了，这次不写词曲也不唱了，省时省力……（。结果后面好几首都这样，这就是人的惰性吗、、、）

这首歌的主题和曲风基本上是同时确定的。主题或者说画面、场景、氛围这些东西对我来说蛮重要的，不早点确定下来的话，会有一种不知道在写什么的迷茫。如果知道了想要描绘什么样的画面，那么在选择音色、写旋律甚至找fills采样的时候都会比较有目标感。

这首歌的 bass pattern 我还挺满意的，而且没怎么试就写出来了。但还是不太自信，在副歌部分非要写另一个（难听的）旋律。队长说没必要，还不如这个好的 pattern 捅到底。副歌部分原本还有一个音色，因为我觉得副歌需要热闹一点，加上去之后又不太满意，删了很多音符，音量调小了，但还是不太满意。果然老师说听着很乱，我就直接删了。终于舒服了，真没有必要强行追求所谓的热闹。

这两件事让我意识到什么叫画蛇添足。如果一个东西你加上去改半天还是觉得不太舒服，可能最后还是要删掉的。同时我也确认了做过几首歌之后我的感觉有变好一些：我觉得好的部分被证明是好的，我觉得不太有信心的部分被证明确实需要删掉。

这是我第一次大量用人声采样做歌，在挑选采样的时候也费了一些工夫。出于省事的考虑我从一开始就打算用讲话而不是唱歌的采样。也是为了避免听众搞不清楚 FanDog 唱歌到底什么声音。但后来还是有朋友听了这首歌之后问我，你的声音为什么变得这么有磁性。我说因为那是别人的声音(○´･д･)ﾉ

这首歌从2月中旬做到2月底，总共用了29个小时，算是挺顺利的，让我觉得还是有希望做完9首的，并且接下来还是采取做纯音乐的策略（逐渐偏离了专注Pop的人设）。不过我还是想多探索一些曲风，于是又开始找什么曲风是我没做过并且听起来不太难做的，然后把魔爪伸向了Jersey Club。

180天发9首歌的创作过程分享（2） 2.《Halo and Strings》（Pop） https://hemrecords.bandcamp.com/track/halo-and-strings 这首跟上一首一样也是十月中下旬写的。不过因为上一首花了太长时间，这首真正开始编曲已经是接近年底了。中间还有十天出去玩了完全没开电脑。

其实我内心有点抗拒编这首歌，因为不知道怎么编。风格跟上一首很不一样。确切地说，我对慢歌的编曲有一种恐惧感。虽然这首也不算特别慢（BPM 80，上一首 100）。

写歌的时候没想那么多，没有刻意说一定要写什么样的风格，写出来是什么样就是什么样了。写完感觉还不错，但是编的时候非常发愁。（现在想来，这不完全是能力的问题，主要还是缺乏经验。）经常望着空空的轨道不知道该干嘛，抓耳挠腮。发愁到即使没坐在电脑前面也在想这个事情。

在这期间有一天晚上我去看演出，不知道怎么就走神了开始想编曲的事情，突然觉得啊要不这首中后段再进鼓吧……还可以找某种鼓的音色试试（然而最后被换掉了，这是后话了）。怕忘了就记在手机里面。

出去玩回来的高铁上也在想这个事情，盯着车窗发呆的时候突然想出来第一遍主歌的时候可以唱一句空一会再唱下一句（显得比较舒缓），间奏之后的主歌可以一句接一句连着唱（显得比较紧凑），这样可以制造出差异。

想出来这个做法我非常开心，虽然在有经验的人看来也没有多特别，但那种“就这么办，应该不错”的感觉是令人兴奋的。

所以其实有很多思考的过程发生在日常生活中，大脑的后台一直在运行，才会有灵机一动的感觉。

编这首歌的过程中还有一个体会就是，如果你觉得这一段太空了，少点什么，那就写点段旋律放上去。

这好像是一句废话……但如果你跟我一样，经常不自觉陷入对着电脑长时间干想什么都没推进的状态，可以试试。印象中编间奏的时候就发呆了很久，没有进展觉得浑身难受，但真的开始写的话，几分钟就写好了，试了几个音色，改了几个音，就觉得哦这好像就可以了。就有点不知道踌躇了那么久是在踌躇什么（可能脑子还在开机）……

这首提交审核以后要改的也不算多，但是鼓又要换掉，这让我陷入了沉思（。）还犯了一些低级错误比如某些轨道的音源掉线了，不出声，但我没发现，就那么导出去交上了（Arturia 修修你们家那破网吧）。

照例放上用时统计。其实编曲时间跟第一首差不多。差别主要在修改时间上。这一首的鼓比较简单，改起来比第一首快很多。而且做第一首的时候处在一个什么流程都是第一次摸索的状态，所以就是会慢一些。大家做第一首歌的时候也多给自己一些耐心吧。

这首做得差不多给队长听的时候，他说很好啊很厉害啊为什么之前作业里面感觉没有体现出来。

这是一个值得思考的问题，但直到现在我也不清楚。可能比起限时完成任务，我更擅长自由创作。可能我反射弧太长，开窍比较晚。但我想说的是即使作业做得平平无奇或者有一些缺憾犯一些错误也不要灰心，这并不代表你以后做不出歌来。（但是作业一定得做。我一次也没落下过♪(´▽｀)）

这两首都是 HEM 子厂牌，当时我还想，我什么时候也弄一个 Underground 啊。没想到第三首就来了(/≧▽≦)/

3.《Birthday Cake》（Pop） https://hemrecords.bandcamp.com/track/birthday-cake

做完第二首歌之后我想试试别的曲风，想写点简单欢快的东西。记得毕业的时候队长说House比较容易（队长还说他觉得Pop最难……）就打算做个House试试。

尴尬的是做出来还是Pop味（顶多有一些些House元素吧）。这件事告诉我们听得少真的很难做得像样（后面我还会一遍一遍证明这个道理）。

House里面人声并没有那么重要，所以词曲就简单写写，一个小时就写完了。句子很短，旋律也很简单。当时正在看《想见你》（到现在也没看完），顺手就把里面过生日许愿的内容写进歌词里面了(:з)∠)做前两首歌实在是有点费脑子，这首就是简单就好，我想歇歇（。）

编曲的时候虽然还是会有迷茫的感觉，不过有了前两次的经验已经比较知道要怎么做，还看了一些速成视频比如这个 https://www.youtube.com/watch?v=qwU60MeK_b4 （还蛮喜欢这种看了就能拿来用的东西）。

在写词曲的时候没有想得很清楚，把 vocal 录好了以后才意识到还得写点别的，不然撑不起一首歌。基于歌曲的主题很容易就想到用铜管类的音色，找了几个差不多的叠在一起，然后写了一个旋律改了改，印象中没有花很久。第二次出现的时候需要在第一次的基础上有一些变化，就把第一遍的东西复制过来稍微改了改。

有了这两段就觉得这歌基本上可以了，有样子了。写完就确认了它们才是真正的副歌。其实写起来也没费什么劲。

感觉做歌的时候还是要有点即兴的心态，想到点什么都可以试试。不是特别难听的都可以先保留在工程里，慢慢你的工程就丰富起来了，到时候再删改调整会容易一些。

而且很多时候即兴的东西，效果不见得比处心积虑写出的东西要差。比如这首歌第3：07和3：14由铜管演奏了两次的那个旋律，就是一种意犹未尽的感觉所以随手写的。一开始只是放在旁边也没打算用，后来编到结尾突然看到这还有个clip，放进去试试，觉得不错就用了。

这时候又觉得其他地方有点空，想加点fills，又懒得写新的（喂），就把它又复制粘贴摆到空的地方再换个音色。这个小旋律在整首歌里面出现很多次，而且有好几种音色演奏过它，都是即兴+犯懒的结果，但我挺满意（。）。像3：28出现的那三个音符的fills也是，我印象很深因为就是某次觉得差不多了收摊了睡觉了，哎呀再加一点点就一点点，鼠标点两下，哎挺好……复制粘贴，摆一摆位置，就留下了。一些小打还有那个开香槟的fills都是基于“诶要不这里这样一下，感觉会很好玩”的试试看心态放进去的。

关于fills其实第八十几节课就讲到了，后面的课程也经常会提到，但我是做到这首歌才觉得好像能够把握这个东西了。从老师上课讲，到你自己做（但是不太理解），再到你自己做（并且清楚自己在干嘛），这需要一个过程。

上课也好笔记也好，都是老师在用演示或者文字的形式传递他的经验（而且是已经经过浓缩的），那是他的经验，不是你的。就算你全部吸收了，那些经验也只是以视频或者文字的形式储存在你的大脑里，而不是以真实经历的形式储存在你的大脑里。只有开始做作业，你才真的开始积累属于你的经验（但不够多）。等到有了做几首歌的经验，再回去看笔记，你会发现笔记里面说的东西，你都有了自己的亲身经历与之对应，那种深刻程度是看十遍笔记也无法获得的。

还有就是不要在一个东西上死磕太久，因为你的首要目标还是完成这首歌。如果某项工作你做了很久还是没什么进展，自己也烦躁了，那就放一放，干点别的。找不到很满意的音色，先用个差不多的，开始写旋律吧。旋律怎么写也不满意，那就看看鼓可以怎么改改吧。如果今天就是什么都不顺，那至少可以摆几个效果器做一点基础的混音吧。主打一个来都来了工程都打开了做点什么事情再走吧。反正我是这么调节心态的。

也不排除你就是那种适合死磕的选手。那你可能有你的工作哲学。重要的是找到适合自己的方式。在毕业之前就找到的话很幸运，也可能像我做了几首歌才能找到（但继续做下去，积累到某个阶段应该还会有新的变化，那也挺好的）。巧合的是上课期间我也是做到第三首歌那次作业上了绿色榜单。大概我就是需要一点积累才能有手感吧。

因为有前两首歌的教训，这次我提前问了队长，鼓组怎么样，是不是又要换。队长说，要不还是换一个吧。我苦笑……队长说找一个跟参考歌差不多感觉的换上去应该就可以。事实证明确实如此。

不过这首歌出现了前两首都没有的问题，那就是失真和click。修改时间的七八个小时，大概有一半是我在竖着耳朵听这次到底失真没有。一边听一边纳闷为什么前两次都没有，这次却有了。为什么出现了，我却没听出来。逐渐变得疑神疑鬼。最后实在是脑子耳朵都累了，好在提交之后没什么问题并喜提Underground（那天正好是大年初一，对于不喜欢过年的人来说还挺安慰的）。

这首歌从开始写到过审只用了两个星期，我自己也没想到能这么快，毕竟前两首都折腾了一个多月。也是做了这首歌之后我意识到我可以更多地信任自己的临场发挥（意思是不知道要做什么但打开Live就是一顿做）。当然也不是每次都好使，之后有好几次灵机一动想出来的东西在提交审核后被整段毙掉（汗），但总体来说成功率高于50%所以我会继续灵机一动 (∩_∩)

180天发9首歌的创作过程分享（1）

截图是总体的情况，是我根据iHour（一个统计时间投入的app）的记录整理的。九首歌里面有四首是Pop曲风，所以下文会含有一些词曲创作的体会。中间连着五首都在做别的曲风，原因后面会说。应该会聊到一些比较细节的东西所以欢迎配合歌曲食用……（打广告）

不过这个记录并不完全准确，尤其是第一首歌如果算上写歌和看视频教程的时间，投入时间应该不少于80个小时。从第二首歌开始的记录会比较准确。

我也没什么基础，前几年学过一点乐理，小时候喜欢听华语流行（汗颜），但听歌量非常小（再次汗颜），因为流行歌总是爱来爱去，被家长发现会被骂一顿。我只能托学校门口小卖部老板帮忙买正版磁带偷偷听（时代的眼泪，那时候小卖部还代充Q币），几盘磁带听一个学期，大概就是这种听歌量（再三汗颜）。

扯远了，下面我按时间顺序分享一下九首歌的流水账。

1.《Bird of Paradise》（Pop）

https://hemrecords.bandcamp.com/track/bird-of-paradise

九月，距离毕业还有一两个月，开始发愁毕业之后做什么曲风。虽然上课讲过很多曲风，HEM的视频也讲过很多曲风，但在我的概念里，很多年来，我觉得音乐只分两类：流行音乐和其他音乐（如有冒犯，对不起）。

所以我想还是先从自己熟悉的地方做起，于是有意识地开始写点东西。有的人习惯先写词，有的人习惯先写曲，有的人词曲一块写出来，这个只能自己摸索哪种做法适合自己了（对这方面感兴趣的朋友可以看看林海主持的访谈节目《六重奏》，非常有东西）。

我觉得重要的是经常去执行写作这个动作本身，至于写出了什么是次要的。不要觉得写歌是很严重很有负担的事情。你就拿出一张纸，写下这一秒钟脑子里出现的第一个词就可以了。你说我脑子里什么都没有，那你可以观察周围。实际上这首歌就是这样开始的。

那天是一个阴天，我看着天空发呆，心想，我得写点啥，我写点啥呢，怎么想的就怎么写吧：I like sunny days/I like rainy days/But I hate cloudy days。

你可能会说，这是幼儿园小朋友的英文儿歌吗。但我觉得要暂时把心里那个批评自己的声音关掉。现在要做的只是创造和记录，批评和修改是下一个阶段的事情，不要混在一起。

写完这两句词，我觉得还挺好（很容易满足），就试着哼旋律，过程已经不太记得了，印象中只哼了一两遍就觉得可以，就它吧（真的很容易满足）。

还是那句话，不要把它当成一个很严重的事情。不要觉得我今天坐在这得写一个很厉害很厉害的东西才行。如果量没有积累到一定程度，基本上是不太可能的。这样想只会给自己增加不必要的压力。

这里要插播一个小故事，很多年前《无与伦比的美丽》这首歌流行的时候（感觉这首歌比一些同学年纪都大），吴青峰说这是他的第98号创作。我就觉得，即便是吴青峰这么厉害的人（如果你不觉得他厉害那可以直接看下一段了 = =）都要写到将近一百首歌才能写出《无与伦比的美丽》啊！他也不是一出生就很厉害的！我平静了。我可能得写一千首才能写出属于我的《无与伦比的美丽》吧。所以我得赶紧写，运气好的话说不定第五百首就写出来了呢（。）

所以说，建议的心态是，有空就写点，最好每天都写（其实我也做不到），写的时候不要批判自己写的东西，写累了就放那，改天再拿起来看。如果写出了好东西算我走运，写得不好那也完成了一次练习，非常厉害。

话虽这么说，我坐在桌边也是经常什么都写不出来。这时候我发现一个很有趣的现象，就是灵感经常在做一些日常重复动作的时候冒出来。上厕所的时候、坐车的时候、洗菜的时候、躺床上快睡着的时候。总之就是负责思考的那部分脑子真正放松的时候。

那你说以后我就在厕所写歌了行不行？不行，因为一旦把厕所和写歌联系起来，大脑到了厕所还是容易紧张。人好像很难刻意去放松，但我们可以及时把放松时候闪现的灵感记录下来（我选择手机自带的录音机，录完之后记得随手重命名一下方便日后查找。名字可以是你觉得这段旋律有怎样的情绪，或者你想到的具体画面，甚至是某个具体物品之类的）。

Anyway，到这里我已经有了两句歌。而且觉得旋律不错，立刻马上就想重复一遍。歌词也有很明显的话头——因为抛出了一个观点，那么接下来解释一下原因是很自然的。于是两句马上变成了四句！好爽，感觉歌在自己写自己（。）

但其实前两句跟后两句有一个本质的区别。写前两句的时候我只是随便那么一写，完全不知道这首歌是要写什么主题。没有确定题目，也没有画面，这首歌什么感情也不清楚，只是记录天气和我的感受而已，我不知道它要去哪儿。

而后两句特别是最后一句写出来之后，大概的人物关系和主题已经出来了。主题（歌词内容的主题，或者说立意吧。不是作曲上说的那个主题）对于流行歌曲来说格外重要。但这也不是我一开始想好的，后两句怎么写出来的我也不是很清楚，只是凭感觉。它肯定还有很多种写法，不一定这个方向就是最好的，但我选择跟着感觉走了。

不过所谓的感觉并不是虚无缥缈的东西，它是你过去所有积累、思考、听歌、写歌的总和。就像所谓的灵感也不是天上掉下来的，是你潜意识里面在思考的结果，只是你自己感觉不到。好像大侦探办案的时候冥思苦想好几天没有头绪，旁人无意间说了句什么，啪，案子破了。虽然旁人说的话很关键，但没有那几天的冥思苦想（和大侦探的智商），说什么也白搭 = =

写到这居然已经两千字了，感觉才开了个头。我尽量捡重要的说……

总之这首歌就这么挺满意地就写下去了，然后终于到了写副歌的环节。我承认对于这件事不论当时还是现在，我还是有相当的心理阴影。

后来我看《六重奏》里面陈耀川说，他习惯先写一首歌里最重要的部分（也就是副歌，负责记忆点的那块），这部分写好了，立住了，其他都好办；如果你从头开始写，写到副歌会很容易出问题。

他说得非常有道理。

虽然《Bird of Paradise》这首的副歌挺容易就写到了自己满意的程度，但写副歌（或者说写pattern）这件事对我来说还是很吃力。

在写这首歌之前的几天，我曾经记录了一段非常喜欢的旋律，也是上厕所的时候自己冒出来的，赶紧记下来，哇，好喜欢，真的是我自己写的吗，不会是听了别人的歌无意中记下来的吧。就喜欢到这种程度。

但这首歌直到现在也没有发表，因为写了好几版副歌都不是很满意，觉得它配不上我这么喜欢的主歌。

虽然没有人规定副歌一定要比主歌好听，但（华语）流行音乐的听众还是普遍有这样的期待，（华语）流行音乐的创作者还是有这样的自我要求。（可这是一首英文歌啊 = =）

用英语写歌这个事情还是要提一嘴。不是我英语好，恰恰相反，因为英语不好所以才敢写。我没有办法想象我写的英文歌词变成中文的样子，大概会觉得有点非常肉麻（尤其是第二首歌，等会说）。但是用英语就没什么心理包袱。也许是母语羞耻，也许是英文本来就比中文直接一点，不管怎么样，如果你发现某种语言确实阻力比较大，可以试试别的语言。你甚至可以自创语言，或者混合好几种语言，参考魏如萱的若干金曲。

怕出错的话可以问问GPT，我不是说让它帮你写，而是你写得差不多了之后问问它有没有语法问题。它会称赞你的（优秀的写歌鼓励师），还会提一堆修改意见生成一堆有的没的，不用管，跟它说如果没有严重错误我不想改了，它就老实了。

说回来写副歌的问题。我觉得心态还是要放平，多写就完了，还有就是多看别人的教程或者创作谈，比如https://www.youtube.com/watch?v=1bkjEO_Zj2g 这种视频我就非常爱看摩多摩多……还有比如马世芳的广播节目。找你感兴趣的歌或者歌手相关的就好，一定会有收获的。

总之《Bird of Paradise》这首歌算是非常顺利地写完了，写了一两天改了一两天的样子，录音的时候还改了一些歌词。录音也挺顺利的，就是被子里面太闷热需要不时出来透气。

然后就到了编曲环节，记录的编曲时间是29小时，这个时间应该是没有包含观看各种YouTube教程的时间，也没有包含盯着电脑发呆感到绝望的时间。

俗话说万事开头难，编第一首歌的时候真的是挺迷茫的，编了一小时，工程只增加了两个小节，是常有的事。又编了一小时，期间没干别的事，就把这两个小节删了，工程恢复到了两小时之前的样子。

但即便是这样也不要放弃啊！看起来好像两个小时什么都没干，但其实你是有在思考的，有在痛苦的。接下来你可能半小时编出来一堆东西，这里面也有那两个小时的功劳。我觉得这一点非常重要。创作过程很可能不是线性的，不是匀速的，你很难掌控它，但有一件事是确定的就是你要做下去，痛苦也好，大脑空白也好，不做下去的话什么都不会发生。

其实编曲需要的知识和技能我们上课都学过了，但怎么应用到自己的作品里面，还需要一个适应的过程。你其实已经会了，只是还无法很熟练地把那些东西拿出来摆在它应该在的位置。所以第一首歌用的时间长点也不用焦虑的。熟练了就会越来越快。

编了一段主歌+一段副歌之后终于鼓起勇气发给了我的队长小蛇，他说很好，我非常开心，编后半段的时候就没那么迷茫了。再后来发给老师，鼓组要整个改掉（汗颜），其实听了很多遍我已经感觉不出来我的鼓哪里有问题了，不管换成什么新的都觉得不对，但还是硬着头皮改，然后就过审了。

老师说继续做有vocal的歌，这首vocal表现挺好。我觉得很受鼓励，也继续做了一些，但遗憾的是后面的歌老师再也没说过vocal挺好了（。）

今天先写到这，后面的歌明天再说，我需要组织一下语言嘿嘿。

附上这首歌的具体时间记录。

用Hugo自建了个新博客，链接是：https://nanako.icu/

所以这里就不会再更新了呢（os: 怎么过了几个月了才说

关于二月与三月，我总算是忙里偷闲，随便写上一点。

春天的光很淡， 淡得像一些绿色的水。 春天的光很轻， 轻得像一片飘浮的叶。

实际上我并不太想回想二月，二月对我而言太过痛苦，出成绩之前的焦虑真的要死掉，第一次感受到铁板鱿鱼的感受，但铁板鱿鱼翻来覆去有烧烤香，我翻来覆去就是失眠，果然人和鱿鱼还是差别太大了。在这样的蒸煮烹炸下我最后还是等到了成绩，等成绩的时候觉得出分太慢，等看到成绩又觉得它如同断头台一样迅速地宣判了我的死刑。于是我就这样如无头骑士一样去找工作了。

带着微湿的气息 天空像一张晾不干的宣纸 灰蓝色渗透进每一寸风里……

从出成绩到过面试只用了三天，我朋友说这么顺利是老天爷在推着我走，好吧感谢老天爷，不过我还是希望它能推推其他方面。三月份我要开始工作，我大概有一年的时间没有工作了，突然又要回归岗位我不太乐意，真的是讨厌上班啊，我有厌班症！不过起码第一周我还是可以玩过去的，去见了见朋友，吃饭逛街，帮朋友摆阵……好久没有这么放松，然后就这样坐着卧铺来到了工作的地方。

卧铺的设计，真的很差。我为我不太灵动的攀爬道歉，但是你卧铺就没有99%的责任吗。

到了学校就发现比想象中的更忙，除了自己要带的物理，还要多带一门综合实践，其实就是找视频给学生看，但是因为刚来不太清楚搞得自己有点像无头苍蝇一样手忙脚乱（难道我就要这样无头下去）。课排的很满，晚自习也很晚，真的很忙，不过对教师的管理没那么严还是让我松了一口气。

虽然很偏僻，但是不查教案，只打卡两次，大小周能双休一周，免费住宿，食堂补贴，每天发零食和水果，同事和领导人很好，工资还高。我要为了赚钱拼了。

就这样我还能跑团我是佩服我自己的，虽然晚自习很晚，但我有充沛的毅力进行娱乐活动。顺便一说我又在模组里睡觉了，我在每个模组里都在睡觉，我以后出道就要叫睡觉大仙。但玩游戏的时间几乎下降为0啊！趁着这周末双休我要狠狠打游戏。（前提是我把我房间收拾好）。

写着写着发现三月的文风和二月明显不一样啊，三月虽然很忙但明显我活过来了？！虽然才刚刚开始，但是一个人住的快乐已经有点冲昏我头脑了，希望接下来能好好做自己想做的事吧，至于这一周，你就让我玩玩吧。

做镜牢任务顺手认认，信息来自游戏本体和wiki

斩击

等级	名称	效果
Ⅰ	手术用刀	[4 5++]拥有斩击技→下回合+(斩击技数 +1)层迅捷
Ⅰ	虚饰的和平	[5 6++]速度差≥3(2+)→斩伤+15%(20%+)
Ⅰ	磨损的砥石	[3]斩击技攻击等级+(斩击技数)(max+3) 攻击斩抗＞1.0单位时→伤+(5+目标的斩击抗性×10)%(max+25%)
Ⅱ	梦中的电子羊	紫/斩击击杀→2t斩威力+2 紫完全共鸣→战斗开始全体攻击防御等级+2
Ⅱ	裁缝用剪刀	[4 6++]硬币数≤2的斩击技→拼点威力+1，伤+10%(15%+ 20%++) 单币拼点威力+1，伤+20%(25%+ 30%++)
Ⅱ	拐杖短剑	斩击（7协全部攻击 弱点分析+ 拼点威力-1++）拼点胜利→下回合目标防御等级-2(每t每人1次不叠加) 关卡开始（奇数回合+ 每回合++）7协+拼点威力(除自身外7协的友方单位数/2)(max2)，（拼点胜利伤+20%++）
Ⅱ	决意	斩击技≥2→t1拼点威力+1，t2起+1(2+)速、拼点(最终)威力+1 4协+hp至上限的75%(50%+ 49%++)但受到的伤害与恢复-50%(75%+)
Ⅲ	宣判之刻	[3 4 5+ 6++]单方面攻击斩伤+10%(12.5%++) 拼点胜利斩伤+(40(50++)/剩余硬币数)%
Ⅲ	云纹鹤颈瓶	斩击1技能（黑云会所有斩击 橙+ 所有攻击++）拼点威力+1，命中时目标攻击等级-2 回合开始时，黑云会威力+1，攻击命中并+流血强度/层数时自身+（1/2++）呼吸法强度(每回合每人最多4次 6+ 8++)
Ⅳ	切开的记忆	[1 2]斩击技基础威力+2，硬币威力+1(包括E.G.O) 斩击拼点胜利伤+30%，该技能命中时，每hp-5%伤+5%(max+20%)

The problem: expression parsing with operator precedence

Human-readable languages tends to have a lot of infix operators with various precedences. In CFG, this corresponds to an annoying list of different rules, e.g.:

add : add '+' mul | add '-' mul | mul
mul : mul '*' atom | mul '/' atom | mul '%' atom | atom
// etc.

With good error recovery necessary, normal parsing methods would need to repeat the rules. Assuming it's possible to collapse the operators, it's still necessary to name each rules, and repeat the names three more times: for recursion and in the operation of one level lower priority as operand and fallback.

To make things worse, since operations like subtraction are not associative, left-associative operators (i.e. the leftmost subexpression is evaluated first) is inevitable, which also requires special handling in parser generation methods like PEG or LL, and naively implemented parser combinators.

So there's need for a better parsing strategy, which allows us to write less rules, and handle the details in parsing automatically. One solution is Pratt parsing. It not only provides a strategy to easily designate the precedence and associativity of infix operators, but is also capable of processing both prefix and postfix operators, with a little extension.

The idea and an implementation for infix operators

The key idea of Pratt parsing is the binding power of the operators. In an expression of atoms and infix operators, the atoms can be seen to be separated by the operators, e.g. in 1 + 2 * 3 - 4, each operators have exactly two atoms at both end of it, and the atom must be at the end of the subexpression, which is an operand of the operator.

In other words, the operands of all operators are “bind” to their ends. Thus we can imagine that in case when two operators are “fighting for” the same operand, the operator binding tighter wins, and associate with the operand first, then the second operator. E.g. in 1 + 2 * 3 - 4, * wins in both ends, and gets 2 * 3 forms a subexpression first, then + and -, and in 1 + 2 * 3 ^ 4, * loses to ^, but wins +, so 3 ^ 4 gets bound first, then 2 * (3 ^ 4), + comes the last.

That's the idea: designate each operator with a binding power, and when two operators fight, make the one with the higher binding power win.

Surprisingly, this mechanic can also be used to deal with associativity. As a clarification, associativity only applies when two operators of the same precedence chains, e.g. in 1 * 2 + 3 * 4, the * wouldn't be burdened with associativity, since they binds with their atoms eagerly, and don't fight with each other, but in 1 + 2 * 3 - 4, + and - would fight with each other, thus their associativity applies.

The solution is the same: since associativity involves determining the operator at which side wins, we can designate the operators' ends with different binding power, thus operators with the right end a stronger binding power would have the operator at the left win, and therefore is left associative, and vice versa.

Now it's time for the implementation. There's a straightforward introduction and recursive implementation in this blog (which may be better than this one x x). Here we give an implementation by stack and a loop, with the chumsky parser combinator library, and we'll explain the algorithm later:

// `Oper` is the type of operators, `Expr` is the type of expressions.
// `atom` is the parser to parse an atom, and `oper` is the parser to parse an operator.
enum State {
    Expr,
    Oper,
}
custom(move |inp| {
    let mut ops: Vec<Oper> = vec![];
    let mut exprs = vec![];
    let mut state = State::Expr;
    loop {
        // Read the next token according to the state
        let Some(op) = (match state {
            State::Expr => {
                state = State::Oper;
                exprs.push(inp.parse(&atom)?);
                continue;
            }
            State::Oper => {
                state = State::Expr;
                inp.parse(oper.or_not())?
            }
        }) else {
            break;
        };
        // Bind the previous operators
        let cp = op.bindpow().0;
        while let Some(pre) = ops.last().copied() {
            let pp = pre.bindpow().1;
            if pp < cp {
                break;
            }
            ops.pop();
            // there's no better way of popping multiple elements from a Vec in Rust ><
            let Some((r, l)) = (try { (exprs.pop()?, exprs.pop()?) }) else {
                unreachable!()
            };
            exprs.push(Expr::Op(pre, Box::new((l, r))));
        }
        ops.push(op);
    }
    // Finally: collect the rest items in the stack into an expression.
    // Since they didn't get bound before, their precedence must be in ascending order,
    // binding reversly is correct.
    let Some(mut res) = exprs.pop() else {
        unreachable!()
    };
    while let Some(op) = ops.pop() {
        let Some(v) = exprs.pop() else { unreachable!() };
        res = Expr::Op(op, Box::new((v, res)));
    }
    Ok(res)
})

Here we have maintain a state machine, which has the following states: the initial state, the previous item being an operator, the previous item being an expression, and the final state. Since we are parsing a sequence with atoms first, and operator and atom alternating, the item to be expected at each state is certain. Since the states are only used to fetch the items, we merged the states.

Now that we have the item sequence, we need to compose the sequence into the result expression.

Consider the information we want and we have: we want to know when to merge the expressions around an operator; and at each step, when we get an atom, we get nothing, since we already know it would be there; and for each operator, we can only know whether it can bind the expressions around it when the other two operators around it are known. Luckily, when we get an operator, we've already known all operators on its left, so we only need to get the operator on its right to know if the operator can be bound.

At this step we can have a figure about the algorithm: when we get an operator, check if the operator on its left can be bound, and regardless of whether the last operator binds, store the current operator and wait for the next operator. When we should store multiple operators, it's obvious that their binding powers should be ascending, since if not so, for the decreasing operator, all previous operators with stronger binding power should be bound before it.

Thus in the rest of our algorithm, we maintain a stack for the operators and expressions, ensure the ascendance of the operators before pushing, and finally bind all the rest operators in the stack: since they're ascending, binding them from later to earlier is correct.

That's all.

Patches for prefix and postfix operators

Despite being true in most languages, it's false that prefix and postfix operators must have higher precedence than infix operators. A seemingly ridiculous but applicable example is the if expr then expr else expr structure, where if can be a prefix operator, and then and else are postfix, such that the whole structure is actually parsed as (((if expr) then expr) else expr).

Our analysis above still applies here: a prefix operator must fight with the infix operator after it, before it can bind to its operand, due to the precedence rules, that's also true for postfix operators, but the directions are reversed. Thus for prefix operators, we only need to wait for the next operator and compare their binding powers, as what we've done for infix operators; the only difference is that instead of popping two expressions, we only need to pop one element to bind to the prefix operator. For postfix operators, things are better —– they can be bound instantly when read, without entering the stack.

Conveniently, we can note that in an AST with reasonably design, whether a operator is prefix, infix or postfix is inherent, thus we can just ask for themselves and store them in the same stack:

custom(move |inp| {
    let mut ops: Vec<Oper> = vec![];
    let mut exprs = vec![];
    let mut state = State::Expr;
    loop {
        let Some(op) = (match state {
            // Prefixes are processed like exprs, except that they don't change the state.
            // Also, they should be pushed to diff stacks.
            State::Expr => {
                match inp.parse(&atom)? {
                    Atom::Expr(e) => {
                        state = State::Expr;
                        exprs.push(e);
                    }
                    Atom::Op(o) => ops.push(o),
                }
                continue;
            }
            State::Oper => {
                state = State::Expr;
                inp.parse(oper.or_not())?
            }
        }) else {
            break;
        };
        let cp = op.bindpow().0;
        while let Some(pre) = ops.last().copied() {
            let pp = pre.bindpow().1;
            if pp < cp {
                break;
            }
            ops.pop();
            // Prefix opers are checked and bound like infix opers,
            // only note that their operand numbers diff
            if pre.is_bin() {
                let Some((r, l)) = (try { (exprs.pop()?, exprs.pop()?) }) else {
                    unreachable!()
                };
                exprs.push(Expr::BinOp(pre, Box::new((l, r))));
            } else {
                let Some(v) = exprs.pop() else {
                    unreachable!()
                };
                exprs.push(Expr::UnOp(pre, Box::new(v)));
            }
        }
        // With higher precedence opers bound, postfix opers can safely bind now
        if op.is_postfix() {
            let Some(v) = exprs.pop() else {
                unreachable!()
            };
            exprs.push(Expr::UnOp(op, Box::new(v)));
        } else {
            ops.push(op);
        }
    }
    let Some(mut res) = exprs.pop() else {
        unreachable!()
    };
    while let Some(op) = ops.pop() {
        // The same as above, process infix and prefix opers diffly
        if op.is_bin() {
            let Some(v) = exprs.pop() else {
                unreachable!()
            };
            res = Expr::BinOp(op, Box::new((v, res)));
        } else {
            res = Expr::UnOp(op, Box::new(res));
        }
    }
    Ok(res)
})

Yep, this is a quite complicated title, so let's illustrate our work in this article with a simple example, in Rust in a different world:

trait DataCap {
    fn serialize(&self) -> String;
}

impl<T: Serialize> DataCap for T {
    fn ser(&self) -> String {
        Serializer::serialize(self, serializer)
    }
}
impl<T: !Serialize> DataCap for T {
    fn ser(&self) -> String {
        unreachable!()
    }
}

Sadly this is not accepted by Rust currently:

• Specialization is proven unsound, thus would never be stabilized and is not considered;
• The minimal version of specialization which requires the impls strictly subsetting doesn't apply to this case;
• Not to mention that negative bounds are far from being added to Rust;
• Turning to decide the impl during instantiation is against Rust's early error spirit and would never appear in Rust;
• The lean4 way which just gives up when conflicts and let users to explicit decide which impl should be used is good, but may be too far for industrial langs like Rust :)

Therefore our workaround is to mark whether the trait is implemented, and make a wrapper to unify the impls:

use std::marker::PhantomData;

trait Serialize {
    fn serialize<S>(&self, s: S) -> String;
}

impl Serialize for i32 {
    fn serialize<S>(&self, _s: S) -> String { todo!() }
}

pub trait SerFlag {}
pub struct WithSer;
pub struct NoSer;
impl SerFlag for WithSer {}
impl SerFlag for NoSer {}

// User should impl this
trait DataCap {
    type HasSer: SerFlag;
}
trait DataSer {
    fn serialize(&self) -> String;
}

struct Wrap<T, S: SerFlag>(T, PhantomData<S>);

impl<T: DataCap<HasSer = WithSer> + Serialize> DataSer for Wrap<T, WithSer> {
    fn serialize(&self) -> String { self.0.serialize(()) }
}
impl<T: DataCap<HasSer = NoSer>> DataSer for Wrap<T, NoSer> {
    fn serialize(&self) -> String { "".to_string() }
}

fn use_data<T: DataCap>(data: T) where Wrap<T, T::HasSer>: DataSer {
    let data = Wrap(data, PhantomData::<T::HasSer>);
    data.serialize();
}

impl DataCap for i32 {
    type HasSer = WithSer;
}
impl DataCap for () {
    type HasSer = NoSer;
}

fn main() {
    use_data(0);
    use_data(());
}