[ANN] Drumrox 2.1.0 + 3 drumkits (Lel PSR, Lel DR8, LinnDrum)

[peter.semiletov]

Drumrox 2.1.0 + 3 drumkits (Lel PSR, Lel DR8, LinnDrum)
https://github.com/psemiletov/drumrox/r ... /tag/2.1.0

Hello!
Besides many fixes and code refactoring, there are some interesting new features.

• First of all, I've made a Drumrox site (https://psemiletov.github.io/drumrox/) which is more clear than the github's project page.

• Also, here is a repository for Drumrox kits (https://github.com/psemiletov/drumrox-kits). Yes, Drumrox 2.1 introduces, in addition to Hydrogen format support, the new drumkit format. Hydrogen is a larger program than Drumrox, so it needs more complex format with wide set of features. Instead of that, Drumrox provides simple format in the form of directory, which contains the samples and drumkit.txt file. The last one looks like that:

Code: Select all

Kick=kick.wav
Snare=snare.wav
Crash=crash.wav

So we can quickly create and use new kits.

• Currently at the Drumrox kits repo are 3 kits, let me introduce them! Lel PSR - the legendary Soviet drum machine, used at early albums of famous USSR rock bands such as Kino, Strannye Igry, Aquarium. Lel DR8 - the continuation of Lel PSR. LinnDrum - drum machine manufactured by Linn Electronics between 1982 and 1985.
  LinnDrum was used by Peter Gabriel, Stevie Wonder, Gary Numan, Michael Jackson, Devo, John Carpenter, Prince, Madonna, Elton John, Queen (at Radio Ga Ga).

• Search paths for drumkits are:

Code: Select all

/usr/share/hydrogen/data/drumkits
/usr/local/share/hydrogen/data/drumkits
/usr/share/drmr/drumkits
/usr/share/drumrox-kits
$HOME/.hydrogen/data/drumkits
$HOME/.drmr/drumkits
$HOME/.drumrox/drumkits
$HOME/drumrox-kits

• Drumrox kit can have the picture (named "image.png") of drum machine/kit, that appears at plugin window.

• Future plans - porting GUI part from GTK2 to another kit (Nuklear? FLTK?), fixes, rewritting some code that I hardly understand, etc. More new kits!

[bluebell]

• Future plans - porting GUI part from GTK2 to another kit (Nuklear? FLTK?), fixes, rewritting some code that I hardly understand, etc. More new kits!

I am afraid the only tool kit that a developer can use reliably is his own tool kit.

I am tired of the same annoying story every couple of years: $TOOLKITv${N} is lame and deprecated, use the fancy superduper $TOOLKITv${N+1}. Else your program won't run on the next version of your Linux distro.

[peter.semiletov]

I am tired of the same annoying story every couple of years: $TOOLKITv${N} is lame and deprecated, use the fancy superduper $TOOLKITv${N+1}. Else your program won't run on the next version of your Linux distro.

LV2 GTK2 GUI does not work with Reaper. GTK3 does not work with Ardour (but GTK2 does). Any suggestions about not to port?

[GMaq]

I am tired of the same annoying story every couple of years: $TOOLKITv${N} is lame and deprecated, use the fancy superduper $TOOLKITv${N+1}. Else your program won't run on the next version of your Linux distro.

LV2 GTK2 GUI does not work with Reaper. GTK3 does not work with Ardour (but GTK2 does). Any suggestions about not to port?

Many popular Linux projects (ie Guitarix and LSP Plugins off the top of my head) have transitioned from GTK toolkits down to the X11 layer, this is the only way to expect current and future compatibility and avoid most of the QT/GTK Plugin UI headaches. I'm sure @tramp and @sadko4u would be willing to get you pointed in the right direction to how to achieve that, if I'm not mistaken Guitarix also has some developer tools to get started with X11 UI's

[peter.semiletov]

I think I'll use FLKT (as wide-spread among distros) or Nuklear (it's small, I can include it with the source). The major milestone is to rewrite some DrMr's non-GUI code that I don't understand now clearly. I need a time to sit down and think Then I'll rewrite GUI from scratch. Currently I can do anything with GTK2 GUI, I've started my Linux programming experience with C/GTK2 at the 200x's, then moved to C++/Qt. But I don't want to make something new with GUI while not it is ported to another kit. GTK2 LV2 GUI has no future outside the Ardour.

[Largos]

