![]() ![]() Therefore, a general structure of script can be abstracted. Most of the Praat scripts are written to do batch tasks. It is like lego, that we can put simple pieces into amazing things. baseName$, start, baseName$, start, baseName$, floor, ceiling, start, end For example, to draw the waveform, spectrogram, pitch and annotation together, I only need to call these precedures in turn. The main structure remains highly readable. It is this modular design that enables me to do complex things with Praat. The procedure even calls another procedure within it. I can even write another procedure which draws the pitch of the sound: procedure draw_pitch. To change the size of the window, I only need to modify two parameters (. The draw_TextGrid function can be used together with draw_sound or draw_spectrogram to draw the waveform or spectrogram together with the annotation. endĪnd another procedure which draws the spectrogram: procedure draw_spectrogram. To illustrate, I wrote another procedure which draws the waveform of a sound. The advantage of this procedure is that you can use it independently in any occassion you want, together with other procedures you define. endĪt first glance, this procedure contains more lines than the previous block. This leads me to abstract the drawing of TextGrid as a procedure, which can be used together with other procedures. Suppose later I want to draw the spectrogram of the sound file together with its annotation, there is no available function as to “draw TextGrid together with a spectrogram”. It is OK to select both obeject and draw them together, as follows. Suppose I want to draw the waveform of a sound file together with the annotation file. Using procedure, it is much easier to make illustrations, and minor revisions are needed to customize the pictures. Making illustrations with Praat is tedious manually. It differs from a function command in other programming languages in that procedure can not return values or objects. Praat provide a mechanism called procedure, which can accept parameters and do certain commands. We can abstract common tasks into functions. I will illustrate this idea in the next section. Modular programming requires you to pay attention to orthogonality. ![]() Modular programming is the practice of splitting a large programme into separate modes. It is better to do these tasks using separate scripts.Īnother useful idea is modular programming. Annotation and segmentation are two separate tasks. Phonetic research starts with annotation and segmentation in Praat, and steps to acoustic analysis. This inspired me to reflect on the workflow of phonetic research using Praat. The Unix philosophy says that Small is beatiful and requires programs to do one thing well. The Unix Philosophy and the modular programming are priceless in this scenario. Professional programmers offer their wisdom. The Unix pholosophy and modular programming Undesirable functions distract him, and if he wants to get rid of it, once again he falls into the trap of tailoring. Now the scripts with too many functions get on his way. It is usual for one to go back to revise some of the steps he has taken before. To perform several tasks at the same time may save some time, but doing research is never an once for all affair. Sometimes, the tinkering even takes more time than if one decides to write his own scripts right away. Using scripts with specific functions can lead to tailoring when customizing them to one’s own needs. These two features have some negative effects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |