One of the new features of wcnt-1.2 is for one .wc file to include another .wc file. For this to be useful, three data objects exist.
The changes can range from simply editing a parameter or two, to excluding modules so that different modules can replace them, or adding new modules in the chain to achieve different effects. If you are using wcnt to create a number of sounds for a track, then common elements can be put in one file. You might for example want to change the tempo of the track. Placing the time_map module in a single file which the others all read means you only have to change that one file.
Here is the most simple form of the synth_file_reader data object. synth_file_reader The action parameters specifiy what to do with the module and data object names specified in the lists (The lists are bounded by the modules and data_objects keywords). In this case both actions are set to exclude whatever is specified in both the lists. As the lists are empty then everything contained in time.wch will be used. examples/zdrums02.wc uses two synth_file_reader definitions which are more selective. synth_file_reader The first definition, named zdrums_base, uses all modules except those listed, and includes all the data objects in zdrums_base.wch. The second only makes use of a single data object named drum_params_01. The reason it uses two definitions despite zdrums01.wc reading zdrums_base.wch aswell, is explained in the following section.
The synth_file_reader can be selective about which definitions are to be made use of in a file, but this selectiveness does not carry across to a synth_file_reader defined in a file which is included by another synth_file_reader. Each synth_file_reader created only reads the file specified in it's filename parameter. The only interaction between synth_file_reader data objects is when one reads and creates a definition of another and then instructs it to read its own file. There is no other method for it to instruct another of what it should and should not do. To get around this examples/zdrums02.wc uses two synth_file_reader data objects to read most of the modules from zdrums_base.wch but only the param_editor from zdrums01.wc. Otherwise zdrums01.wc would try to read zdrums_base.wch aswell, only to find that the modules and data objects it attempts to create have all got names already in use, causing wcnt to quit because no two definitions can share the same name. One other important piece of information about the synth_file_reader is that the header information of the file included should exactly match that of the file it is included in. One of the files could read this information from a header file (a file which contains only the header information) and in another it could be as normal. As long as the samplerate, bpm, and signature match it's ok.
It's no use being able to read another file if you cannot change anything afterwards. No prizes for guessing what the param_editor does. This here's how you use it. When using the command line help for the param_editor here's what you get: param_editor Which is more or less no help at all. So let's look at an actual definition from our good friend, zdrums02.wc. param_editor Hmm, forgive me if I'm mistaken, but that does not appear to correspond much does it? Right so, in the command line help, after the edit, the first <unnamed> text_string has in the example become zdrums-wav. The quick and nimble minded amongst you will have realised the <unnamed> parameter name is not specified, only it's value, being zdrums-wav which is the thing to edit. The second <unnamed> text_string is a list of parameters found in the thing to be edited, along with the values to change the parameters to. However, unlike setting the parameters in the module or data object definition itself, when using the param_editor the parameters can be specified in any order. They can also be specified more than once, and the last value will be used. Usually in wcnt all parameters have a name, and their value cannot contain any spaces. These <unnamed> parameter types were specifically created to overcome this. Without them, editing the parameters of modules and data objects would become more long winded than a complete redefinition of the module itself. So be greatful!
Reconnecting inputs is done by using the input_editor which is similar to the param_editor in that the <unnamed> text_string parameter types are used to keep the syntax the same as how inputs are connected in a module. Here is an example from zdrums02.wc: input_editor As with connecting inputs in a module, when using the input_editor the module which contains the output to use does not have to be defined before hand, but the module which contains the input must already be defined. Whenever an output is connected to an input no matter whether in the module definition or by using the input_editor, wcnt creates a connector which stores the information and then makes the connection once reading of the files is complete, that is when everything that should be created has been. The input_editor deletes the original connector and then creates a new one. This holds true if the input_editor is told to set the same input more than once, it deletes the previous connector it made.
wcnt-1.2/jwmsynth |
File inclusion |