第一次带学生用Scratch做《天空之城》我原以为是听力课的延伸结果课上到一半变成了一堂数据结构课一个个音符堆成旋律一排排消息串成双人合奏一条条链表把乐谱变成可以遍历的数据。很多老师把这节课归类为“Scratch音乐课”但真正值得教的不是“让舞台响起来”而是让学生看清——音乐里的音符与节拍翻译成程序就是数值与时长多个角色要整齐配合靠的是消息机制而一套能从第1个音符自动跑到最后一个音符的存储结构就是链表。这篇文章完全来自我的课堂实操记录把整节课的拆解过程、踩坑点和可以照抄的积木逻辑全部摊开适合在少儿编程机构上课的老师、自己带娃做项目的家长以及刚接触Scratch但想搞懂消息和列表的中高年级学生。1. 为什么非要用《天空之城》上这节课曲式里藏着天然的教学点1.1 旋律熟悉度决定了课堂效率音乐类编程课最怕的一件事是“学生不知道自己弹错了”。如果选一首冷门曲子学生哼哼不出来节奏对不对全靠猜课堂一大半时间会浪费在校准听觉上。而《天空之城》的知名度足够高几乎每个孩子都在某个动画剪辑、钢琴版视频或者学校铃声里听过主旋律。我课堂上做过一个小测试把主旋律用Scratch顺序积木播放出来故意把第三个音弹错全班至少有三分之二的学生能立刻举手说“这里不对”。这个“能听出错误”的能力在编程调试里就是最原始的测试用例。学生不需要懂乐理耳朵就是他们的断言工具。所以曲子本身的熟知度不是一个情怀问题是一个教学效率问题。1.2 四个核心概念在这首曲子里如何落位这堂课的标题“音符与节拍、消息与链表”听起来像四个独立的知识点但它们在《天空之城》这个项目里是环环相扣的音符旋律中的每一个音高需要被翻译成一个数字MIDI音符编号这是“数据化”的开始。节拍每个音符持续多久决定节奏是否像原曲。同一串音符拍子写错听起来就是另一首歌。链表主旋律有大量重复乐句把整段旋律存入列表用循环遍历播放几十个演奏积木可以压缩成几行核心逻辑。消息当项目只有一个角色时顺序执行就够了但当你希望主旋律和伴奏、灯光反馈同时进行就必须用广播消息把多个角色“调度”起来。这四个概念不是四个独立环节而是在同一个项目中递进出现的。学生先用手工堆积木的方式完成旋律马上就会感到繁琐这时候引入链表重构他们才会感受到数据结构的价值当单一角色演奏已经满足不了表达需求时消息机制就顺理成章地登场了。1.3 完整作品长什么样我课堂上的目标不是做一个“单声部音乐盒”而是一个小型合奏作品绿旗被点击后主旋律精灵开始演奏《天空之城》简化主旋律一个小节之后伴奏精灵收到广播消息同步进入形成简单的对比声部舞台上的音符灯角色随着当前演奏的音符切换造型提供视觉反馈通过一个滑块变量可以实时调整整首曲子的速度不修改任何积木。这个作品做完学生手里拥有的不是一个碰巧能响的脚本而是一套“数据驱动演奏”的小框架。2. 先解决“音符数据化”简谱、音名和MIDI编号的对应2.1 电脑不认识简谱只认识数字Scratch的“音乐”扩展积木里有一个“演奏音符”的积木它要求你填一个数字比如演奏音符(60) 0.25拍。这个数字不是随便来的它对应的是MIDI音符编号——一种把钢琴上每个键都编一个号码的标准。中央C也就是很多孩子学琴时的“do”对应的编号是60往右走一个白键编号加1往左走一个白键编号减1。所以简谱唱名音名MIDI编号1doC4602reD4623miE4644faF4655solG4676laA3577siB359注意我这里把6和7放在了低音区也就是A3和B3而不是A4、B4。这么做的原因是天空之城主旋律的整体音域刚好在C4上下浮动如果全部用高八度Scratch默认的钢琴音色听起来会偏尖锐不够原曲那种空灵感。实际做的时候你完全可以根据喜好整体加12或者减12只要所有音符一起平移旋律结构不变。2.2 主旋律拆成八个小节的数据表我在课堂上用的《天空之城》简化主旋律一共8个小节4/4拍每小节4拍。要强调一点这不是原版完整谱是参照社区流传的简化版整理出来的课堂旋律段目的是让数据结构足够清晰又不失原曲辨识度。-----小节简谱对应音名MIDI编号拍数第1小节6 7 1 7A3 B3 C4 B357 59 60 591 1 1 1第2小节1 3 7 休止C4 E4 B3 空60 64 59 01 1 1 1第3小节6 7 1 7A3 B3 C4 B357 59 60 591 1 1 1第4小节1 3 5 休止C4 E4 G4 空60 64 67 01 1 1 1第5小节6 7 1 7A3 B3 C4 B357 59 60 591 1 1 1第6小节1 3 7 休止C4 E4 B3 空60 64 59 01 1 1 1第7小节6 7 1 2A3 B3 C4 D457 59 60 621 1 1 1第8小节3 2 1 休止E4 D4 C4 空64 62 60 01 1 1 1这张表就是整个项目的数据基础后面无论是硬编码、列表遍历还是双角色合奏全部围绕这张表展开。2.3 休止符也必须进数据表表格里出现了好几个“0”代表空拍。这是很多学生第一次写音乐程序时最容易漏掉的地方。他们会把休止符直接不写结果音符列表长度变成3个、4个交替循环起来后节奏完全错乱。正确做法是把休止符当成一个特殊音符用0占位。后面写列表遍历脚本时需要加一个条件判断如果当前项是0就执行“休止”积木否则执行“演奏音符”积木。这个小分支虽然只多了一行但体现了一个非常重要的编程思想——数据结构里的每个位置都必须有明确含义哪怕它的含义是“什么都不做”。3. 节拍的底层逻辑速度、拍号与Scratch演奏积木的阻塞特性3.1 BPM与一拍时长的换算节拍在Scratch里不是靠“毫秒延迟”实现的而是靠速度BPM和拍数两个参数。BPM全称是Beats Per Minute每分钟多少拍。Scratch音乐扩展积木里的“将速度设为( )”填的就是这个值。影响时长的是这样一条公式:一拍时长(秒) 60 ÷ BPM如果速度是120一拍就是0.5秒如果速度是90一拍就是0.667秒。我课堂上把速度设为90因为《天空之城》原曲偏慢90BPM左右比较接近那种舒缓感。Scratch里的“演奏音符( ) ( )拍”积木第二个参数填的是“几拍”不是“几秒”。这跟MIDI音符编号一样又是一个数据化的过程——人类交流用“半拍”“两拍”计算机用数字0.5、2。学生只要理解了这一点以后切到任何音乐软件都不会太陌生。3.2 “演奏音符”积木是阻塞的还是非阻塞的这里有个非常关键、但很多老师自己都没注意到的特性Scratch的“演奏音符”积木执行时当前脚本会等这个音符播完再继续往下走。它不像“播放声音”积木那样后台异步播放而是类似于“等待”积木会阻塞当前脚本。这个特性带来的直接后果是同一个角色脚本里你没法用顺序积木实现“一边演奏主旋律、一边演奏伴奏”。因为第一个音还没弹完脚本不会去执行下面的操作。理解了这一点就知道为什么合奏必须引入多角色加消息广播——只有不同角色的脚本才真正并行执行。这是整节课从“单一旋律”升级到“多声部合奏”的技术前提。3.3 音乐扩展在哪、默认音色从哪调Scratch 3.0里音乐扩展默认不在积木区。点左下角“添加扩展”选择“音乐”才会出现“演奏音符”“演奏鼓点”“休止”这些积木。很多新手老师第一次上课时找不到积木就是因为没做这一步。音乐扩展里有一个“将乐器设为( )”积木默认是钢琴。吉他、小提琴、管风琴等音色都能选。我做《天空之城》时用的就是默认钢琴如果学生想做更空灵的效果可以试试“音乐盒”或“电子琴”但注意不同设备音色库不一样课上最好统一。4. 第一版顺序演奏积木直接“硬编码”旋律先把节拍跑准4.1 最简单的脚本搭法我不反对第一版用最笨的方式实现。甚至可以说必须让学生先笨一次他们才懂得为什么需要链表。第一版脚本长这样当绿旗被点击 将速度设为 (90) 将乐器设为 (1) 演奏音符 (57) 1拍 演奏音符 (59) 1拍 演奏音符 (60) 1拍 演奏音符 (59) 1拍 演奏音符 (60) 1拍 演奏音符 (64) 1拍 演奏音符 (59) 1拍 休止 1拍 ……继续往下复制这种写法的优点是直观学生能在10分钟内搞定并且立刻听到成果。整张数据表里的32个音在这个阶段就是32个积木一个一个拖进去。4.2 学生最容易犯的错误忘记“休止”导致乐句“抢拍”课堂上第一次试听时至少有一半小组会出现“节奏越跑越快”或者“第4小节突然断掉”的情况。排错方法很简单把数据表打印出来一个一个对着查。最常见的问题是休止符被当成“没内容”直接跳过于是本应是4拍的小节只占了3拍后面的旋律整体往前挪了一拍。音乐里这叫“抢拍”听感上像有人催着你往前走。遇到这种情况我一般不让主学生直接改积木而是让他们先把出错的音符编号圈出来对照表格说出“这里应该休止几拍”把问题定位清楚再动手。这个习惯比改对一个积木重要得多。4.3 硬编码版本的三个痛点硬编码版本能响但离一个好作品还很远修改成本高想换一个音得在一大串积木里找到它拖走旧的、拖来新的还容易拖错位置。代码和数据混在一起音符和拍数全都写死在积木参数里没法分析和复用。扩展性差想再添加伴奏声部要么再复制一套超长脚本要么就只能看着干瞪眼。当学生被这些痛点折磨到一定程度就是引出链表列表结构的最佳时机。如果一上来就讲列表很多学生会觉得“明明一个一个拖积木也挺好啊”教学效果会差很多。5. 用链表重构让旋律成为可以遍历的数据5.1 Scratch的列表为什么可以当成链表来教严格来说Scratch中的“列表”和计算机专业课里讲的“链表”并不完全一样。真正的链表是一组节点每个节点存数据和一个指向下一个节点的指针Scratch列表本质上是一个动态数组按下标访问。但在基础教育阶段两者的核心思想是一致的把一组数据串成一条线程序按顺序从头到尾处理它们。Scratch列表恰恰能让学生以最直观的方式感受“一串数据被遍历”的过程而且它天然支持动态增删这跟链表“插入节点、删除节点”的抽象概念也能对应上。我给学生的说法是“链表就是把一堆音符用一根线串起来程序像过安检一样一个接一个地读。今天我们用Scratch的列表来模拟这根线。”5.2 建立音符列表和节拍列表操作步骤很简单在“变量”分类里点击“建立一个列表”命名为音符。再建一个列表命名为节拍。把数据表的MIDI编号逐个添加进音符列表57、59、60、59、60……把对应的拍数添加进节拍列表1、1、1、1、1……这里要特意让学生对比两个列表强调它们是一一对应的音符的第5项是60节拍的第5项是1意思是“第5个音是MIDI编号60持续1拍”。5.3 循环遍历播放的标准脚本模板建好列表后核心播放积木就从几十行变成下面这个循环当绿旗被点击 将速度设为 (90) 将乐器设为 (1) 将变量 [i v] 设为 (1) 重复执行 (音符的长度) 次 如果 (音符的第 (i) 项) [0] 那么 休止 (节拍的第 (i) 项) 拍 否则 演奏音符 (音符的第 (i) 项) (节拍的第 (i) 项) 拍 结束 将变量 [i v] 增加 (1) 结束这里的变量i是索引从1开始每处理完一个音符就加1直到循环次数等于列表长度。“列表长度”可以直接用音符的长度积木取到不需要手动数。这整段脚本只用了5个核心积木组合却完成了之前32个积木的工作。我让学生对比一下两者的积木数量不需要太多讲解他们自己就会发出“哇”的感叹。5.4 修改音乐时只动数据不动代码链表重构带来的最大体验提升是“改音乐”这件事变了。以前想改一个音要在一堆积木里搜索现在只需要点开音符列表双击修改某一项音乐立刻变成新版本。我课堂上设计了一个小练习让学生把第8小节的第一个音从64改成60然后播放感受旋律结尾的变化。整个操作耗时不到5秒。再让他们把第4小节的休止符从0改成62看看节奏被“填满”之后的效果。这个练习做完几乎每个学生都能理解“数据驱动”是什么意思。这也是链表列表在真实编程中最常见的使用价值把可变内容提取成数据用稳定的逻辑去处理它这样新增需求只需要扩展数据不需要改写核心代码。6. 消息机制从单线演奏到多角色合奏6.1 广播消息的两种典型用法Scratch的消息机制很多人以为只是“让角色说一句话”其实它是角色之间的调度信号。有两条核心积木广播(消息1)发给所有角色发完立刻继续往下执行不等别人。广播(消息1)并等待发给所有角色等所有收到消息的脚本执行完了才继续往下走。我用一个很生活的例子解释给学生听广播消息就像老师在走廊里喊了一句“上课了”所有班的学生听到后各自进教室老师喊完就回办公室不会站在走廊等所有人都坐好。而“并等待”版本相当于老师喊完还站在走廊直到每个班传来“坐好了”的回执才离开。对音乐项目来说合奏场景用普通广播更合适因为需要多个角色同时开始演奏互相不阻塞。而在分乐句衔接的场景中广播并等待更好用能确保上一句播完再开始下一句。6.2 用消息实现卡农轮奏我课上做的是一个轻量级卡农效果主旋律精灵从第1小节开始播放伴奏精灵收到广播后从同一旋律的第5小节切入形成一个相差4小节的轮奏。实现方式主旋律精灵在播放列表循环时用变量当前小节记录播放到了第几小节。当当前小节等于5时发送广播卡农开始。伴奏精灵的脚本是当接收到 [卡农开始 v] 将乐器设为 (5) // 用弦乐音色区别于钢琴 重复执行 (音符的长度) 次 演奏音符 (音符的第 (i) 项) (节拍的第 (i) 项) 拍 将变量 [i v] 增加 (1) 结束注意伴奏精灵也要单独维护一套列表索引变量不能跟主旋律精灵共用同一个i否则两个角色会互相干扰。6.3 消息不能携带数据共享数据要靠变量第一次上这节课的老师很容易走进一个误区以为可以通过广播消息把“当前音符编号”传给另一个角色。但Scratch的消息本质只是一个事件名它不能携带参数。广播当前音符是(57)这种写法是不成立的。想要让另一个角色知道“现在演奏的是哪个音”正确做法是用一个全局变量比如当前演奏音符在主旋律的循环里每播一个音就更新一次舞台上的可视化角色只需要不断读取这个变量的值即可。这是“事件机制”和“共享状态”两种设计思路的经典对比对中学生来说是一个非常划算的认知升级。6.4 注意广播的时序与重复广播问题使用消息排错时有两个高频坑绿旗点击后立刻广播接收方可能还没准备好。我建议在主控角色里先等待0.5秒再广播给所有角色一段初始化时间否则个别角色会收不到第一条消息。循环里重复广播导致接收方脚本反复启动。如果广播放在循环内部且每轮都会触发接收角色会产生多个并发脚本实例。解决方法是给广播加条件确保同一段旋律只在特定时机广播一次。实操中我一般建议学生在广播前加一个“只发一次”的标记变量。比如初始为0广播后设为1用条件判断避免重复广播。7. 让作品更有完成度速度控制、音符灯与课堂验收7.1 用变量控制整体速度不用进积木里找速度控制是这个项目里很出彩的细节。很多老师会让速度固定写死但我说服学生把90这个数字提取成一个变量乐曲速度然后在绿旗初始化时赋值积木里全部用这个变量。这样做的好处显而易见想改速度的时候不需要脚本分区里到处找数字了直接改一个变量就能整体变速。更进阶的玩法是在舞台上显示一个滑块变量学生拖动滑块就能实时改变速度观察“快一点像进行曲、慢一点像摇篮曲”的有趣效果。这个交互能同时巩固变量、数据驱动、实时反馈三个知识点。7.2 跟着音符闪烁的角色用共享变量驱动视觉反馈一个让作品瞬间高级起来的设计是增加一个“音符灯”角色。这个角色不发声只做视觉反馈每当前一个音符被演奏它根据变量的当前值切换造型从低音蓝色到高音暖色形成随音乐流动的光效。具体逻辑很简单当绿旗被点击 将大小设为 (200) 重复执行 如果 (当前演奏音符) [60] 那么 将造型切换为 [低音灯 v] 否则 如果 (当前演奏音符) [65] 那么 将造型切换为 [中音灯 v] 否则 将造型切换为 [高音灯 v] 结束 结束 结束这里不涉及复杂公式只用了嵌套条件判断。但它让整个作品从“一个会响的脚本”变成了“一个可看可听的小型音乐应用”学生的完成感和分享欲完全不一样。7.3 课堂验收清单我每次上完这节课会按下面这张清单快速验收每个小组的作品验收项标准旋律完整能听出《天空之城》主旋律轮廓没有抢拍或漏音列表数据音符列表和节拍列表一一对应休止符用0占位循环播放使用列表遍历实现而非逐个硬编码积木消息同步伴奏角色能被广播触发并与主旋律形成合奏速度控制修改速度变量后整首乐曲速度同步变化可视化音符灯角色随演奏实时变化这六项对应的正好是音符、节拍、链表、消息、变量、条件判断六个知识点。学生自己也能拿这张表自查写完一个作品就像做完一次编程闯关。8. 实测中遇到的坑以及我摸索出来的排错技巧最后分享几个课堂上反复出现的问题每个都是真实踩过的坑。第一个坑是“列表长度不匹配”。有小组把休止符漏在列表外导致音符列表32项、节拍列表30项循环到后半段时读取到空值音乐直接断掉。出现这个现象时我让学生先数两个列表的长度再数数据表里音符加休止的总数几乎马上就能定位。第二个坑是“主旋律播得太快听感很怪”。原因往往是学生把速度设到了140以上。《天空之城》这种慢速抒情曲不适合用快节奏测试。调试时我建议先用90BPM起步等逻辑全部跑通后再去尝试速度变化。第三个坑是“伴奏角色收不到消息”。排查思路分三步先确认消息名完全一致Scratch对消息名大小写和空格很敏感再确认接收积木用的确实是广播的那个消息而不是默认新建的消息最后检查主旋律角色是否真的执行到了广播那一行。很多学生会在循环里放一个永远不会满足的条件广播代码就被跳过了。第四个坑跟“广播并等待”有关。有学生在试卡农时为了让伴奏等主旋律先播一会儿在主旋律角色的循环里插入了一个广播并等待结果两个角色都卡死在等待状态。原因是伴奏角色收到消息后开始播放一大段音乐广播并等待会让主旋律一直等伴奏播完才继续而伴奏的播放逻辑不需要主旋律做任何事程序就僵在那里了。后来我让学生把“并等待”改成“先等指定拍数再广播”用等待(4)拍积木解决问题。音频排错的时候我还发现一个很省力的技巧在循环里加一个将当前演奏音符设置为变量然后让主旋律角色在演奏每个音的同时用思考(当前演奏音符)显示出来。这样调试时不需要一直盯着列表对编号角色头顶会自动冒出当前音符一眼就能看出循环在第几个音停下来非常直观。这堂课上到现在每一轮都会出现新的小问题但核心框架已经稳定下来先硬编码跑通再用列表重构最后用消息做合奏。三个环节缺一不可跳过一个后面的概念就悬空。如果你也要上类似的Scratch音乐课我建议先别急着追求完整版曲谱拿我这份8小节的简化版本练手把数据结构讲透比让学生磕一整首曲子更有价值。