Yahoo Tuning Groups Ultimate Backup tuning Better tuning resolution with Timidity, but still not good enough

Upon the suggestion of Marcel de Velde, I have installed Timidity for
Windows XP, ran the TWsynth component and hooked up the midi to a
decent XG soundfont via Midi Yoke.

The XG-soundset is here (you have to sign up for download):

http://www.sf2midi.com/soundfonts/download/yamaha-xg-sound-set-sf2-108.html

After going through several badly tuned soundfonts and patches, I
finally found in the original Yamaha XG sound set a French Horn (patch
61) that sounds fairly decent and very correctly tuned.

Using the same AutoStrobe experiment setup, I measured each pitch from
A=440 Hz up a quarter-tone by 1 cent increments. RHS signifies SCALA's
steps from A up in cents, LHS indicates actual sounds from the
Timidity Synth using the XG-soundset.

cents - measured
0 - 0
1 - 1
2 - 1.9
3 - 2.9
4 - 3.8
5 - 4.7
6 - 6.5
7 - 6.5
8 - 8.3
9 - 9.2
...
...
50 - 50

Apparently, the tuning is done by about 0.93 cent increments. Maximum
deviation from theoretical is half a cent, which is a drastic
improvement compared to the tuning discrepancies with the Yamaha S-
YXG50. I don't know what the significance of this increment in MIDI
parlance is though. Mayhap the octave is divided into 1296 equal
parts? Or else, could we be dealing with 0.25 Hertz increments?

A severe problem is the occasional crackling and chopping of the audio
when using TWSynth. Size of the referenced soundfont is not a factor. I am guessing the generic windows audio driver is troublesome. How can
I remedy this situation?

Cordially,
Oz.

✩ ✩ ✩
www.ozanyarman.com

🔗Graham Breed <gbreed@...>

🔗Ozan Yarman <ozanyarman@...>

🔗Marcel de Velde <m.develde@...>

Hi Oz,

Apparently, the tuning is done by about 0.93 cent increments. Maximum
> deviation from theoretical is half a cent, which is a drastic
> improvement compared to the tuning discrepancies with the Yamaha S-
> YXG50. I don't know what the significance of this increment in MIDI
> parlance is though. Mayhap the octave is divided into 1296 equal
> parts? Or else, could we be dealing with 0.25 Hertz increments?
>
> A severe problem is the occasional crackling and chopping of the audio
> when using TWSynth. Size of the referenced soundfont is not a factor.
> I am guessing the generic windows audio driver is troublesome. How can
> I remedy this situation?
>
> Cordially,
> Oz.
>

You can do different soudsettings that will lower the cpu, and choose a
different driver for you soundcard etc under preferences.
Don't have the crackling problem myself and don't know what's causing it in
your case, but it looks like timidity can be made very cpu light and should
work on a 10 year old computer with the right settings.

Furthermore timidity can cause the notes to be too abubtly cutoff at the
tail because of 0 release envelope.
This will also cause clicks (only on release of the note)
To fix this add a line to your instrument in the cfg file to make a longer
release like this:

dir "C:\\Documents and
Settings\\mars\\Bureaublad\\Soundfonts\\sonimusicae\\Orgue-de-salon-sf2\\"
bank 0
0 %font "Orguedesalon.sf2" 0 22 rate=:::180 strip=tail

this is my cfg file for an organ sound.
the last line begins with 0. This is the midi program channel the instrument
receives on.
after the font you see a 0 again, this is the bank of the font, then you see
a 22, this is the midi program channel inside the soundfont that point to a
specific program (like 61 for the french horn in your xg soundfont file).
(note this program 22 sound inside the soundfont now listenes to program 0
in timidity. Also note that some midi equipment will send on channel 1 but
this is seen as channel 0 by timidity. 0 to 127 vs 1 to 128)
btw also note the \\ in the directory line, seems this is somehow needed
otherwise timidity won't read the directory line correctly.

As for tuning.
Good to hear that it has better than a cent resolution with pitchbends.
Hope this is enough for realtime playing.
But for non realtime I recomend MIDI Tuning Standard tuning which has a much
better resolution.

Btw if someone knows a way to tune timidity in realtime with MTS please let
me (and Oz offcourse:) know!

Good luck and if you need any more help feel free to contact me onlist or
offlist!
Only started using timidity recently but I have it working nicely now.

Marcel

🔗Ozan Yarman <ozanyarman@...>

Dear Marcel,

On Oct 20, 2009, at 10:17 PM, Marcel de Velde wrote:

>
>
> Hi Oz,
>
> Apparently, the tuning is done by about 0.93 cent increments. Maximum
> deviation from theoretical is half a cent, which is a drastic
> improvement compared to the tuning discrepancies with the Yamaha S-
> YXG50. I don't know what the significance of this increment in MIDI
> parlance is though. Mayhap the octave is divided into 1296 equal
> parts? Or else, could we be dealing with 0.25 Hertz increments?
>
> A severe problem is the occasional crackling and chopping of the audio
> when using TWSynth. Size of the referenced soundfont is not a factor.
> I am guessing the generic windows audio driver is troublesome. How can
> I remedy this situation?
>
> Cordially,
> Oz.
>
>
> You can do different soudsettings that will lower the cpu, and > choose a different driver for you soundcard etc under preferences.
> Don't have the crackling problem myself and don't know what's > causing it in your case, but it looks like timidity can be made very > cpu light and should work on a 10 year old computer with the right > settings.
>

I have tweaked many settings the way you described, without, alas, any remedies for the crackling audio.

> Furthermore timidity can cause the notes to be too abubtly cutoff at > the tail because of 0 release envelope.
> This will also cause clicks (only on release of the note)
> To fix this add a line to your instrument in the cfg file to make a > longer release like this:
>
> dir "C:\\Documents and Settings\\mars\\Bureaublad\\Soundfonts\> \sonimusicae\\Orgue-de-salon-sf2\\"
> bank 0
> 0 %font "Orguedesalon.sf2" 0 22 rate=:::180 strip=tail
>
> this is my cfg file for an organ sound.
> the last line begins with 0. This is the midi program channel the > instrument receives on.
> after the font you see a 0 again, this is the bank of the font, then > you see a 22, this is the midi program channel inside the soundfont > that point to a specific program (like 61 for the french horn in > your xg soundfont file).
> (note this program 22 sound inside the soundfont now listenes to > program 0 in timidity. Also note that some midi equipment will send > on channel 1 but this is seen as channel 0 by timidity. 0 to 127 vs > 1 to 128)
> btw also note the \\ in the directory line, seems this is somehow > needed otherwise timidity won't read the directory line correctly.
>

