Hi!

On Thu, Sep 29, 2016 at 02:54:27PM +0200, Tim Janik wrote:
> On 21.09.2016 21:08, Stefan Westerfeld wrote:
> >> 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.
> 
> > 
> > Fixed, by replacing g_object_new with bse_object_new, see below.
> 
> Ok.
> 
> > 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.
> 
> Hm, gitk shows a combined diff for the merge... Just learning how to read 
> that from git-diff(1) ;-)
> 
> With git diff, I suspect you view this:
>   git diff 1698dc960d2607323551a72c59d581efdbe6e1fc^!
> I.e.:
>   *   1698d # Merge branch 'wip/soundfont' into wip/soundfont-merge (8 days 
> ago) <Stefan Westerfeld>
> Right?

Right.

> > 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.
> 
> Yeah, I think that's simply dependent on the order of the merge parents in 
> the merge commit.
> What I meant was the file tree should end up the same, right?

Yes it should.

> > Anyway, you can now pull the branch (produced in this way)
> > 
> >     wip/soundfont-merge
> 
> Merge commit:
> >   Merge branch 'wip/soundfont' into wip/soundfont-merge
> >
> >    This merge creates a version of the wip/soundfont branch that cleanly 
> > applies
> >    to the current master branch.
> 
> This should say something like "merge with 'master'" (like the description
> mentions), instead of referring to a temporary branch that'll never be pushed
> into the public beast repo.

Ok. I'll try to do it better for new submissions.

> > --------------------------- bse/bseproject.genprc.cc 
> > ---------------------------
> 
> This should have never been checked in.

Right. I deleted it in new proposed branch.

> > +++ bse/bseproject.proc
> > + METHOD (BseProject, get-sound-font-repo) {
> 
> Please try to move this into bseapi.idl, we're trying to get rid of all 
> *.proc files.

Ok, I fixed this, moved get-sound-font-repo to bseapi.idl.

> > diff --cc bse/bsesoundfontrepo.proc
> 
> Same here, please try adding this to bseapi.idl.

Done.

> > 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/.
> 
> This looks wierd, master doesn't have zintern/Makefile.am anymore, your merge
> commit doesn't seem to reintroduce it, but the

It's gone now anyway.

> > so I was able to test that loading soundfonts and playback works.
> 
> Ok, that's an important step already, thanks so far.
> 
> The merge doesn't apply cleanly to my local tree which has a bunch more 
> proc->bseapi.idl moves in it.
> 
> I'll do my best to push this to github in the net few days and can need your 
> help resolving the conflicts after that.

Thanks for doing that, it gave me a reference implementation (bsewave & co) for
the new procedures introduced in the soundfont patch.

My improved branch as now available as

  wip/soundfont-merge

from

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

It fixes all the issues you mentioned here, basically it just moves the
procedures to bseapi.idl. So it should merge cleanly with your master. I also
fixed some signedness warnings. I also tested soundfont load and playback: this
works.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan
_______________________________________________
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Reply via email to