Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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:
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
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
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:
Thanks! Integrated in r436
Original comment by nickdowell
on 20 Jun 2011 at 8:29
Original issue reported on code.google.com by
keenanpe...@gmail.com
on 21 May 2011 at 7:36