Thanks for the tips. I tried this suggestion, but alas, again without any fix for the crackling audio.

I attempted to tweak many settings in TWSynth, but discovered that meddling with the output values (for example, trying to change audio quality from 16-bit to 24-bit) could crash TWsynth and freeze Windows XP every time the synth is re-run. I had to delete the configuration (ini) files often and did a hard boot several times before giving up messing with the output settings.

I swear I could select Directsound as a driver before, but it somehow disappeared after one of those crashes. A reinstall of DirectX did not help. I am stuck with Windows audio driver unless somebody can suggest another way for TWSynth in Windows XP.

> As for tuning.
> Good to hear that it has better than a cent resolution with > pitchbends.
> Hope this is enough for realtime playing.
> But for non realtime I recomend MIDI Tuning Standard tuning which > has a much better resolution.
>
> Btw if someone knows a way to tune timidity in realtime with MTS > please let me (and Oz offcourse:) know!
>

You mean it is actually possible to hear less than 0.1 cent differences realtime while playing around with SCALA Chromatic Keyboard using TWSynth? How does one do that? It would be great to have such a tuning resolution at hand.

> Good luck and if you need any more help feel free to contact me > onlist or offlist!
> Only started using timidity recently but I have it working nicely now.
>

Thanks for all your help!

> Marcel
>
>
>
>

Oz.

🔗Graham Breed <gbreed@...>

🔗Ozan Yarman <ozanyarman@...>

O Graham,

Sorry for the late reply. I have been checking qsynth, which is kind
of screwy with the soundfonts (playing C sounds a -200 cents Bb, and
pitch bend commands do not function properly). I have finally managed
to find a copy of twsynth that does not produce crackling audio. So
far so good. I also discovered through trial and error that the
Fantasia (New Age) Pad of the soundfont named "Scc1t2.sf2" features a
sweet sounding (teensy wobbly) and correctly tuned patch. I made new
measurements and confirm that, indeed, the smallest increment in
Timidity must be 0.39 cents (256th of an equal semitone).

Do you know how the smallest increment can be set to 1024th of an
equal semitone in Timidity++ for Windows? That would equate to nearly
0.1 cent increments. It would be good to have such a resolution handy,
especially considering experimenting with proportional beating chords.
I would appreciate it very much if someone can assist me in that
direction.

I didn't check the tuning tables though. I feel much more comfortable
with +12 pitches per octave over 16 channels simultaneously.

Cordially,
Oz.

✩ ✩ ✩
www.ozanyarman.com

On Oct 22, 2009, at 6:18 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>
>> Apparently, the tuning is done by about 0.93 cent increments. Maximum
>> deviation from theoretical is half a cent, which is a drastic
>> improvement compared to the tuning discrepancies with the Yamaha S-
>> YXG50. I don't know what the significance of this increment in MIDI
>> parlance is though. Mayhap the octave is divided into 1296 equal
>> parts? Or else, could we be dealing with 0.25 Hertz increments?
>
> I've checked the source code. The only loss of precision I
> see is in the pitch bend lookup table, which only has 256
> divisions of a semitone. That should mean about 0.39 cent
> steps. Not perfect but better than what you're seeing.
>
> It could be fixed fairly easily but I'm not sure it matters.
> Does anybody care about pitch bend precision? I hope the
> tuning tables are better. Maybe you could check them.
>
>
> Graham

🔗Marcel de Velde <m.develde@...>

Hello Oz and Graham,

> Sorry for the late reply. I have been checking qsynth, which is kind
> of screwy with the soundfonts (playing C sounds a -200 cents Bb, and
> pitch bend commands do not function properly). I have finally managed
> to find a copy of twsynth that does not produce crackling audio.
>
Ah good that you found this was the problem!

> So far so good. I also discovered through trial and error that the
> Fantasia (New Age) Pad of the soundfont named "Scc1t2.sf2" features a
> sweet sounding (teensy wobbly) and correctly tuned patch.
>
Thanks for the tip, will try it out.

> I made new
> measurements and confirm that, indeed, the smallest increment in
> Timidity must be 0.39 cents (256th of an equal semitone).
>
> Do you know how the smallest increment can be set to 1024th of an
> equal semitone in Timidity++ for Windows? That would equate to nearly
> 0.1 cent increments. It would be good to have such a resolution handy,
> especially considering experimenting with proportional beating chords.
> I would appreciate it very much if someone can assist me in that
> direction.
>
I have a hunch that if you tune by Midi Tuning Standard you will get a
better pitch resoluton.
I just tried out Graham's tip that Scala's realtime midi relay output should
also work for MTS and indeed it does! :)
Thank you Graham!

The way I have it set up is as follows:
I did not have to set any Z flag in Timidity, apparently it was correctly
set allready by default.
I selected in Scala under preferences - midi: synthesizer tuning options
(send): model: 1: MIDI Tuning Standard single notes dump, 3 byte.
Then I installed Loopbe1 (an internal midi relay cable)
The under midi relay in Scala I selected as output loopbe, and in Timidity++
realtime synthesizer I selected as input Loopbe.
And it's working perfectly. Timidity realtime synthesizer is retuned
realtime by Scala midi relay by MTS tuning.

I didn't check the tuning tables though. I feel much more comfortable
> with +12 pitches per octave over 16 channels simultaneously.
>
The MTS will give you this.
And with as much polyphony on each channel as Timidity can handle.

Good luck,

Marcel

🔗Marcel de Velde <m.develde@...>

🔗Ozan Yarman <ozanyarman@...>

O Marcel,

On Oct 27, 2009, at 9:39 PM, Marcel de Velde wrote:

>
>
>
> SNIP
>
> I made new
> measurements and confirm that, indeed, the smallest increment in
> Timidity must be 0.39 cents (256th of an equal semitone).
>
> Do you know how the smallest increment can be set to 1024th of an
> equal semitone in Timidity++ for Windows? That would equate to nearly
> 0.1 cent increments. It would be good to have such a resolution handy,
> especially considering experimenting with proportional beating chords.
> I would appreciate it very much if someone can assist me in that
> direction.
>
> I have a hunch that if you tune by Midi Tuning Standard you will get > a better pitch resoluton.
> I just tried out Graham's tip that Scala's realtime midi relay > output should also work for MTS and indeed it does! :)
> Thank you Graham!
>
> The way I have it set up is as follows:
> I did not have to set any Z flag in Timidity, apparently it was > correctly set allready by default.
> I selected in Scala under preferences - midi: synthesizer tuning > options (send): model: 1: MIDI Tuning Standard single notes dump, 3 > byte.
> Then I installed Loopbe1 (an internal midi relay cable)
> The under midi relay in Scala I selected as output loopbe, and in > Timidity++ realtime synthesizer I selected as input Loopbe.
> And it's working perfectly. Timidity realtime synthesizer is retuned > realtime by Scala midi relay by MTS tuning.
>

