0.9.11 plan

Moderators: khz, MattKingUSA, deva, muldjord

chaot4
Established Member
Posts: 42
Joined: Sat Apr 16, 2016 9:59 am

0.9.11 plan

Postby chaot4 » Tue Oct 25, 2016 1:46 am

As we now got this forum -- let's try it out.

The roadmap for 0.9.11 seems to be almost finished (only glocke has one issue left). So, what are the plans of releasing 0.9.11? Is it ready when all the roadmap issues are done? If so, any plans on when this might be?

Cheers,
chaot4

suhr
Posts: 1
Joined: Mon Oct 24, 2016 2:32 pm

Re: 0.9.11 plan

Postby suhr » Tue Oct 25, 2016 5:47 am


User avatar
Glocke
Established Member
Posts: 15
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Postby Glocke » Tue Oct 25, 2016 1:05 pm

chaot4 wrote:almost finished (only glocke has one issue left).

Sorry for that. But atm I'm out of enough time to complete it. But feel free to capture the issue. As far as my notes tell the truth, the last thing was to make the dgreftest work again.. but that's all I know about the issue xD
  • Bass player & vocalist of Breaper (Death Metal, Thuringia/Germany)
  • Minor dev of DrumGizmo (LGPLv3 Drumsampling Tool)
  • Dev & game artist of Racod's Lair (Pixelart Dungeoncrawler)

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Tue Oct 25, 2016 5:22 pm

I'm thinking we should just release what we have now and push the remaining tasks (there are 2) to the next release.

chaot4
Established Member
Posts: 42
Joined: Sat Apr 16, 2016 9:59 am

Re: 0.9.11 plan

Postby chaot4 » Tue Oct 25, 2016 7:40 pm

Alright, deva. Then ping me (via mail or here) if you need a helping hand for some of the release stuff.

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Tue Oct 25, 2016 7:48 pm

Actually I thinks it's just down to testing :-)
Specifically the VSTs but that's muldjord's table...

chaot4
Established Member
Posts: 42
Joined: Sat Apr 16, 2016 9:59 am

Re: 0.9.11 plan

Postby chaot4 » Tue Oct 25, 2016 9:58 pm

Just fyi: All the unit tests passed on my laptop but I didn't test it in Ardour or anything.

muldjord
Established Member
Posts: 12
Joined: Mon Dec 08, 2014 9:45 am

Re: 0.9.11 plan

Postby muldjord » Wed Oct 26, 2016 3:56 pm

I am on the VST testing task, I just need to find the time... And maybe more importantly, energy. But I should be able to do it before the weekend.

User avatar
Glocke
Established Member
Posts: 15
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Postby Glocke » Thu Oct 27, 2016 11:33 am

*moved to development subforum*
  • Bass player & vocalist of Breaper (Death Metal, Thuringia/Germany)
  • Minor dev of DrumGizmo (LGPLv3 Drumsampling Tool)
  • Dev & game artist of Racod's Lair (Pixelart Dungeoncrawler)

muldjord
Established Member
Posts: 12
Joined: Mon Dec 08, 2014 9:45 am

Re: 0.9.11 plan

Postby muldjord » Thu Oct 27, 2016 5:15 pm

Tested both 64 and 32 bit VST dll's on Windows today. Both crash when the mouse poiner enters the DG window. Sound is fine on 32bit, but I never got to test that on 64bit since I don't have a project where a drumkit is already loaded.

When I run plugingui.exe (both 32 and 64bit) I get the following error in a terminal when it crashes:
"pure virtual method called
terminate called without an active exception"

Being the hlaf-assed programmer I am, I have no idea what that means, but I thought it might be important. :D Deva is informed.

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Thu Oct 27, 2016 6:48 pm

... and so the hunt begins!

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Thu Oct 27, 2016 7:39 pm

I have found the error but not yet a good way to solve it.

http://cgit.drumgizmo.org/drumgizmo/com ... 399456cc4e

This commit adds deleting of peek event (ie. events returned by peekNextEvent) as this is needed for the x11 implementation.
On Win32 the returned pointer is however not to be deleted as it is stored in a list internally by the native window to be returned again on the next call to getNextEvent.
So deleting the event returned by peekNextEvent will make the pointer dangling when later returned by getNextEvent.
I see three potential solutions:
1) Rewrite the Win32 peekNextEvent to make a copy of the Event before returning it, imitating the behaviour of the X11 implementation.
2) Rewrite the X11 peekNextEvent to store the event and return the same pointer in getNextEvent imitating the behaviour of the Win32 implementation. (this is probably very hard to do)
or
3) Rewrite the whole thing to return objects instead of pointers (they are very small anyway so performance should not be an issue) and remove the 'delete' statements entirely.

What say you?

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Fri Oct 28, 2016 4:13 pm

I went with the fourth option std::shared_ptr ;-)
It should be fixed in the most recent jenkins build.

User avatar
Glocke
Established Member
Posts: 15
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Postby Glocke » Sat Oct 29, 2016 3:04 pm

Personally, I'd avoid shared_ptr (despite "performance should not be an issue" or not) because there is not shared ownership (as far as I can tell) - so the code would self-document/imply a design decision that was a bug-fix-decision ... I don't like this idea :)

Since the code is peeking and deleting multiple times (and the main issue seems to be the break instruction), I'd try to use a unique_ptr, like this (not tested):
First change the Event *EventHandler::peekNextEvent() API to

Code: Select all

std::unique_ptr<Event> EventHandler::peekNextEvent()
{
   return nativeWindow.peekNextEvent();
}

So the raw ptr is passed to the unique_ptr ctor, the unique_ptr is moved out (done by compiler) and can be used now:

Code: Select all

auto peekEvent = peekNextEvent(); // returns the unique_ptr

// do the stuff but don't call delete
if (peekEvent->type() != EventType::resize) {
    break;
}


I'd apply this to the getNextEvent, too (assuming its not shared, too).

The unique_ptr default destructor calls delete, hence it should work. But even if a custom deletion would be necessary... unique_ptr allows this, too :)

Hope that helps :)

Glocke
  • Bass player & vocalist of Breaper (Death Metal, Thuringia/Germany)
  • Minor dev of DrumGizmo (LGPLv3 Drumsampling Tool)
  • Dev & game artist of Racod's Lair (Pixelart Dungeoncrawler)

User avatar
deva
Established Member
Posts: 124
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: 0.9.11 plan

Postby deva » Sat Oct 29, 2016 3:23 pm

The trouble with the unique_ptr as with the raw pointer is that the nativewindow_win32 version of peek returns the front pointer in a vector without popping it.
The unique_ptr would delete it after the peek event goes out of scope rendering the raw pointer in the vector dangling.
... or did I misunderstand your approach?


Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest