Hello!
I've used the awesome LV drum machine DrMr for a years, but at the some point of time it became incompatible with the modern format of Hydrogen drum kits. So I've decided to fix DrMr, and this fixing led me to more ideas about the DrMr development and continuation. So the initial result is Drumrox - https://github.com/psemiletov/drumrox
It can load Hydrogen kits in the current kit format
Presets now sorted alphabetically
Some code is rewritten in C++, and I hope to rewrite more soon.
You can install it from the source, or via AUR (yay -S drumrox)
PS I have many ideas for this plugin, but currently my experience with LV2 API is very small.
Hello!
I've used the awesome LV drum machine DrMr for a years, but at the some point of time it became incompatible with the modern format of Hydrogen drum kits. So I've decided to fix DrMr, and this fixing led me to more ideas about the DrMr development and continuation. So the initial result is Drumrox - https://github.com/psemiletov/drumrox
It can load Hydrogen kits in the current kit format
Presets now sorted alphabetically
Some code is rewritten in C++, and I hope to rewrite more soon.
You can install it from the source, or via AUR (yay -S drumrox)
PS I have many ideas for this plugin, but currently my experience with LV2 API is very small.
Does it scale up the GUI for high resolution support (4k, HiDPI, etc) ?
Does it scale up the GUI for high resolution support (4k, HiDPI, etc) ?
Currently I did not touch GUI yet. It is based on GTK+2, I am mostly Qt/C++ guy, and need some time to learn the DrMr source, and then maybe rework the GUI (for example, if there are many instruments at the kit, the plugin window becomes larger that the screen). My first steps was just fixing the compatibility with Hydrogen kits, and make the presets list in the sorted order). Maybe I'll try to port it to GTK+4.
I packaged it for the multimedia:proaudio openSUSE repo.
I think that more than GTK4, it would be better to port it to a static UI toolkit like JUCE or DPF (or even FLTK, if you bother to configure it a bit!).
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]
Please donate time (even bug reports) or money to libre software
I packaged it for the multimedia:proaudio openSUSE repo.
I think that more than GTK4, it would be better to port it to a static UI toolkit like JUCE or DPF (or even FLTK, if you bother to configure it a bit!).
Thank you a lot!
By the way, new release is coming soon, with some useful new features
And speaking about the porting to another toolkit - probably yes, but in the distant future. I like Qt GTK4, as I read, does not supported by LV2 specification, there are GTK2 and GTK4. But, GTK-based GUI is not supported by Reaper.
linear panner, law: -6 dB //default. Is that good?
linear panner, law: 0 dB
square root panner, law: -3 dB
sin/cos panner, law: -3 dB
This option affects to all instrument panners.
Also, in 1.1.0, the Gain knob is more precise - the original DrMr step was 1 dB, the current one os 0.1 dB
P.S. I'm confused what to do with MIDI note velocity and the final sample gain, so there is a possibility that in the future the behavior will be changed, and I need advices about that (and learn more from the original DrMr source). Actually, I've started to rewrite all internal mixing.
Does Robin's toolkit support HiDPI? These days, most everything is high resolution, and those of use who run at high resolutions can't use plugins unless they scale up to 200%-300%. It would be kind of pointless to move to a toolkit that doesn't support it, so that's why I'm asking.
Does Robin's toolkit support HiDPI? These days, most everything is high resolution, and those of use who run at high resolutions can't use plugins unless they scale up to 200%-300%. It would be kind of pointless to move to a toolkit that doesn't support it, so that's why I'm asking.
Does your post asks anything other than HiDPI?
this toolkit has scalability options, or have you never used x42 plugins?
If I'll rewrite the GUI of DrMr/Drumrox, it will be based on more common-used toolkit, such as newer version of GTK or, more possible - Qt6, or maybe something small that I can include in source tree. But for now I need to be more familiar with the source, and want to rewrite some things in C++. And not to broke any existing functionality
If I'll rewrite the GUI of DrMr/Drumrox, it will be based on more common-used toolkit, such as newer version of GTK or, more possible - Qt6, or maybe something small that I can include in source tree. But for now I need to be more familiar with the source, and want to rewrite some things in C++. And not to broke any existing functionality
Those big toolkits are bad option for making plugins. Plugins should have everything static, no dynamic library dependencies. Sepcially Ardour and Mixbus, without plugin sandboxing and delivered with own libraries are the ones where dynamic loading can cause problems.