I am using MidiYoke, which does the same job linking SCALA to TWSynth. But I am not relaying MIDI yet, I'm experimenting with the Chromatic Keyboard in SCALA as always, trying out chords and intervals. The tuning resolution is by steps of 256th of an equal semitone. Peterson AutoStrobe 590 confirms that TWSynth is operating by 0.39 cent increments when pitchbending. Hence, MTS is not working to its full potential in TWSynth.

All I ask is for someone to show me how the pitch bend resolution could be increased in Timidity, hopefully with some line added to the timidity.cfg file.

> I didn't check the tuning tables though. I feel much more comfortable
> with +12 pitches per octave over 16 channels simultaneously.
>
> The MTS will give you this.
> And with as much polyphony on each channel as Timidity can handle.
>

The polyphony is currently set to 256 simultaneous voices in TWSynth. It can be increased on demand as far as computer memory allows.

> Good luck,
>
> Marcel
>
>
>

Oz.

🔗Ozan Yarman <ozanyarman@...>

You may like to check this info:

http://www.nabble.com/note-changes-and-pitch-bending-td19546994.html

Oz.

✩ ✩ ✩
www.ozanyarman.com

On Oct 27, 2009, at 10:26 PM, Marcel de Velde wrote:

>
>
> Sorry cheered to early.
> I had somehow convinced myself I was listening to MTS realtime
> tuning of Timidity but checking revealed that Scala in not using MTS
> but sitll using pitch bends for the realtime tuning.
> Selecting synthesizer model had no effect on the real time midi
> relay settings.
> Will figure out how to make it work though.
> I think it will be either through the send tuning interface in Scala
> or by saving the tuning to a textfile and leading this in Timidity.
> Again sorry if you allready went through the trouble of trying it out.
>
> Marcel
>
> I have a hunch that if you tune by Midi Tuning Standard you will get
> a better pitch resoluton.
> I just tried out Graham's tip that Scala's realtime midi relay
> output should also work for MTS and indeed it does! :)
> Thank you Graham!
>
> The way I have it set up is as follows:
> I did not have to set any Z flag in Timidity, apparently it was
> correctly set allready by default.
> I selected in Scala under preferences - midi: synthesizer tuning
> options (send): model: 1: MIDI Tuning Standard single notes dump, 3
> byte.
> Then I installed Loopbe1 (an internal midi relay cable)
> The under midi relay in Scala I selected as output loopbe, and in
> Timidity++ realtime synthesizer I selected as input Loopbe.
> And it's working perfectly. Timidity realtime synthesizer is retuned
> realtime by Scala midi relay by MTS tuning.
>
>
>
>

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:

> Do you know how the smallest increment can be set to 1024th of an > equal semitone in Timidity++ for Windows? That would equate to nearly > 0.1 cent increments. It would be good to have such a resolution handy, > especially considering experimenting with proportional beating chords. > I would appreciate it very much if someone can assist me in that > direction.

You'd have to compile a patched version. The changes don't look that difficult but you have all the problems of compiling something on Windows. Or convincing the developers to lift the restriction.

> I didn't check the tuning tables though. I feel much more comfortable > with +12 pitches per octave over 16 channels simultaneously.

I expect it's the same anyway.

The trouble is, the primary use case for pitch bends is where you have a lot of them arriving close together, and each one has to be cheap to process. In that case, each one being accurate to less than a cent isn't important at all so you can use a lookup table if it saves processing power. With the MIDI Tuning Standard there's a better argument that you want the accuracy first and the processor overhead isn't important because you won't have more than one retuning per note.

Personally, I'm not convinced that the lookup tables are saving processor time. But given it only matters if the samples start out tuned correctly I don't think it's worth arguing about. (But I notice that Timdity has a load of pitch detection code -- I don't know what it's for.)

If you really want high precision microtonality, try to get Csound working with an algorithm that doesn't depend on samples. Or look at ZynAddSubFX -- I don't know how precise that is.

Graham

🔗Ozan Yarman <ozanyarman@...>

Dear Graham,

On Oct 28, 2009, at 2:43 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>
>> Do you know how the smallest increment can be set to 1024th of an
>> equal semitone in Timidity++ for Windows? That would equate to nearly
>> 0.1 cent increments. It would be good to have such a resolution >> handy,
>> especially considering experimenting with proportional beating >> chords.
>> I would appreciate it very much if someone can assist me in that
>> direction.
>
> You'd have to compile a patched version. The changes don't
> look that difficult but you have all the problems of
> compiling something on Windows. Or convincing the
> developers to lift the restriction.

I did a successful compilation of libsndfile just yesterday using MinGW + MSys. If I knew what to change and where exactly, I assume I could try to make a personal Timidity compilation for Windows featuring 0.1 cent pitchbend precision. Does anyone wish to suggest a better increment for Timidity while we are at it?

Also, I need to know what packages are needed prior to the compilation process. Can you help fill in the blanks?

>
>> I didn't check the tuning tables though. I feel much more comfortable
>> with +12 pitches per octave over 16 channels simultaneously.
>
> I expect it's the same anyway.
>
> The trouble is, the primary use case for pitch bends is
> where you have a lot of them arriving close together, and
> each one has to be cheap to process. In that case, each one
> being accurate to less than a cent isn't important at all so
> you can use a lookup table if it saves processing power.

I don't necessarily use pitchbend control to bend a pitch (or pitches) continuously in realtime. That would indeed require too much processing power if the increments were 16,384 steps per interval. Let us optimize then. I was thinking of settling for 0.1 cents to realize near-perfect proportional beating chords. What do you think is the optimum increment here?

> With the MIDI Tuning Standard there's a better argument that
> you want the accuracy first and the processor overhead isn't
> important because you won't have more than one retuning per
> note.
>
> Personally, I'm not convinced that the lookup tables are
> saving processor time. But given it only matters if the
> samples start out tuned correctly I don't think it's worth
> arguing about. (But I notice that Timdity has a load of
> pitch detection code -- I don't know what it's for.)
>
> If you really want high precision microtonality, try to get
> Csound working with an algorithm that doesn't depend on
> samples.

I never got fond of Csound. Too much programming language is required for that. I work better with interfaces, knobs and buttons.

> Or look at ZynAddSubFX -- I don't know how precise
> that is.

Glad you spoke of it. I did indeed check ZynAddSubFX a day ago. It responds to 0.1 cent increments in the very least. I can't measure smaller increments, my AutoStrobe's accuracy of pitch detection is 0.1 cent. I am guessing it implements MTS wholly... 14-bits that is.

