Needs alternate tuning capability

[GoogleCodeExporter]

I currently use ZynAddSubFX as a softsynth with alternate tuning (microtonal, 
xenharmonic) capability. But I don't really like ZynAddSubFX because its user 
interface is pretty bad, and it seems old and unmaintained.

Amsynth seems much nicer and simpler, and also sounds much better, at least on 
the default settings, which is perfect for me. All it needs is a way to map 
MIDI notes to different frequencies than those of 12-per-octave equal 
temperament.

I see that the tuning map is currently set in a single line of 
VoiceAllocationUnit.cc:

_voices.back()->setFrequency ((440.0f/32.0f) * pow (2.0f, 
(float)((i-9.0)/12.0)));

which makes it really straightforward to add alternate tuning capability.

I would be more than happy to add this myself and submit a patch, but I want to 
make sure it will get merged in to the main distribution, so let's talk 
specifics.

I'm imagining a single new menu option, "Load alternate tuning map", that would 
read frequencies (or cents, or whatever) from a text file for each of the 128 
MIDI notes. If you don't select that option, it would act exactly the same as 
before and 12 equal temperament would be the default.

Do you see any problems with that?

Original issue reported on code.google.com by keenanpe...@gmail.com on 21 May 2011 at 7:36

[GoogleCodeExporter]

I would be happy to accept patches to amsynth to add features such as this.

I have never experimented with alternate tunings, so will have to rely upon 
your judgement regarding how to make it usable and practical.

Might it not be annoying for users if they have to load the alternate tuning 
map every time they launch the synth? Should amsynth save the tuning map in its 
settings?

Would it be beneficial to have some of the more popular alternate tunings 
included, or do different people set up alternate tunings differently?

Original comment by nickdowell on 22 May 2011 at 1:36

[GoogleCodeExporter]

I think Scala format (http://www.huygens-fokker.org/scala/scl_format.html) is 
the way to go, because it's a nice simple text file, but also standardized.

Saving the current tuning map in the settings is probably a good idea at some 
point.

I think it's better not to have any specific tunings by default, because they 
come in so many different versions. Better just to keep it very general and 
then users can use any tuning for which there's a Scala file equally easily. 
(For example, all of the ones in this big archive: 
http://www.huygens-fokker.org/scala/downloads.html#scales)

Original comment by keenanpe...@gmail.com on 22 May 2011 at 7:51

[GoogleCodeExporter]

Hmm, I just tried building amsynth after writing some new code, but it failed 
because my code used exceptions and apparently amsynth is compiled with the 
flag "-fno-exceptions".

Any particular reason for this? Does it mean I shouldn't use exceptions in code 
for amsynth?

Original comment by keenanpe...@gmail.com on 23 May 2011 at 6:26

[GoogleCodeExporter]

I don't recall any special reason for turning off exceptions, it's probably 
safe to remove the -fno-exceptions option from configure.in

None of the existing code is set up to catch exceptions, though, so throwing 
one will just terminate the application...

Original comment by nickdowell on 23 May 2011 at 12:22

[GoogleCodeExporter]

I just read that gtkmm doesn't provide for exceptions to be thrown "through" 
its code (callbacks and such), which makes them less useful anyway, so I think 
I'll just avoid exceptions.

Original comment by keenanpe...@gmail.com on 23 May 2011 at 3:54

[GoogleCodeExporter]

OK, here are my patches, thoroughly tested and debugged.

In addition to alternate-tuning.patch which adds alternate tuning support via 
Scala .scl and .kbm files, there is also repair-dangerous-buffers.patch which 
fixes some potentially dangerous uses of statically allocated char[] buffers, 
sprintf, etc., which I found. I'm sure some didn't really need to be changed, 
but I think it's better to be consistent about using better methods like 
stringstream.

The patches can be applied in either order.

Original comment by keenanpe...@gmail.com on 30 May 2011 at 6:42

Attachments:

• alternate-tuning.patch
• repair-dangerous-buffers.patch

[GoogleCodeExporter]

Many thanks, I have checked over your patches and accepted them as-is.
Time to prepare a new beta release!

Original comment by nickdowell on 31 May 2011 at 5:17

• Changed state: Fixed
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

One small bugfix:

If you try to read a Scala .scl file with an empty description (such as Scala 
produces if you leave the description blank), the parser I wrote gets confused 
and thinks the next non-empty line is the description, which usually causes it 
to error out and not load the scale. To fix this, simply change this line:

                if (i == line.size()) continue; // skip all-whitespace lines

to this:

                if (i == line.size() && gotDesc) continue; // skip all-whitespace lines after the description

Original comment by keenanpe...@gmail.com on 17 Jun 2011 at 9:17

[GoogleCodeExporter]

Found another bug (trying to read a non-existant file makes program spin). 
Here's the fix together with the previous one in a single patch.

Original comment by keenanpe...@gmail.com on 18 Jun 2011 at 7:46

Attachments:

• file-reading-bugfixes.patch

[GoogleCodeExporter]

Thanks! Integrated in r436

Original comment by nickdowell on 20 Jun 2011 at 8:29