While testing some mixed floating point and integer calculations I found a
quite surprising difference when this compiler option was set (gcc 6.x). It was
clearly different at only 100 iterations and got dramatically worse with
larger counts.
My test routine was this:
int a = 0;
float b = 0;
float c = 0;
float inc = 0.1f;
float dec = 0.05f;
int it = 100;
for (int i = 0; i < it; ++ i)
{
a = (int)truncf(b);
c = b - floorf(b);
b += inc;
a = (int)truncf(b);
c = b - floorf(b);
b -= dec;
}
cout << "int " << a << " rem " << c << endl;
My suspicion is that the difference is due to accumulated rounding errors.
Curiously without the decrements the behavior with and without -ffast-math
seems to be identical well into the millions.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Linux Audio Music has been dormant for a very long time, but recently I
contacted the the person who hosted and ran it.
The reason he closed it was because of a serious vulnerability was discovered in
Rails, and he no longer had time to do the necessary upgrades.
However, he has told me that he still has the entire database and the code. In
his own words:
"... would be happy to host and do what I can to facilitate a handoff to
someone else who wants to manage it."
For anyone who doesn't know, this was a relatively simple and clean site aimed
specifically at providing a home for tracks composed with Linux - something
rather rare!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I'm seeing 'can't retrieve the current commit' on several quite different
projects.
Anyone else seeing this?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Hi all.
Next meeting at c-base is on Tuesday 2018-11-06 at 20:00.
To avoid cross-posting too much on the mailing lists I'd like the
follow-up discussion to happen in the thread to the invitation mail I
sent to the linux-audio-user list.
Cheers
        /Daniel
Hello list,
I recently tried out petri-foo and I like it enough to care about it in
the form of bug reports.
I don't know how to contact the developers though.
The website http://petri-foo.sourceforge.net/ says last release 2012,
the github repository is switched to read-only.
Did I miss the active development place somehow? Fork of a fork?
-hgn
Hi list, I'm working on version 2 of MusE's safe plugin
scanner which now creates cached text lists of all plugins
found on the system, seven formats: ladspa, dssi, dssi-vst,
LinuxVst, vst, lv2, and our own MESS).
Currently each cache file is a custom xml template describing all
the various features of each plugin found, in one common format.
For six of the formats listed above it went smoothly but when
I made the LV2 section I kept thinking - I'm re-inventing the wheel.
LV2 already uses Turtle text description files, so it was a bit odd
making a converter from/to my xml format to/from lilv ttl scans.
Question: Can rdf, or ladspa rdf, or Turtle files be used to
generally specify ANY type of plugin, so that the various
tools and libraries associated with rdf, lrdf, or ttl or lv2
can read them in a common way?
This would also allow me to introduce lrdf (or something rdf-based)
into MusE and really take advantage of features like enumerated
value strings and so on.
It'd be great if some rdf tool or library function could scan all
my existing ladspa and dssi (and other) plugins for me and present
me with an rdf file so I don't have to do all the work.
Even if the file might lack the ability to fill in those ladspa
enumeration value strings when scanning an unidentifiable plugin.
Thanks.
Tim.