But the sounds are too wobbly (Only the Clarinet sound is a dependable patch for measurements), and I am not a person who is into electronic instrument modelling. So, back to TWSynth.

>
>
> Graham
>

Oz.

🔗Daniel Forro <dan.for@...>

🔗cameron <misterbobro@...>

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:

> I did a successful compilation of libsndfile just yesterday using > MinGW + MSys. If I knew what to change and where exactly, I assume I > could try to make a personal Timidity compilation for Windows > featuring 0.1 cent pitchbend precision. Does anyone wish to suggest a > better increment for Timidity while we are at it?

I don't see why Timidity needs to define its own lookup tables. The obvious reason is to avoid the C pow() function. But modern processors calculate standard functions pretty efficiently, involving lookup tables, so I expect one pitch bend per note to carry a negligible overhead.

At least try no restriction and benchmark it. Note that you may be able to avoid initializing the lookup table, which will save 256 calculations on startup! If there is a siginificant saving with the lookup table, note that an alternative approach is to use linear interpolation to get the extra precision. I think this would give very accurate results with the existing lookup tables.

The procedure is:

Look at the init_bend_fine in timidity/tables.c

Replace the 8 lookups from bend_fine in timidity/playmidi.c with the relevant expression, using full precision.

Grep for other uses of bend_fine if you want to purge the lookup table completely.

> Also, I need to know what packages are needed prior to the compilation > process. Can you help fill in the blanks?

No, sorry. All I did is download the code from CVS. And what I'm looking at doesn't look like the Windows synth anyway.

> Glad you spoke of it. I did indeed check ZynAddSubFX a day ago. It > responds to 0.1 cent increments in the very least. I can't measure > smaller increments, my AutoStrobe's accuracy of pitch detection is 0.1 > cent. I am guessing it implements MTS wholly... 14-bits that is.
> > But the sounds are too wobbly (Only the Clarinet sound is a dependable > patch for measurements), and I am not a person who is into electronic > instrument modelling. So, back to TWSynth.

I've used ZASFX a bit. It doesn't have the greatest interface, but it looks easier to tweak than Csound. You should be able to remove that wobbliness.

Graham

🔗Ozan Yarman <ozanyarman@...>

O Cameron,

On Oct 28, 2009, at 8:18 AM, cameron wrote:

> Ozan, ZynAddSubFx and a good number of software synths which use the > approach loading .scl files directly into the synth. The synth then > recalibrates itself to send the proper new cycles per second to the > midi note numbers.
>

I have and use ZASFx, it's a great tool. But as I said earlier, most samples sound wobbly and instrument modelling is beyond me.

> In ZynAddSubFx, the tuning can also be reassigned to keys with a > Scala .kbd file (so you can have mute keys, duplicate pitches, > upside-down scales, etc).
>

I know this.

> The accuracy is something like .00001 Hz (cycles per second), can't > remember. The .scl files can contain ratios, which the synths > calculate to its internal resolution, 32-bit or whatever.
>

At 440 Hz, an increase by that cps will equate to 0.00004 cents difference. It is fantastic, but overkill at the same time.

> Anyway it really is accurate enough!

Surely!

> Loading Scala files directly
> is clearly the best approach, the next best is .tun files, which are > also extremely acccurate.
>
> This program:
>
> http://12equalboresme.com/
>
> converts Scala files to Kontakt scripts. It is also extremely > accurate- .00001 Cent IIRC. This is nominal if you are using > acoustic samples, as they wobble a lot more than that, but if you > make your own samples for a dead-still synthetic instrument, you can > verify that it is indeed an extremely accurate system. Kontakt + > script is the best solution for acoustic instrument samples.
>

There is no way to verify any increment smaller than 0.1 cents with my hardware. 0.1 cents is plenty as far as I am concerned.

Good to know that there is a way to convert Scala files to Kontakt scripts. Thanks for pointing that out.

> - Cameron Bobro
>
>
>

Oz.

🔗Ozan Yarman <ozanyarman@...>

Dear Graham,

✩ ✩ ✩
www.ozanyarman.com

On Oct 28, 2009, at 8:39 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>
>> I did a successful compilation of libsndfile just yesterday using
>> MinGW + MSys. If I knew what to change and where exactly, I assume I
>> could try to make a personal Timidity compilation for Windows
>> featuring 0.1 cent pitchbend precision. Does anyone wish to suggest a
>> better increment for Timidity while we are at it?
>
> I don't see why Timidity needs to define its own lookup
> tables. The obvious reason is to avoid the C pow()
> function. But modern processors calculate standard
> functions pretty efficiently, involving lookup tables, so I
> expect one pitch bend per note to carry a negligible overhead.
>

I don't understand any of what you said. Please elaborate. What is a
lookup table?

> At least try no restriction and benchmark it.

How do I benchmark timidity? Don't I need special benchmarking tools for the job?

> Note that you
> may be able to avoid initializing the lookup table, which
> will save 256 calculations on startup! If there is a
> siginificant saving with the lookup table, note that an
> alternative approach is to use linear interpolation to get
> the extra precision. I think this would give very accurate
> results with the existing lookup tables.
>

Please remind me, what was linear interpolation?

> The procedure is:
>
> Look at the init_bend_fine in timidity/tables.c
>

Don't I need a special editor to view this file?

> Replace the 8 lookups from bend_fine in timidity/playmidi.c
> with the relevant expression, using full precision.
>

Is the relevant expression "full precision", or some kind of number?

> Grep for other uses of bend_fine if you want to purge the
> lookup table completely.

Again, please elaborate.

>
>> Also, I need to know what packages are needed prior to the
>> compilation
>> process. Can you help fill in the blanks?
>
> No, sorry. All I did is download the code from CVS. And
> what I'm looking at doesn't look like the Windows synth anyway.

I was assuming that the macbuild, linuxbuild, and winbuild are all in
the same bundle?

>
>> Glad you spoke of it. I did indeed check ZynAddSubFX a day ago. It
>> responds to 0.1 cent increments in the very least. I can't measure
>> smaller increments, my AutoStrobe's accuracy of pitch detection is
>> 0.1
>> cent. I am guessing it implements MTS wholly... 14-bits that is.
>>
>> But the sounds are too wobbly (Only the Clarinet sound is a
>> dependable
>> patch for measurements), and I am not a person who is into electronic
>> instrument modelling. So, back to TWSynth.
>
> I've used ZASFX a bit. It doesn't have the greatest
> interface, but it looks easier to tweak than Csound. You
> should be able to remove that wobbliness.
>

I'd rather not mess up with the hundreds of controls that I don't know
does what. TWSynth is good enough if only we could fix the PB precision.

