Page 1 of 2

0.9.11 plan

Posted: Tue Oct 25, 2016 1:46 am
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

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 5:47 am
by suhr

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 1:05 pm
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

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 5:22 pm
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.

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 7:40 pm
by chaot4
Alright, deva. Then ping me (via mail or here) if you need a helping hand for some of the release stuff.

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 7:48 pm
by deva
Actually I thinks it's just down to testing :-)
Specifically the VSTs but that's muldjord's table...

Re: 0.9.11 plan

Posted: Tue Oct 25, 2016 9:58 pm
by chaot4
Just fyi: All the unit tests passed on my laptop but I didn't test it in Ardour or anything.

Re: 0.9.11 plan

Posted: Wed Oct 26, 2016 3:56 pm
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.

Re: 0.9.11 plan

Posted: Thu Oct 27, 2016 11:33 am
by Glocke
*moved to development subforum*

Re: 0.9.11 plan

Posted: Thu Oct 27, 2016 5:15 pm
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.

Re: 0.9.11 plan

Posted: Thu Oct 27, 2016 6:48 pm
by deva
... and so the hunt begins!

Re: 0.9.11 plan

Posted: Thu Oct 27, 2016 7:39 pm
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?

Re: 0.9.11 plan

Posted: Fri Oct 28, 2016 4:13 pm
by deva
I went with the fourth option std::shared_ptr ;-)
It should be fixed in the most recent jenkins build.

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 3:04 pm
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

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 3:23 pm
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?