- 第 2 页 -
用汇编写出来的程序，自然会比其他高级语言执行效率高，资源占用低。直接对寄存器，内存进行读写操作。高级语言一个函数短短十几行的代码，用汇编实现就需要十倍也许几十倍上百倍的行数。更何况一个像SAW这样的程序，编写出来的汇编源代码也许是数以十万百万计。计算机专业科班出身的，只要在编程方面不是白痴，应该都明白这个道理。用汇编写出SAWSTUDIO，比用其他各种高级语言写出来的SAM, 甚至是PROTOOLS HD，开发难度之大，不是同一个级别的。呵呵，用汇编编写GUI，图形化用户界面，是一件比较头疼的事。
相信在80年代末期到90年代初期接触过编程语言的人，都见过在DOS操作系统盛行的时期，想设计图形化界面来改变人机交互界面，是一件多么稀罕的事情。大多数的界面菜单操作都是用的键盘快捷方式进行，很少支持鼠标操作的。鄙人从90年初期就曾经用PASCAL,C,后来的FOXPRO等等语言在DOS系统下编写过GUI图形化用户界面，对此深有体会。就连最早期的网游的雏形，那时候叫MUD，都是用键盘发出各种指令来操作自己的游戏中人物。比如说，进入一个场景，先来一段场景描述，然后告诉你，这个地方有几个出口，分别是E东边，W西边，S南边，N北边……然后我们就飞快的用键盘来指挥自己的人物向自己的目标方向前进，比如说来一套组合的快捷键：W->N>W->N->E->E，就等于跑了西边，北边，西边，北边，东边，东边这么一大溜……
发展到如今，各种傻瓜式高级语言，所见即所得的GUI编程接口随处可见，使得UI编写成为一件非常简单的工作，直接套用系统给出的模板就能得到一个相当专业的用户界面的雏形，然后再在上面修改一下就成了自己的界面。因此SAW在UI，用户交互方面的友好性，自然不能和其他的各种高级编程语言写出来的音频软件相比。但，有得必有失，失去了一些从开始用电脑就接触WINDOWS UI用户友好界面的用户所谓的交互性之余，换取的是高效率的执行代码以及相当低的系统资源占用率，这，对于计算机专业人士，和真正注重音频软件内在美的人来说，无疑是最大的诱人之处。汇编写SAW的人，应该可以当其他语言程序员的老师。因此，这个软件的开发者，不论是从对音频录音方面的理解，还是计算机程序方面的造诣，是值得人尊敬的。就冲着这一点，SAW就高过其他音频工作站一筹，是合情合理的。
相信在80年代末期到90年代初期接触过编程语言的人，都见过在DOS操作系统盛行的时期，想设计图形化界面来改变人机交互界面，是一件多么稀罕的事情。大多数的界面菜单操作都是用的键盘快捷方式进行，很少支持鼠标操作的。鄙人从90年初期就曾经用PASCAL,C,后来的FOXPRO等等语言在DOS系统下编写过GUI图形化用户界面，对此深有体会。就连最早期的网游的雏形，那时候叫MUD，都是用键盘发出各种指令来操作自己的游戏中人物。比如说，进入一个场景，先来一段场景描述，然后告诉你，这个地方有几个出口，分别是E东边，W西边，S南边，N北边……然后我们就飞快的用键盘来指挥自己的人物向自己的目标方向前进，比如说来一套组合的快捷键：W->N>W->N->E->E，就等于跑了西边，北边，西边，北边，东边，东边这么一大溜……
发展到如今，各种傻瓜式高级语言，所见即所得的GUI编程接口随处可见，使得UI编写成为一件非常简单的工作，直接套用系统给出的模板就能得到一个相当专业的用户界面的雏形，然后再在上面修改一下就成了自己的界面。因此SAW在UI，用户交互方面的友好性，自然不能和其他的各种高级编程语言写出来的音频软件相比。但，有得必有失，失去了一些从开始用电脑就接触WINDOWS UI用户友好界面的用户所谓的交互性之余，换取的是高效率的执行代码以及相当低的系统资源占用率，这，对于计算机专业人士，和真正注重音频软件内在美的人来说，无疑是最大的诱人之处。汇编写SAW的人，应该可以当其他语言程序员的老师。因此，这个软件的开发者，不论是从对音频录音方面的理解，还是计算机程序方面的造诣，是值得人尊敬的。就冲着这一点，SAW就高过其他音频工作站一筹，是合情合理的。