>
> Graham
>

Oz.

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:

>> I don't see why Timidity needs to define its own lookup
>> tables. The obvious reason is to avoid the C pow()
>> function. But modern processors calculate standard
>> functions pretty efficiently, involving lookup tables, so I
>> expect one pitch bend per note to carry a negligible overhead.
> > I don't understand any of what you said. Please elaborate. What is a > lookup table?

The lookup table is what restricts Timidity to 256 divisions of the semitone. It calculates all 256 different fine tunings and remembers them to save time calculating the exact bend each time you want it.

>> At least try no restriction and benchmark it.
> > How do I benchmark timidity? Don't I need special benchmarking tools > for the job?

See how long it takes to process a file, or how much the sound breaks up in real time or how much of the processor it uses.

>> Note that you
>> may be able to avoid initializing the lookup table, which
>> will save 256 calculations on startup! If there is a
>> siginificant saving with the lookup table, note that an
>> alternative approach is to use linear interpolation to get
>> the extra precision. I think this would give very accurate
>> results with the existing lookup tables.

> Please remind me, what was linear interpolation?

Drawing a straight line between two data points so that you can guess a value in the middle.

>> The procedure is:
>>
>> Look at the init_bend_fine in timidity/tables.c
> > Don't I need a special editor to view this file?

No.

>> Replace the 8 lookups from bend_fine in timidity/playmidi.c
>> with the relevant expression, using full precision.
> > Is the relevant expression "full precision", or some kind of number?

It's a bit of C code you copy from the other file.

>> Grep for other uses of bend_fine if you want to purge the
>> lookup table completely.
> > Again, please elaborate.

Every time the lookup table is accessed, you may be losing precision. So search for each time it's mentioned in the code.

>>> Also, I need to know what packages are needed prior to the >>> compilation
>>> process. Can you help fill in the blanks?
>> No, sorry. All I did is download the code from CVS. And
>> what I'm looking at doesn't look like the Windows synth anyway.
> > I was assuming that the macbuild, linuxbuild, and winbuild are all in > the same bundle?

I couldn't get a bundle. There should be some but I got an error message in Japanese. The CVS is accessible in SourceForge but the instructions are incomplete. You have to specify a module name but there isn't a list of modules. I guessed "timidity" and I'm missing some folders that I can see from the web browser.

> I'd rather not mess up with the hundreds of controls that I don't know > does what. TWSynth is good enough if only we could fix the PB precision.

But you do want to mess with C code? "Wobbliness" is probably due to LFOs. Try turning down any LFO depth you find.

Graham

🔗Ozan Yarman <ozanyarman@...>

Dear Graham,

So, if I eliminate the pitchbend lookup tables in Timidity entirely,
do I arrive at MTS with 16384 increments per interval (semitone,wholetone, etc...)?

I imagine trying to benchmark the different compilations of Timidity
on my powerful Macbook Pro will produce negligible results.

Wait, did you say that the audio might crackle again after this? I
hope it's not so.

You have to be real specific about how to change the 8 lookup tables in:

> init_bend_fine in timidity/tables.c

Seeing as I am a complete dummy in C programming language. What and
from where do I copy the relevant C code to replace the lookup tables?
And if I want to eliminate the lookup tables entirely, do I delete all
instances of bend_fine?

Please bear patiently with me on this one. A step-by-step list of
instructions will be much appreciated.

Or else, maybe you can patch of the tables.c file to eliminate the
pitchbend lookup tables entirely and send it to me via e-mail?

One more thing, I couldn't find a Windows executable of the latest
version of ZASFX, which is v. 2.4. Do you have a compiled version 2.4?
Or do I need to compile it myself too?

Cordially,
Oz.

✩ ✩ ✩
www.ozanyarman.com

On Oct 29, 2009, at 5:18 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>
>>> I don't see why Timidity needs to define its own lookup
>>> tables. The obvious reason is to avoid the C pow()
>>> function. But modern processors calculate standard
>>> functions pretty efficiently, involving lookup tables, so I
>>> expect one pitch bend per note to carry a negligible overhead.
>>
>> I don't understand any of what you said. Please elaborate. What is a
>> lookup table?
>
> The lookup table is what restricts Timidity to 256 divisions
> of the semitone. It calculates all 256 different fine
> tunings and remembers them to save time calculating the
> exact bend each time you want it.
>
>>> At least try no restriction and benchmark it.
>>
>> How do I benchmark timidity? Don't I need special benchmarking tools
>> for the job?
>
> See how long it takes to process a file, or how much the
> sound breaks up in real time or how much of the processor it
> uses.
>
>>> Note that you
>>> may be able to avoid initializing the lookup table, which
>>> will save 256 calculations on startup! If there is a
>>> siginificant saving with the lookup table, note that an
>>> alternative approach is to use linear interpolation to get
>>> the extra precision. I think this would give very accurate
>>> results with the existing lookup tables.
>
>> Please remind me, what was linear interpolation?
>
> Drawing a straight line between two data points so that you
> can guess a value in the middle.
>
>>> The procedure is:
>>>
>>> Look at the init_bend_fine in timidity/tables.c
>>
>> Don't I need a special editor to view this file?
>
> No.
>
>>> Replace the 8 lookups from bend_fine in timidity/playmidi.c
>>> with the relevant expression, using full precision.
>>
>> Is the relevant expression "full precision", or some kind of number?
>
> It's a bit of C code you copy from the other file.
>
>>> Grep for other uses of bend_fine if you want to purge the
>>> lookup table completely.
>>
>> Again, please elaborate.
>
> Every time the lookup table is accessed, you may be losing
> precision. So search for each time it's mentioned in the code.
>
>>>> Also, I need to know what packages are needed prior to the
>>>> compilation
>>>> process. Can you help fill in the blanks?
>>> No, sorry. All I did is download the code from CVS. And
>>> what I'm looking at doesn't look like the Windows synth anyway.
>>
>> I was assuming that the macbuild, linuxbuild, and winbuild are all in
>> the same bundle?
>
> I couldn't get a bundle. There should be some but I got an
> error message in Japanese. The CVS is accessible in
> SourceForge but the instructions are incomplete. You have
> to specify a module name but there isn't a list of modules.
> I guessed "timidity" and I'm missing some folders that I
> can see from the web browser.
>
>> I'd rather not mess up with the hundreds of controls that I don't
>> know
>> does what. TWSynth is good enough if only we could fix the PB
>> precision.
>
> But you do want to mess with C code? "Wobbliness" is
> probably due to LFOs. Try turning down any LFO depth you find.
>
>
> Graham
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>

🔗Ozan Yarman <ozanyarman@...>

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:

