gmane.comp.gnome.beast

Re: MERGE: bse2cxx-part4

Tim Janik — 2011-08-05T18:57:44

Are you saing that GTokenType var; can hold a value *other* than the 
possible enum values, but that narrowing occours:
- not when reading it out by printf (shows "other")
- not when assigning var ot an int (assigns "other")
- only when assigning var to a uint (assigns a close enum value)
?

That sounds utterly broken to me. If at all, I'd expect the narrowing to 
occour on the *assignment*of*var*.


Nope, I thought our normal tests run by make check or installcheck are 
good enough to trigger this?
I'm running make report only close to releases because the suite takes 
so long with it, any progress on the bsescm speedups btw? ;)


Ah, I see what you were referring to now.


That was from before you gave a good explanation on why we should fix 
it. It's one of those other tihngs on my list that didn't get high 
priority because it patches Birnet. I'd much rather see a patch to 
rapicorn at some point and have the Beast sources use Rapicorn-core, 
which is much more solid than Birnet these days. (Rather than

Re: MERGE: bse2cxx-part5

Tim Janik — 2011-08-05T18:35:18

Thanks again.

-      self->controls[1] = g_value_get_enum (value);
+      self->controls[1] = BseMidiSignalType (g_value_get_enum (value));

This should rather be:
+      self->controls[1] = (BseMidiSignalType) g_value_get_enum (value);

We see a lot of those enum conversion though, so I'm wondering if it 
isn't better for the code base to allow automatic int->enum conversion 
operators... Any experience with that?

MERGE: bse2cxx-part5

Stefan Westerfeld — 2011-08-05T17:47:55

   Hi!

I've ported a few bse more sources to C++, no problems occurred.

git fetch http://space.twc.de/public/git/stwbeast.git bse2cxx-part5:bse2cxx-part5

  Cu... Stefan

Re: MERGE: bse2cxx-part4

Stefan Westerfeld — 2011-08-02T11:25:00

   Hi!

On Mon, Aug 01, 2011 at 06:17:36PM +0200, Tim Janik wrote:

I can try, but sometimes gboolean and bool will behave a little different, so
thats not just search & replace, but every case needs to be checked after
conversion.

I try to do that.


Well targetting windows, at this point, mostly means targetting win32; then
long should work (as pointers are still 32-bit). I've never built code
targetting 64-bit windows, and last time I checked, the gcc/mingw toolchain did
not support it (we need gcc on windows anyway). I don't know if a 64-bit gcc on
windows would have sizeof (long) == 8. In any case ptrdiff_t is fine with me,
so I'll try to use this in the future.


$ make report
...
TEST: adsr-wave-1-test
make[4]: Entering directory `/home/stefan/src/beast/tests/audio'
../../shell/bsescm-0.7.5 --bse-mixing-freq=48000 -p null=nosleep -m null --bse-rcfile "/dev/null" --bse-no-load --bse-override-plugin-globs '../../plugins/.libs/*.so:../../plugins/freeverb/.libs/*.so' --bse-override-sample-path '../../tes

Re: MERGE: bse2cxx-part4

Tim Janik — 2011-08-01T16:17:36

Great, the most parts look really good, thanks for doing the work.
Things that can still use polishing:
- gboolean -> bool
- "(gpointer)" -> "(void*)", no extra space, i.e. not (void *)

This is not ok:
-    i = (guint) g_param_spec_get_qdata (pspec, ...);
+    i = (unsigned long) g_param_spec_get_qdata (pspec, ...);

Never introduce a long, it's an evil type that should never be used (see 
my other emails on the list). Not even for 64bit pointer conversions 
(breaks on windows). For pointer -> int conversions, you need to:
uint i = ptrdiff_t (some_pointer);



I can't reproduce any problem here, running:
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5

Could you elaborate on the exact error you're seeing?

Re: MERGE: bse2cxx-part3

Tim Janik — 2011-08-01T15:46:47

Another thing you can do is s/gboolean/bool/. This could have been done 
in plain C even, as C99 provides bool. Keep an eye on pointers though, 
because gboolean really is an int, while sizeof(bool) == 1.

MERGE: bse2cxx-part4

Stefan Westerfeld — 2011-08-01T15:04:19

   Hi!

I've ported a few bse more sources to C++. The very last commit regarding enum
conversion is a little odd, but required for g++-4.4 (see commit log).
Everything else should be straight forward, and make report passes within the
branch.

git fetch http://space.twc.de/public/git/stwbeast.git bse2cxx-part4:bse2cxx-part4

  Cu... Stefan

Re: MERGE: bse2cxx-part3

Tim Janik — 2011-07-28T09:43:30

See, what i wrote above, uint8 here...


This one is worse, rather leave it as gulong and lets go in a seperate 
step over the code to remove all longs.


I don't get this one, space separation?

Re: MERGE: bse2cxx-part3

Stefan Westerfeld — 2011-07-27T18:03:12

   Hi!

On Tue, Jul 26, 2011 at 04:17:37AM +0200, Tim Janik wrote:

Ok. Here is my cxxport.pl script, let me know if you need changes to that.

#!/usr/bin/perl -w -pi.bak
s,\bclass\b,klass,g;
s,\bgint\b,int,g;
s,\bguint\b,uint,g;
s,\bgdouble\b,double,g;
s,\bgfloat\b,float,g;
s,\bgchar\b,char,g;
s,\bguchar\b,unsigned char,g;
s,\bglong\b,long,g;
s,\bgulong\b,unsigned long,g;
s,\bgpointer\b,void *,g;
s,\bgconstpointer\b,const void *,g;
s,parent klass,parent class,g;

   Cu... Stefan

Re: Gsl FFT <-> FFTW compatibility

Stefan Westerfeld — 2011-07-26T14:30:16

Well, so then  lets look at the changes in pre-/postprocessing in the inner
loop:

****** Analysis:

diff --git a/bse/gsl-fftconf.sh b/bse/gsl-fftconf.sh
...
< at >< at > -309,12 +349,12 < at >< at > gsl_power2_fftar (const unsigned int n_values,
       H1im = F2im + F1re;
       H1re = F1im - F2re;
       H2re = F2re - F1im;
-      H2im = H1im - FEim;
+      H2im = FEim - H1im;
       H1re += FEre;
       H2re += FEre;
       H1im += FEim;
       rivalues_out[i] = H1re;
-      rivalues_out[i + 1] = H1im;
+      rivalues_out[i + 1] = -H1im;
       rivalues_out[r] = H2re;
       rivalues_out[r + 1] = H2im;
       WMULTIPLY (Wre, Wim, Dre, Dim);
...

The first change should not affect performance, the second change is one
additional negation per complex output.

****** Synthesis:

< at >< at > -360,9 +403,8 < at >< at > gsl_power2_fftsr (const unsigned int n_values,
       ri |= j;
 
       FOre = -FOre;
-      FOim = -FOim;
       FEre *= 0.5;
-      FEim *= 0.5;
+      FEim *= -0.5;
       F2re = FOre * Wim;
       F2im = FOim * Wim;
       F1re

Re: MERGE: bse2cxx-part3

Tim Janik — 2011-07-26T02:17:37


Thanks, great. I see you put a lot of work in there,
here're my bits:
- please use "uint" in the future, see my other mail.
- remove cxxdummy.cc from compilation rules if another C++ source is present.
- "void * boxed" should be "void *boxed" (unfixed in master)
- pointer casts should be written as: (void*) ptr
   (no extra space between "void" and "*")

Thanks again, applied.


Yours sincerely,
Tim Janik

---
http://lanedo.com/~timj/ - Founder and CEO of Lanedo GmbH.
Free software author and contributor on various projects.

Re: MERGE: bse2cxx-part2

Tim Janik — 2011-07-26T02:14:54


Eeek, "unsigned int" causes too much reformatting in your
latest patch. This should be "uint" instead, uint is provided
by sys/types.h, which is included by birnet*.
I've fixed up your changes now, please use these types in the
future:

uint
uint8for "byte" contexts, e.g. memory allocation
int8for signed "byte" contexts, e.g. memory allocation
charfor character contexts.

uint8/int8 *may* be missing, until we have rapicorn, if that#s
the case, just fixup birnetcdefs.h to define them.
Also, any use of "long" should be revisitted in the source, it's
allmost always an error to use long, since it varies so much
(32bit on some 32bit-platoforms, 64bit on 64bit-unix, 32bit on
64bit-windows).

bseresampler.hh didn't compile here once i applied the uint
fixes. It's just been including glib.h. All header files in
a specific directory should always include one "base" header
out of the same dir, that brings in the main definitions, e.g.
bse/bsecxxutils.hh for C++ bse, or bse/bseutils.h for C,
sfi.hh for sfi/, birne

Re: Gsl FFT <-> FFTW compatibility

Tim Janik — 2011-07-26T01:31:04



I see, thanks for the explanation. It seems that you already adapted the
post/pre processing, and given that the real valued fft routines don't
match the complex valued one, I'd guess that you added additional ops in
one or both of the post/pre processing routines which likely make things
slower, right?


Yours sincerely,
Tim Janik

---
http://lanedo.com/~timj/ - Founder and CEO of Lanedo GmbH.
Free software author and contributor on various projects.

Re: Gsl FFT <-> FFTW compatibility

Stefan Westerfeld — 2011-07-25T14:02:36

   Hi!

On Mon, May 16, 2011 at 11:35:32PM +0200, timj< at >gnu.org wrote:

Right, I changed it to MAX_DFT_SIZE now.


Because the DFT implementation is a lot slower than your
reference_power2_fftc implementation. So we only check small FFT sizes with
the DFT implementation (which is easy to check for correctness, because the
code is very simple), and all FFT sizes with your implementation.


It was there before my changes, so I kept it as it is.


To make gslfft behave like FFTW, we change gsl_power2_fftac to do what was
previously done by gsl_power2_fftsc. Same thing for gsl_power2_fftac. We also
rename gsl_power2_fft*analysis_skip2 to gsl_power2_fft*synthesis_skip2. So for
complex ffts, everything is consistent.

However, there are the real variants, which used to work like that

fftar: real data -> fftac -> post processing -> complex output
fftsr: complex data -> pre processing -> fftsc -> real output

I changed these to FFTW behaviour by adjusting the (pre/post) processing steps,
so we have

fftar: real data

MERGE: bse2cxx-part3

Stefan Westerfeld — 2011-07-22T12:58:07

   Hi!

I've ported a few bse more sources to C++. Sorry about minor mistakes in the
commit order. Anyway, you can fetch the branch into your bse repo by using:

git fetch http://space.twc.de/public/git/stwbeast.git bse2cxx-part3:bse2cxx-part3

  Cu... Stefan

Re: MERGE: soundfont-support

Stefan Westerfeld — 2011-07-14T16:37:48

   Hi!

On Wed, Jul 13, 2011 at 12:54:17PM +0200, Tim Janik wrote:

No, it doesn't; I've just compared fluidsynth with effects and stwbeast with
SoundFont support using oprofile, and stwbeast doesn't spend any time on the
fluidsynth reverb and chorus functions.


Of course it would be possible to somehow render the fluidsynth effects
and get the result as extra mixer channel in beast. However, I would not
recommend that, because as soon as you do anything more than 1:1 playing,
things will go wrong. For instance, if you put a post-network on one of
the fluidsynth beast tracks, the fluidsynth effect rendering will render the
reverb without the post-network.

More unnatural behaviour follows if you use the mixer beast provides.
For instance if you solo or mute a track, the fluidsynth effects will
still include all tracks. If you use the mixer to amplify one of the
tracks, the fluidsynth effects will not change accordingly.

The other option would be to use one fluidsynth instance per track. But
not only the cp

synthesizer

wijaya adidarma — 2011-07-08T18:33:41

Dear Sir,

I would like to know if you could support me for developing synthesizer
keyboard with 128 polyphonic , 76 keys, with rich of sound library ( piano,
string, flute , drum , bass, etc ).

I am using ARM9 processor under linux operating system.

Thank you for your kind attention.

Best Regards,

wijaya adidarma
_______________________________________________
beast mailing list
beast< at >gnome.org
http://mail.gnome.org/mailman/listinfo/beast

Re: MERGE: bse2cxx-part2

Stefan Westerfeld — 2011-07-07T11:04:26

   Hi!

On Tue, Jul 05, 2011 at 12:27:24PM +0200, Tim Janik wrote:

Right, I didn't take into account that running the script would probably
require manual fixing in every file anyway, for instance because of the
indentation. So we do it your way: one file at a time.

(Btw, I'm readding the beast list to CC, I think this started as public
discussion, so it should remain public).

   Cu... Stefan

Re: MERGE: bse2cxx-part2

Stefan Westerfeld — 2011-07-05T07:56:14

   Hi!

On Mon, Jul 04, 2011 at 09:55:05PM +0200, Tim Janik wrote:


Sounds good. I think it would be best to first run a script on all C sources,
like

class -> klass
gint -> int
guint -> unsigned int
gdouble -> double
gfloat -> float
gchar -> char
guchar -> unsigned char

(did I forget anything?). I can make a merge request for that.

Once this is done, manual porting can do the rest, but that should be done in
seperate commits, to make it easy to review what was manually changed between
the C -> C++ transition.

   Cu... Stefan

MERGE: bse2cxx-part2

Stefan Westerfeld — 2011-07-01T17:38:15

   Hi!

I've read your remarks on my first attempt to port bsebus.c to C++, so in this
merge request you'll find a version I adjusted accordingly. There are also C++
ports of a few more sources in the bse/ directory.

repo:   http://space.twc.de/public/git/stwbeast.git
branch: bse2cxx-part2

   Cu... Stefan

MERGE: bse2cxx-part1

Stefan Westerfeld — 2011-06-26T19:56:12

   Hi!

I've started to port bse/ to C++. There are a lot of sources in this directory,
so I'll send more merge requests once this one is reviewed:

repo:   http://space.twc.de/public/git/stwbeast.git
branch: bse2cxx-part1

   Cu... Stefan