I think I'll use FLKT (as wide-spread among distros) or Nuklear (it's small, I can include it with the source). The major milestone is to rewrite some DrMr's non-GUI code that I don't understand now clearly. I need a time to sit down and think Then I'll rewrite GUI from scratch. Currently I can do anything with GTK2 GUI, I've started my Linux programming experience with C/GTK2 at the 200x's, then moved to C++/Qt. But I don't want to make something new with GUI while not it is ported to another kit. GTK2 LV2 GUI has no future outside the Ardour.

Perhaps this thread viewtopic.php?t=25516 is useful @sjaehn has done a tutorial series on lv2 specific gui stuff.

[peter.semiletov]

Perhaps this thread viewtopic.php?t=25516 is useful @sjaehn has done a tutorial series on lv2 specific gui stuff.

Thank you, I saw some @sjaehn's great videos, and I aware about B.Widgets and Pugl. B.Widgets looks fantastic!

[sjaehn]

I think I'll use FLKT (as wide-spread among distros) or Nuklear (it's small, I can include it with the source).

The main problem about UIs in plugins is linking. Dynamic linking is highly problematic. Especially if the linked (UI) library doesn't guarantee full compatibility to former versions. And both, GTK and Qt have got a lot of compatibility breaks in their version history.

FLTK might be less problematic in respect of compatibility breaks, but the dynamic linking problem still persist.

The best solution is static linking of a library and hide their symbols. There are small UI libraries for music production plugins made for static linking, like RobTK (by @x42), libXputty (by @tramp), LSP-TK (by @sadko4u), or B.Widgets (by myself). Or take any UI toolkit which you can include with source (Nuklear?), as long as it doesn't depend on a dynamically linked library again.

In theory, you can make static builds of GTK (at least with versions 3 and 4) and Qt (and FLTK). But this is complicated and not recommended. @rncbc did it with Qt for his private builds.

[peter.semiletov]

There are all great UI libraries! But I have a major problem before the porting As you know, Drumrox is a fork of DrMr - now heavily modified fork, but a fork, and I don't understand some of DrMr's code, to be precise - the code of interconnection between UI's drumkit change (from combobox) and its counterpart at the non-gui side (in DrMr is is not just sending the drumkit path, but something more complex). When I'll understand it completely, I'll start to think about new GUI seriosly.
To my shame, I was afraid to write LV2 plugin from scratch, altough it always was to me simpier to write things on my own than to modify other's program architecture (not a code itself).

[sadko4u]

My little point about GTK: for me it didn't work with the JUCE-based host. It never received any keboards nor mouse events.

[sadko4u]

Oh, forgot to mention. For LSP, there is a plugin template repository which is a good point to start development of some new plugin using all features and formats provided by LSP framework:

https://github.com/lsp-plugins/lsp-plug ... -template/

I use this repository for every new plugin since 1.2.0 because it gives all necessary to start writing the code.

[peter.semiletov]

Oh, forgot to mention. For LSP, there is a plugin template repository which is a good point to start development of some new plugin using all features and formats provided by LSP framework:
https://github.com/lsp-plugins/lsp-plug ... -template/
I use this repository for every new plugin since 1.2.0 because it gives all necessary to start writing the code.

Vladimir, thank you, I looked at that and maybe try later, but not for Drumrox. It seems too difficult for me to transform Drumrox into something based on LSP Plugin Framework. Frankly to say I mostly avoided to program audio related stuff for years, after my unsucceful attempt to write DAW Wavylon (https://github.com/psemiletov/wavylon). From time to time I make maintenance updates to my simple sound editor EKO (https://github.com/psemiletov/eko), the side project of Wavylon. LV2 plugins API always scared be, but some time ago I wanted to make a video for Youtube about good sound plugins in Linux, and wanted to tell about DrMr, but DrMr was broken in a sense of support modern Hydrogen kits, so I desided to make a fork, never dealing with LV2 API before...

[sjaehn]

Vladimir, thank you, I looked at that and maybe try later, but not for Drumrox.

I fully agree. If you want to continue an existing project, then it is the best to put a simple UI TK like Xputty on top. If you want to start with something new, then it's worth to take a look at the existing frameworks. Like LSP (the framework, not only the UI toolkit).

[peter.semiletov]

I fully agree. If you want to continue an existing project, then it is the best to put a simple UI TK like Xputty on top. If you want to start with something new, then it's worth to take a look at the existing frameworks. Like LSP (the framework, not only the UI toolkit).

There is just one problem ( Drumrox has the dynamic UI, it constructs containers for each drum instrument (according to the drumkit selected and loaded), with gain/pan/label/etc. I need the GUI toolkit with containers and relative positioning, otherwise I need to write all that stuff for my own

[AlkuK]

Nice. Thanks for sharing. You rock. Peace.