> So, if I eliminate the pitchbend lookup tables in Timidity entirely, > do I arrive at MTS with 16384 increments per interval (semitone, > wholetone, etc...)?

Yes. But it's only as good as the sample set you're using. If the samples aren't tuned that accurately, the results won't be anyway. That's why you should go for a purely algorithmic approach for high-precision tuning.

> I imagine trying to benchmark the different compilations of Timidity > on my powerful Macbook Pro will produce negligible results.

Probably, yes. There may be a good reason for the optimization but without seeing benchmarks I'll assume not.

> Wait, did you say that the audio might crackle again after this? I > hope it's not so.

I doubt it.

> Or else, maybe you can patch of the tables.c file to eliminate the > pitchbend lookup tables entirely and send it to me via e-mail?

If you know what you want to change, I can send you the updated file. It'd probably easier to switch to something like :-

> One more thing, I couldn't find a Windows executable of the latest > version of ZASFX, which is v. 2.4. Do you have a compiled version 2.4? > Or do I need to compile it myself too?

I have the Linux version from the Ubuntu repository. It doesn't have a version number, may be a custom build. I've never downloaded or used the Windows version.

Graham

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:
> Graham, can you elaborate how using linear interpolation with the lookup > tables will increase the pitch bend precision? Please be specific and > remember that I am a C programming dummy.

Sure. I don't need C, but I'll use bc (the Unix calculator) for examples.

The usual formula for converting a pitch difference in cents to a frequency ratio is

e(x*l(2)/1200)

where e() is the exp function, l() is the corresponding logarithm function, and x is the cents value. Because l(2)/1200 is a constant, that can be simplified to.

e(x*0.00057762265)

So it only requires one multiplication and the e() function, which is a basic piece of mathematics and sure to be in floating point processors or libraries.

The problem is that e() isn't that easy to calculate. There are standard algorithms that come from pure mathematics, but they require a relatively large number of operations to get an accurate result. You can also use a lookup table, which is a big list of known values kept in memory, like the log tables people used to use before desktop calculators.

The standard libraries (in either hardware or software) will use fairly sophisticated ways of calculating e() that involve lookup tables and are optimized to be very fast. For most of us, those are all we ever need. There are, however, cases where you may find an improvement by writing your own algorithm:

1) You're running on limited hardware (like a hardware synth) and don't have enough memory free for the lookup tables.

2) You need this function in a critical piece of code where every bit of optimization makes a difference.

3) A time machine has transported you back to the 1970s where even desktop processors are more limited and the libraries aren't so good.

There are other cases where you might not see an improvement, but start fiddling around anyway:

4) You're used to running on limited hardware and got into the habit of implementing these things yourself.

5) You didn't bother to check if the piece of code your working on is critical to performance or not.

6) You learned C programming from a text book written in the 1970s.

So, for whatever reason, you think you can do better then the standard library designers at writing an exponential function. Is that hubris? Maybe not. The point is, when you're dealing with pitch differences, you have a very good idea what range of values you're going to plug in and you don't need the full precision of your floating point variables. That allows you to take short-cuts that the standard library designers couldn't take account of. And the easiest thing to write is a lookup table.

The way Timidity does it is to split the calculation between two different lookup tables: one for equal tempered semitones and one for fine tunings smaller than a semitone. This is convenient because we only need to consider the fine tuning.

So the problem is to return the frequency ratio corresponding to an interval between 0 and 100 cents. The method they use is a 256 entry lookup table. The number 256 is chosen because you can get the index into the table from the original tuning specification by bit shifting, which is very fast. The lookup is also very fast, so we have a way of finding the frequency ratios accurately, but only in 1/256 semitone steps.

(Note: Csound users may be getting smug here, but you still have to be careful. Csound does also implement its own functions with limited precision. For example: "powoftwo() function returns 2 ^ x and allows positive and negatives numbers as argument. The range of values admitted in powoftwo() is -5 to +5 allowing a precision more fine than one cent in a range of ten octaves." Avoid this for microtonal work.)

Because 256 isn't a convenient number to work with in decimal, I'll instead talk about 100 divisions, or a resolution of 1 cent. Imagine a lookup table that gives you the tuning of an interval to the nearest cent.

The correct tuning of a 5:4 major third in cents is, from bc,

l(1.25)/l(2)*1200
386.31371386483481743200

reversing that calculation with limited precision gives

e(386.3137*0.00057762265)
1.24999998976386909720

Very close to 1.25. But our lookup table only gives us values to the nearest cent, so we have to choose between:

e(386*0.00057762265)
1.24977351000380408917

e(387*0.00057762265)
1.25049561602287101401

We know that both of these are close to what we want. We also know that they're both wrong. In fact, because we threw away a fractional part of 0.3137, we can guess that the true value is about 0.3137 of the way from the value for 386 cents and that for 387 cents. That gives a new expression:

e(386*0.00057762265)*(1-0.3137) + e(387*0.00057762265)*0.3137
1.25000003466198538348

You can see that this result is much closer to what we wanted -- and that's linear interpolation. The true size of the interval that came out is

l(1.25000003466198538348)*1200/l(2)
386.31376187124159514818

Not bad -- four decimal places in and nearly four out, or accuracy to better than a millicent. All this from a lookup table in cents. The calculation will be slower -- maybe it'll take two or three times as long -- and the lookup table is less than half the size of Timidity's.

You need to calculate the frequency every time a note is played, or the pitch wheel moves. That won't happen very often, compared to the rate at which any digital equipment has to process its samples. Merely doubling the time it takes shouldn't be significant. Unfortunately, the poor pitch resolution of many synthesizers shows that they aren't bothering :-(

Graham

🔗Ozan Yarman <ozanyarman@...>

✩ ✩ ✩
www.ozanyarman.com

On Oct 31, 2009, at 7:38 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>
>> So, if I eliminate the pitchbend lookup tables in Timidity entirely,
>> do I arrive at MTS with 16384 increments per interval (semitone,
>> wholetone, etc...)?
>
> Yes. But it's only as good as the sample set you're using.
> If the samples aren't tuned that accurately, the results
> won't be anyway. That's why you should go for a purely
> algorithmic approach for high-precision tuning.
>

So you mean that it is safer to keep the PB lookup tables and
implement linear interpolation?

>> I imagine trying to benchmark the different compilations of Timidity
>> on my powerful Macbook Pro will produce negligible results.
>
> Probably, yes. There may be a good reason for the
> optimization but without seeing benchmarks I'll assume not.
>
>> Wait, did you say that the audio might crackle again after this? I
>> hope it's not so.
>
> I doubt it.
>
>> Or else, maybe you can patch of the tables.c file to eliminate the
>> pitchbend lookup tables entirely and send it to me via e-mail?
>
> If you know what you want to change, I can send you the
> updated file. It'd probably easier to switch to something
> like :-
>

