Get it at http://www.drumgizmo.org/
DrumGizmo is an open source, multichannel, multilayered, cross-platform drum plugin and stand-alone application. It enables you to compose drums in midi and mix them with a multichannel approach. It is comparable to that of mixing a real drumkit that has been recorded with a multimic setup.
This is mostly a bugfix release, but also introduces the use of the Ardour inline feature in the LV2 version of the plugin. Go load it up, you'll see a loading bar in the mixer panel.
A unicode bug has been fixed and we also fixed a problem that occurred when using more than one instance of DG in your DAW. Plus a tonne of other stuff. Check the roadmap for the full details.
Important note to package maintainers:
We now copy vst source files into the build tree while building the vst plugin. This mean that should you wish to make a tar-ball available with the build directory after the build has finished this must either be stripped of said files or not be made public.
DrumGizmo version 0.9.11 now available!
Moderators: MattKingUSA, khz, muldjord, Glocke, deva
- funkmuscle
- Established Member
- Posts: 2806
- Joined: Mon Jun 02, 2008 2:30 pm
- Has thanked: 131 times
- Been thanked: 33 times
Re: DrumGizmo version 0.9.11 now available!
hey guys, DG 0.9.11 has issues with MuSE3. They asked me to report.
this is the message from Tim, one of the devs. I just copied his reply to me at their git issues site.
this is the message from Tim, one of the devs. I just copied his reply to me at their git issues site.
Code: Select all
Oh crud.
DrumGizmo made significant changes to their semaphore code
from 0.9.10 to 0.9.11
The supplied file runs fine with 0.9.10 but crashes with 0.9.11
The error is from within DrumGizmo.
But it is /triggered/ by MusE. Ardour works fine.
Whether we run MusE with or without audio (-a switch), it crashes.
According to the call stack, DrumGizmo crashes at semaphore.cc:152,
in method Semaphore::wait(), in a sem_timedwait() block, with an error
/other/ than timeout, while waiting. In version 0.9.10 that method's
code was much simpler, with simply a sem_wait(&prv->semaphore) call.
Now, also according to the call stack, another thread is sitting in a
futex_wait(). This futex_wait is caused by MusE calling
seteuid() from globals.cpp:doSetuid() which is called from
our jack.cpp:jack_thread_init() if Jack is running, or from
calling seteuid() in globals.cpp:undoSetuid() from
dummyaudio.cpp:dummyLoop() if Jack is not running
(the -a switch dummy audio driver).
Each time I try with Jack or our dummy audio, the crash happens,
and that futex_wait() call is sitting there in the other thread !
So... Over the years I have wondered if we really need that setuid()
crap anymore? That was waaaay back in prehistoric Jack and kernel days.
Our (outdated?) README file states that MusE needs to be run at
the same uid as Jack. Is this really necessary still?
I have not delved into it more because it didn't seem to break anything.
But now... I will look closer and try removing those setuid() calls.
Hey funkmuscle: You are on their forum. Can you let them know
what's happening here, keep them in the loop, so to speak?
Maybe they can offer some advice since version 0.9.11 + MusE breaks.
Meanwhile I will try to fix it here by removing those setuid() calls...
Thanks.
Tim.
- funkmuscle
- Established Member
- Posts: 2806
- Joined: Mon Jun 02, 2008 2:30 pm
- Has thanked: 131 times
- Been thanked: 33 times
Re: DrumGizmo version 0.9.11 now available!
he just updated me and the issue has been resolved. I was able to test it and all is good.funkmuscle wrote:hey guys, DG 0.9.11 has issues with MuSE3. They asked me to report.
this is the message from Tim, one of the devs. I just copied his reply to me at their git issues site.
Code: Select all
Oh crud. DrumGizmo made significant changes to their semaphore code from 0.9.10 to 0.9.11 The supplied file runs fine with 0.9.10 but crashes with 0.9.11 The error is from within DrumGizmo. But it is /triggered/ by MusE. Ardour works fine. Whether we run MusE with or without audio (-a switch), it crashes. According to the call stack, DrumGizmo crashes at semaphore.cc:152, in method Semaphore::wait(), in a sem_timedwait() block, with an error /other/ than timeout, while waiting. In version 0.9.10 that method's code was much simpler, with simply a sem_wait(&prv->semaphore) call. Now, also according to the call stack, another thread is sitting in a futex_wait(). This futex_wait is caused by MusE calling seteuid() from globals.cpp:doSetuid() which is called from our jack.cpp:jack_thread_init() if Jack is running, or from calling seteuid() in globals.cpp:undoSetuid() from dummyaudio.cpp:dummyLoop() if Jack is not running (the -a switch dummy audio driver). Each time I try with Jack or our dummy audio, the crash happens, and that futex_wait() call is sitting there in the other thread ! So... Over the years I have wondered if we really need that setuid() crap anymore? That was waaaay back in prehistoric Jack and kernel days. Our (outdated?) README file states that MusE needs to be run at the same uid as Jack. Is this really necessary still? I have not delved into it more because it didn't seem to break anything. But now... I will look closer and try removing those setuid() calls. Hey funkmuscle: You are on their forum. Can you let them know what's happening here, keep them in the loop, so to speak? Maybe they can offer some advice since version 0.9.11 + MusE breaks. Meanwhile I will try to fix it here by removing those setuid() calls... Thanks. Tim.
- deva
- Established Member
- Posts: 285
- Joined: Sun Oct 23, 2016 10:15 am
- Has thanked: 3 times
- Been thanked: 31 times
- Contact:
Re: DrumGizmo version 0.9.11 now available!
Great
What was the issue?
It is true that we introduced a more complex use of the semaphore, and it might very well be true that we do not handle error cases very nicely.
So if MuSE somehow manages to trigger such error it would be nice to know what triggered it, so we can handle it nicely and also add a unit-test to ensure something similar won't happen in any future implementations.
What was the issue?
It is true that we introduced a more complex use of the semaphore, and it might very well be true that we do not handle error cases very nicely.
So if MuSE somehow manages to trigger such error it would be nice to know what triggered it, so we can handle it nicely and also add a unit-test to ensure something similar won't happen in any future implementations.
- funkmuscle
- Established Member
- Posts: 2806
- Joined: Mon Jun 02, 2008 2:30 pm
- Has thanked: 131 times
- Been thanked: 33 times
Re: DrumGizmo version 0.9.11 now available!
from Tim's reply:deva wrote:Great
What was the issue?
It is true that we introduced a more complex use of the semaphore, and it might very well be true that we do not handle error cases very nicely.
So if MuSE somehow manages to trigger such error it would be nice to know what triggered it, so we can handle it nicely and also add a unit-test to ensure something similar won't happen in any future implementations.
Code: Select all
Here's the ChangeLog:
Removed seteuid()/setreuid() code supporting ancient
givertcap tool (kernel priveleges).
[Yeah I forgot to mention before that this stuff is support
for the old "givertcap" tool.]
Was interfering with DrumGizmo's use of semaphores.
TODO: Remove further old rtcaps code such as main.cpp:getCapabilities().