0.9.11 plan
Moderators: MattKingUSA, khz, muldjord, deva
0.9.11 plan
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
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
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 xDchaot4 wrote:almost finished (only glocke has one issue left).
Just a guy
- 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
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
Alright, deva. Then ping me (via mail or here) if you need a helping hand for some of the release stuff.
- 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
Actually I thinks it's just down to testing
Specifically the VSTs but that's muldjord's table...
Specifically the VSTs but that's muldjord's table...
Re: 0.9.11 plan
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
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
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. Deva is informed.
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. Deva is informed.
- 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
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?
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?
- 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
I went with the fourth option std::shared_ptr
It should be fixed in the most recent jenkins build.
It should be fixed in the most recent jenkins build.
Re: 0.9.11 plan
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
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:
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
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();
}
Code: Select all
auto peekEvent = peekNextEvent(); // returns the unique_ptr
// do the stuff but don't call delete
if (peekEvent->type() != EventType::resize) {
break;
}
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
- 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
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?
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?