Send me both a version of tables.c with no lookup tables and maximum
precision and another version with 256 divisions of the equal semitone
improved with linear interpolation. I'll test both versions if I can
ever successfully compile Timidity for Windows.

>> One more thing, I couldn't find a Windows executable of the latest
>> version of ZASFX, which is v. 2.4. Do you have a compiled version
>> 2.4?
>> Or do I need to compile it myself too?
>
> I have the Linux version from the Ubuntu repository. It
> doesn't have a version number, may be a custom build. I've
> never downloaded or used the Windows version.
>

Ok.

>
> Graham
>
>
>

Oz.

🔗Ozan Yarman <ozanyarman@...>

✩ ✩ ✩
www.ozanyarman.com

On Oct 31, 2009, at 8:28 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>> Graham, can you elaborate how using linear interpolation with the
>> lookup
>> tables will increase the pitch bend precision? Please be specific and
>> remember that I am a C programming dummy.
>
> Sure. I don't need C, but I'll use bc (the Unix calculator)
> for examples.
>
> The usual formula for converting a pitch difference in cents
> to a frequency ratio is
>
> e(x*l(2)/1200)
>
> where e() is the exp function, l() is the corresponding
> logarithm function, and x is the cents value. Because
> l(2)/1200 is a constant, that can be simplified to.
>
> e(x*0.00057762265)

Where l is ln, or neperian (natural) logarithm of course. The same
results can be obtained by the formula:

2^(cents/1200)

>
> So it only requires one multiplication and the e() function,
> which is a basic piece of mathematics and sure to be in
> floating point processors or libraries.
>

Agreed.

> The problem is that e() isn't that easy to calculate. There
> are standard algorithms that come from pure mathematics, but
> they require a relatively large number of operations to get
> an accurate result. You can also use a lookup table, which
> is a big list of known values kept in memory, like the log
> tables people used to use before desktop calculators.
>

So far so good.

> The standard libraries (in either hardware or software) will
> use fairly sophisticated ways of calculating e() that
> involve lookup tables and are optimized to be very fast.
> For most of us, those are all we ever need. There are,
> however, cases where you may find an improvement by writing
> your own algorithm:
>
> 1) You're running on limited hardware (like a hardware
> synth) and don't have enough memory free for the lookup tables.
>
> 2) You need this function in a critical piece of code where
> every bit of optimization makes a difference.
>
> 3) A time machine has transported you back to the 1970s
> where even desktop processors are more limited and the
> libraries aren't so good.
>
> There are other cases where you might not see an
> improvement, but start fiddling around anyway:
>
> 4) You're used to running on limited hardware and got into
> the habit of implementing these things yourself.
>
> 5) You didn't bother to check if the piece of code your
> working on is critical to performance or not.
>
> 6) You learned C programming from a text book written in the
> 1970s.
>
> So, for whatever reason, you think you can do better then
> the standard library designers at writing an exponential
> function. Is that hubris? Maybe not. The point is, when
> you're dealing with pitch differences, you have a very good
> idea what range of values you're going to plug in and you
> don't need the full precision of your floating point
> variables. That allows you to take short-cuts that the
> standard library designers couldn't take account of. And
> the easiest thing to write is a lookup table.
>

Ok.

> The way Timidity does it is to split the calculation between
> two different lookup tables: one for equal tempered
> semitones and one for fine tunings smaller than a semitone.
> This is convenient because we only need to consider the
> fine tuning.

Right.

>
> So the problem is to return the frequency ratio
> corresponding to an interval between 0 and 100 cents. The
> method they use is a 256 entry lookup table. The number 256
> is chosen because you can get the index into the table from
> the original tuning specification by bit shifting, which is
> very fast.

Bit shifting? Please elaborate here. What number other than 256 is
appropriate for this bit shifting? Is 1024 such a number for example?

> The lookup is also very fast, so we have a way
> of finding the frequency ratios accurately, but only in
> 1/256 semitone steps.
>

So far so good.

> (Note: Csound users may be getting smug here, but you still
> have to be careful. Csound does also implement its own
> functions with limited precision. For example: "powoftwo()
> function returns 2 ^ x and allows positive and negatives
> numbers as argument. The range of values admitted in
> powoftwo() is -5 to +5 allowing a precision more fine than
> one cent in a range of ten octaves." Avoid this for
> microtonal work.)
>
> Because 256 isn't a convenient number to work with in
> decimal, I'll instead talk about 100 divisions, or a
> resolution of 1 cent. Imagine a lookup table that gives you
> the tuning of an interval to the nearest cent.
>
> The correct tuning of a 5:4 major third in cents is, from bc,
>
> l(1.25)/l(2)*1200
> 386.31371386483481743200

Or otherwise = log(10) 1.25 x 1200 / log(10) 2.

>
> reversing that calculation with limited precision gives
>
> e(386.3137*0.00057762265)
> 1.24999998976386909720
>
> Very close to 1.25. But our lookup table only gives us
> values to the nearest cent, so we have to choose between:
>
> e(386*0.00057762265)
> 1.24977351000380408917
>
> e(387*0.00057762265)
> 1.25049561602287101401

I'm getting this now.

>
> We know that both of these are close to what we want. We
> also know that they're both wrong. In fact, because we
> threw away a fractional part of 0.3137, we can guess that
> the true value is about 0.3137 of the way from the value for
> 386 cents and that for 387 cents. That gives a new expression:
>
> e(386*0.00057762265)*(1-0.3137) + e(387*0.00057762265)*0.3137
> 1.25000003466198538348
>
> You can see that this result is much closer to what we
> wanted -- and that's linear interpolation. The true size of
> the interval that came out is
>
> l(1.25000003466198538348)*1200/l(2)
> 386.31376187124159514818
>
> Not bad -- four decimal places in and nearly four out, or
> accuracy to better than a millicent. All this from a lookup
> table in cents.

Fabulous.

> The calculation will be slower -- maybe
> it'll take two or three times as long -- and the lookup
> table is less than half the size of Timidity's.
>

So, all that is needed is to add the arguments for linear
interpolation whilst preserving the original 256 equal divisions of
the semitone tuning resolution. That way the actual increments we'll
be working with shall be much smaller than 0.39 cents. Right?

