Re: wip/soundfont (and wip/ branches)

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Wed, Sep 21, 2016 at 05:42:31PM +0200, Tim Janik wrote:
> On 21.09.2016 12:49, Stefan Westerfeld wrote:
> > > > However if you start BEAST, go to SoundFont repository and click load
> > > > and load a sound font, this is what happens:
> > > >
> > > >   beast-0.10.1: bseobject.cc:167: void bse_object_init(BseObject*): Assertion `in_bse_object_new' 
> > > > failed.
> > > >   Abgebrochen (Speicherabzug geschrieben)
> > > >
> > > > This sounds like something that should be very easy to fix for you, since you
> > > > know what changes to the object system you did that caused this problem.
> > >
> > > And there we go, seems debugging is the next step neccessary...
> >
> > Ok. I know that it didn't fail back then when I wrote the code, so I had hoped
> > that this was caused by infrastructure changes, and you'd recognize the error
> > message and know what to do. Well, I'll try to figure out myself what needs to
> > be changed.
>
> If you want me to guess, it could be related to bse_object_new now hardcoding the C++ object types that are 
> paired with a GType object.
> But you're right it needs further investigation.

Fixed, by replacing g_object_new with bse_object_new, see below.

> > Are you sure? If I merge master into the wip/soundfont branch, as in
> >
> >   (on wip/soundfont)$ git merge master
> >
> > then this will generate a commit with houndreds of changes that are completely
> > unrelated to the soundfont branch (because it will merge every single thing
> > that has changed in master since then), and among these changes a few that are
> > related.
> >
> > I can do this, but it doesn't make the actual merge changes as obvious as for
> > instance my squash commit or rebasing.
> >
> > It would work the other way round, by starting from a new branch from master:
> >
> >   (on master)$ yybranch wip/soundfont-merge
> >   (on master)$ yywarp wip/soundfont-merge
> >   (on wip/soundfont-merge)$ git merge wip/soundfont
> >
> > which is basically the same as just merging the branch into master, except that
> > it is done in an extra branch, and it would
> >
> >  - show the changes clearly (unlike merging master into wip/soundfont)
> >  - not edit or squash old commits (lossless)
> >  - the resulting branch can be pushed to origin and should merge cleanly
> >  - however it would not have linear history any longer
> >
> > It sounds like a plausible way to go.
>
> If I'm not mistaken, both ways will create the exact same kind of merge commit, the only thing different is 
> just that the resulting branch you end up with is either named wip/soundfont-merge or wip/soundfont.
>
> But maybe I'm missing something...

I tried it, while merging master into wip/soundfont-merge there are the following
problems:

 * git diff [ foo.cc ] will show all changes in master, that is a lot
 * it can be workarounded using explicit git diff master [ foo.cc ]
 * also, git status produces a looong list of stuff, due to the number
   of changes in master

also after the merge gitk will show every change in master if you select
the merge commit and look at the history.

So the next thing I tried was reversing it, and create wip/soundfont-merge
as proposed:

 * git diff shows the expected thing (diffs created by soundfont code)
 * git status shows the expected thing (status changes by soundfont code)

after merge gitk will show the soundfont branch history.

So it seems that to git, the merging process is not completely symmetric and
its better to think of it as merging a topic-like branch onto a master-like
branch.

Anyway, you can now pull the branch (produced in this way)

    wip/soundfont-merge

from

    http://space.twc.de/public/git/stwbeast.git

it also contains two additional commits after the merge:

 * the g_object_new triggering assertion problem
 * I also moved the replay network from zintern/ to res/.

so I was able to test that loading soundfonts and playback works.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan