headers
Tim Janik | 5 Aug 20:57
Picon
Gravatar

Re: MERGE: bse2cxx-part4

On 02.08.2011 14:42, Stefan Westerfeld wrote:
> In the bseloader-bsewave.cc code, the next step is to convert that enum value
> into an uint type variable. Finally, we switch on the uint value. The thing
> that happens is that although the value get_b() returned was 4, the case 3:
> code is executed.
>
> Now one might say that b never had the value 4 in the first place (as you
> say due to narrowing the assignment to the possible enum choices), but a
> printf on b's value confirms that its in fact 4.

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*.

> Have you tried make report on your machine yet?

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? ;)

>> What do you mean, why is compilation with gcc-4.5 not allowed?
>
> Well, you can try, but g++-4.5 will stop compiling with these error messages.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Westerfeld | 5 Aug 19:47
Picon

MERGE: bse2cxx-part5

   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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 1 comment |
headers
Stefan Westerfeld | 1 Aug 17:04
Picon

MERGE: bse2cxx-part4

   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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 2 comments |
headers
Stefan Westerfeld | 22 Jul 14:58
Picon

MERGE: bse2cxx-part3

   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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 4 comments |
headers
Stefan Westerfeld | 14 Jul 18:37
Picon

Re: MERGE: soundfont-support

   Hi!

On Wed, Jul 13, 2011 at 12:54:17PM +0200, Tim Janik wrote:
> On 24.11.2010 00:33, Stefan Westerfeld wrote:
> >2) we use one fluidsynth instance for both tracks - fluidsynth supports this
> >model explicitely, and its what the patch currently uses. In this case, we get
> >two stereo audio tracks rendered by fluidsynth, which we can route through the
> >mixer. This is nice, because volume control or after effects (once supported by
> >the mixer) can be done through the mixer. We also get volume metering in the
> >mixer for each channel. So using one fluidsynth instance is really enough for
> >what we need.
> >
> >But what about reverb/chorus in this model? Fluidsynth explicitely supports the
> >multi track mode we're using here, so they thought of a solution: instead of
> >processing reverb and chorus for each channel seperately, fluidsynth assumes
> >that a fraction of each channel's output should be sent through an effects bus
> >(one stereo bus), and then reverb should be done for all channels combined.
> >Later, we should add in the fx bus to the result. That way, they minimize the
> >cpu power required for reverb computation: instead of using cpu power to
> >compute - in our use-case - reverb for the Piano and reverb for the Violin,
> >they use one extra effects track (combining maybe 20% of the Piano output and
> >10% of the Violin output). Thats cheaper, especially for many channels. And it
> >sounds exactly the same if you add the effects bus back in, because the reverb
> >is an LTI system.
> >
> >However, it doesn't map well into our model. We can map the two output tracks
> >to the mixer, but not the fx bus. For instance, if you turn down the volume of
> >the Piano channel in the mixer (extreme case: mute it), fluidsynth would not
> >notice, because the mixer is *after* the fluidsynth processing. Result: the
> >Piano would still be in the fx bus.
(Continue reading)

Permalink | Reply | 0 comments |
headers
wijaya adidarma | 8 Jul 20:33
Picon

synthesizer

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
Permalink | Reply | 0 comments |
headers
Stefan Westerfeld | 7 Jul 13:04
Picon

Re: MERGE: bse2cxx-part2

   Hi!

On Tue, Jul 05, 2011 at 12:27:24PM +0200, Tim Janik wrote:
> On 05.07.2011 09:56, Stefan Westerfeld wrote:
> >On Mon, Jul 04, 2011 at 09:55:05PM +0200, Tim Janik wrote:
> >>On Fri, 1 Jul 2011, Stefan Westerfeld wrote:
> >>>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
> >>
> >>Thanks, merged. You are free to port gchar->char and gint->int
> >>on the fly btw. It's a pitty that porting the code to C++ makes
> >>it so much more ugly instead of improving it ;(
> >
> >>Did you find a way yet to automated part of the most stupid
> >>changes needed? E.g. something like this small perl script here?
> >>
> >>==================
> >>#!/usr/bin/perl -w -pi.bak
> >>s,\bclass\b,klass,g;
> >>==================
> >
> >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.
> 
> Hm, I'd rather see this done on a single file before it's ported.
> These changes tend to screw up indentation, catch comments and strings
> as well and sometimes do other harm. So it needs to be reviewed with
> each individual file. Thus doing it along porting a single file to C++
> is much more natural, workflow wise.

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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 1 comment |
headers
Stefan Westerfeld | 5 Jul 09:56
Picon

Re: MERGE: bse2cxx-part2

   Hi!

On Mon, Jul 04, 2011 at 09:55:05PM +0200, Tim Janik wrote:
> On Fri, 1 Jul 2011, Stefan Westerfeld wrote:
> 
> >  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
> 
> Thanks, merged. You are free to port gchar->char and gint->int
> on the fly btw. It's a pitty that porting the code to C++ makes
> it so much more ugly instead of improving it ;(

> Did you find a way yet to automated part of the most stupid
> changes needed? E.g. something like this small perl script here?
> 
> ==================
> #!/usr/bin/perl -w -pi.bak
> s,\bclass\b,klass,g;
> ==================

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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 0 comments |
headers
Stefan Westerfeld | 1 Jul 19:38
Picon

MERGE: bse2cxx-part2

   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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 0 comments |
headers
Stefan Westerfeld | 26 Jun 21:56
Picon

MERGE: bse2cxx-part1

   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
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Permalink | Reply | 0 comments |
headers
Tim Janik | 22 May 15:09
Favicon

Coding Guidelines Moved

Hey all,

our coding guidelines have been moved into the Wiki now:
 	http://beast.testbit.eu/Coding_Guidelines

The Beast Development Wiki page links here, let me know
if you think other places need a link as well.

Review and comments welcome.

Yours sincerely,
Tim Janik

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

Gmane