> You need to calculate the frequency every time a note is
> played, or the pitch wheel moves. That won't happen very
> often, compared to the rate at which any digital equipment
> has to process its samples. Merely doubling the time it
> takes shouldn't be significant. Unfortunately, the poor
> pitch resolution of many synthesizers shows that they aren't
> bothering :-(

Good thing that there is Timidity++ then!

>
>
> Graham
>
>

Oz.

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:

>> e(x*l(2)/1200)

> Where l is ln, or neperian (natural) logarithm of course. The same > results can be obtained by the formula:
> > 2^(cents/1200)

That's it. But not, as it happens, in bc, because the ^ operator doesn't work with non-integer powers. And this may correspond to how the underlying hardware works, and so may be a difference you care about.

>> So the problem is to return the frequency ratio
>> corresponding to an interval between 0 and 100 cents. The
>> method they use is a 256 entry lookup table. The number 256
>> is chosen because you can get the index into the table from
>> the original tuning specification by bit shifting, which is
>> very fast.
> > > Bit shifting? Please elaborate here. What number other than 256 is > appropriate for this bit shifting? Is 1024 such a number for example?

There are 14 bits of fine tuning, right? 256 requires 8 bits, so you throw away bits. 1024 is, indeed, another number that works. It needs 10 bits and you throw away 4. A number that doesn't work is 100. Dividing by 100 in binary is more difficult than repeatedly dividing by 2 -- but obviously easier in decimal. The numbers that work are 2^n for integer n.

>> The calculation will be slower -- maybe
>> it'll take two or three times as long -- and the lookup
>> table is less than half the size of Timidity's.
> > So, all that is needed is to add the arguments for linear > interpolation whilst preserving the original 256 equal divisions of > the semitone tuning resolution. That way the actual increments we'll > be working with shall be much smaller than 0.39 cents. Right?

That's it. But it's still easier to keep the original expression and let the standard libraries sort it out if you're on desktop hardware.

>> You need to calculate the frequency every time a note is
>> played, or the pitch wheel moves. That won't happen very
>> often, compared to the rate at which any digital equipment
>> has to process its samples. Merely doubling the time it
>> takes shouldn't be significant. Unfortunately, the poor
>> pitch resolution of many synthesizers shows that they aren't
>> bothering :-(
> > Good thing that there is Timidity++ then!

No, that's an example of an application that doesn't bother with interpolation. ZynAddSubFX is apparently better, though, and Csound can use the 64-bit standard library.

Graham

🔗Graham Breed <gbreed@...>

Ozan Yarman wrote:
> ✩ ✩ ✩
> www.ozanyarman.com
> > On Oct 31, 2009, at 7:38 AM, Graham Breed wrote:
> >> Ozan Yarman wrote:
>>
>>> So, if I eliminate the pitchbend lookup tables in Timidity entirely,
>>> do I arrive at MTS with 16384 increments per interval (semitone,
>>> wholetone, etc...)?
>> Yes. But it's only as good as the sample set you're using.
>> If the samples aren't tuned that accurately, the results
>> won't be anyway. That's why you should go for a purely
>> algorithmic approach for high-precision tuning.
> > So you mean that it is safer to keep the PB lookup tables and > implement linear interpolation?

No, I mean it may not be worth bothering. If your samples aren't tuned to MTS precision it doesn't matter how precisely Timidity retunes them -- unless it does something clever with pitch recognition, which I doubt. But ZynAddSubFX or VAZ Plus or Csound don't require real-world samples and so you can get much better control over the pitch. So if you really care about this level of precision you may be better off without a sampler.

If you want to work with SoundFonts you may have to stomach this level of imprecision. I have a vague idea that the SoundFont standard doesn't specify the pitch of samples any more precisely than Timidity's tuning tables anyway ... which would be a good reason why Timdity uses that level of precision.

> Send me both a version of tables.c with no lookup tables and maximum > precision and another version with 256 divisions of the equal semitone > improved with linear interpolation. I'll test both versions if I can > ever successfully compile Timidity for Windows.

I can do that if you're ready to compile it. I can also send you ZynAddSubFX instruments because I'm playing with it now. Maybe other people can help you there as well.

Graham

🔗Ozan Yarman <ozanyarman@...>

Hello Graham, a late reply:

On Nov 2, 2009, at 8:05 AM, Graham Breed wrote:

> Ozan Yarman wrote:
>> ✩ ✩ ✩
>> www.ozanyarman.com
>>
>> On Oct 31, 2009, at 7:38 AM, Graham Breed wrote:
>>
>>> Ozan Yarman wrote:
>>>
>>>> So, if I eliminate the pitchbend lookup tables in Timidity
>>>> entirely,
>>>> do I arrive at MTS with 16384 increments per interval (semitone,
>>>> wholetone, etc...)?
>>> Yes. But it's only as good as the sample set you're using.
>>> If the samples aren't tuned that accurately, the results
>>> won't be anyway. That's why you should go for a purely
>>> algorithmic approach for high-precision tuning.
>>
>> So you mean that it is safer to keep the PB lookup tables and
>> implement linear interpolation?
>
> No, I mean it may not be worth bothering. If your samples
> aren't tuned to MTS precision it doesn't matter how
> precisely Timidity retunes them -- unless it does something
> clever with pitch recognition, which I doubt.

I have experienced firsthand that the same soundfont contains patches
that respond differently to pitch bends. One patch was a Reed Organthat only accepted cent increments, and the other was a Fantasia Pad
that at least accepted 0.39 cent increments (due to the restriction of
Timidity++ maybe?).

> But
> ZynAddSubFX or VAZ Plus or Csound don't require real-world
> samples and so you can get much better control over the
> pitch. So if you really care about this level of precision
> you may be better off without a sampler.
>

I concur.

> If you want to work with SoundFonts you may have to stomach
> this level of imprecision. I have a vague idea that the
> SoundFont standard doesn't specify the pitch of samples any
> more precisely than Timidity's tuning tables anyway ...

Yes, there is always the danger of that happening.

> which would be a good reason why Timdity uses that level of
> precision.

Possibly.

>
>> Send me both a version of tables.c with no lookup tables and maximum
>> precision and another version with 256 divisions of the equal
>> semitone
>> improved with linear interpolation. I'll test both versions if I can
>> ever successfully compile Timidity for Windows.
>
> I can do that if you're ready to compile it.

I found this document on the internet for the compiling of Timidity++:

http://www.csee.umbc.edu/help/sound/TiMidity++-2.13.2/doc/C/README.w32

It seems a lot of work, but I already set up Mingw and Msys (am not
sure what additional libraries and components are needed), Got the
pexports, pdcurses... I downloaded Oggvorbis, Gogo nocoder, Flac,
Portaudio and Portmidi, but the instructions require me to compile
them seperately, at which I was not successful.

> I can also
> send you ZynAddSubFX instruments because I'm playing with it
> now. Maybe other people can help you there as well.
>

Yes, I would very much like to have your ZASFX instruments.

>
> Graham
>
>

Cordially,
Oz.