0.9.11 plan

Moderators: MattKingUSA, khz, muldjord, deva

chaot4
Established Member
Posts: 61
Joined: Sat Apr 16, 2016 9:59 am
Been thanked: 1 time

0.9.11 plan

Post by chaot4 »

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

Post by suhr »

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

Re: 0.9.11 plan

Post by Glocke »

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
Just a guy
User avatar
deva
Established Member
Posts: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

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: 61
Joined: Sat Apr 16, 2016 9:59 am
Been thanked: 1 time

Re: 0.9.11 plan

Post by chaot4 »

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: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

Actually I thinks it's just down to testing :-)
Specifically the VSTs but that's muldjord's table...
chaot4
Established Member
Posts: 61
Joined: Sat Apr 16, 2016 9:59 am
Been thanked: 1 time

Re: 0.9.11 plan

Post by chaot4 »

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

Post by muldjord »

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: 18
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Post by Glocke »

*moved to development subforum*
Just a guy
muldjord
Established Member
Posts: 12
Joined: Mon Dec 08, 2014 9:45 am

Re: 0.9.11 plan

Post by muldjord »

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: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

... and so the hunt begins!
User avatar
deva
Established Member
Posts: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

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: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

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: 18
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Post by Glocke »

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
Just a guy
User avatar
deva
Established Member
Posts: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

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?
Post Reply