The sequence and sound data developed for the previous version of the audio library can also be used with the n_audio library. However, because of the improvements outlined in <2>, you will need to prepare the data following the guidelines below.
The effect of the change from an exponential to a linear envelope is greatest at the time of release. The effect is such that it sounds like the release time has been extended because the attentuation rate is smaller at the beginning of the release.
To compensate for this effect you can:
Please note for the following points due to the change in (2.3) and (2.4).
These are explained below.
In n-audio the minimum audio processing unit is set to a fixed value of 184 samples per unit. The number of samples that can be processed by the RSP is also fixed at 184 fixed.
Therefore, the number of samples that the application generates for each frame must be set to a multiple of 184.
For example, when the playback frequency is 32 kHz, the number of required data for 1 frame is
32000 ------- = 533.33...= 533 60
The closest multiple to 533 is
184 x 3 = 552
Thus, Frames A can be set up as follows.
It is possible to set up a value larger than 552 as the size of frame A. However, if it is set up much larger than 533, the required time for processing the frame may become longer than the time for creating 533 data in the former library, even though n_audio is used.
In Frame A,
552 - 533 = 19
samples become surplus samples and are carried over to next frame.
To adjust for the the surplus samples, prepare Frame B as follows.
Combine Frame A and Frame B as follows.
The total of output sample data numbers of these 10 frames is
184 x 3 x 9 + 184 x 2 = 5336
and the actual number of the required sample data among 10 frames is
533 x 10 = 5330
Thus, it becomes possible to adjust the surplus data of the whole application by using these 10 frames repeatedly.
In this manner, you must provide the adjustment of surplus data in the application, and set the number of sampling data created for 1 frame to a multiple of 184.
The above example results from calculation, and doesn't consider unexpected errors. Please see the sample program that comes with the product for more specific examples of how to determine the frame size within an application.
Because we fixed the minimum unit of the audio process to 184 sampling data, gaps are produced depending upon the timing of the ON/OFF for sound, and the envelope transition points. (Example 3)
Example 3) A Timing Gap Between Envelop Changes
When the change in envelope (Attack -> Decay) occurs in one sub-frame, the point where the change occurs is forced to move forward or backwards by rounding up the values.
For example, if the playback frequency is 32kHz, the previous timing is a maximum of
1 184 ------- x ---- = 0.002875 sec 32000 2
off due to rounding errors.
To prevent the timing gap, each event needs to occur on the multiple integer of the minimum audio processing unit. When the playback frequency is 32kHz,
1 ------- x 184 = 0.00575 sec 32000
becomes the minimum processing unit. Therefore, at this moment, we adjust the timing of envelope change by setting the envelope (within the ".inst" file) to
envelope { attackTime = 17250; /* <-- 5750 usec x 3 */ attackVolume = 127; decayTime = 2501250; /* <-- 5750 usec x 435 */ decayVolume = 0; releaseTime = 201250; /* <-- 5750 usec x 35 */ }
We adjust timing for each process using tempo value for the MIDI sequence data.
Specifically, it becomes as follows.
If you process a quarter note with 48 steps, the time "Qn" per quarter note becomes
Qn = 0.00575 x 48 = 0.276 sec
"Tempo" becomes
60 Tempo = ---- = 217.39 ... bpm Qn
We adjust the timing of sequence data using "one to this integer" as the actual tempo
Although, there is sequencer software that will not allow the decimal value of tempo to be input. In these cases, we try to rewrite the tempo value of MIDI data directly.