Percussion Synthesizer

All your LV2 and LADSPA goodness and more.

Moderators: khz, MattKingUSA

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

Basslint wrote:What did you find problematic about Qt? You were using straight Widget-based Qt IIRC. Do you think QML would have solved some of those issues?

I'm thinking about writing an LV2 plugin with an interface made in QML which comunicates via OSC to the sound engine, so that the GUI and audio part are well separated. Your opinion as a much more experienced developer would be much appreciated :D
In the most of the cases this will work, and maybe you don't need to care too much. But if you want to be more strict about plugins than...

If the user wants to load different plugins that were based on different versions of Qt, than the host needs to load in its address space two different shared Qt libraries which in the most of the cases will cause the host/DAW to crash due to various reasons. In theory this should not happen but Qt is designed in a way that does not offer safely two instances of Qt to run in the same process address space. I saw that the Qt interface permits not to export the symbols (and I am not sure if this option was developed until the end), but in this case you'll need to build all Qt with this option, dynamic or statically... but this is too complicated, and probably not really possible for Qt, and I am afraid with QML module added will make things even worse.

In general every dependence you add to the plugin be sure that it will not behave in this way. If you add something be sure that it is used by the host/DAW too[*] and you are ABI compatible with that or you build/link it statically by turning off symbols export if it is possible. On the other hand, every plugin at the end will depend say of X11 API library, for example, shared libraries, but this library is only loaded by the host once (and only one version) because is base for every GUI that runs on the system. So, GUI toolkits for plugins better to make use only of "system wide" things.

Probably for these reasons there are also developed GUI toolkits for plugins like DISTRHO by GNU/Linux audio hackers, VST GUI by Steinberg, or maybe JUCE too. But be ware if you'll use one of these toolkits (or Redkite) instead of Qt than there will be a lot of limits you can do, the first one, you may not have a file browser that is native or that is mature and cross-platform, you many not have advanced dynamic layout features which often complicates things, cross-platform shortcuts support, things related to graphics backends rendering etc.

If you'll decide to use one of these toolkits and want to have a cross-platform and cross-format plugins support out of the box, than I recommend DISTRHO.

"OSC to the sound engine" - I don't know this engine but for LV2 and in general for plugins you don't need to use any sound engine, the host takes care of this, you need this only for standalone version. For standalone make sure that engine supports JACK as an option at least, because JACK is a GNU/Linux audio standard for music, you need to support it.

[*] Even in this case it is a not a guarantee, it needs that library also to be thread-safe, and not to depend of a global state

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

Basslint wrote: I'm thinking about writing an LV2 plugin with an interface made in QML which comunicates via OSC to the sound engine, so that the GUI and audio part are well separated. Your opinion as a much more experienced developer would be much appreciated :D
Sorry, I have misinterpreted what you mean by this. I thought you mean an audio module from Qt that access the audio engine. Probably you mean inter-process communication that uses OSC protocol? If you'll do this, than most probably any implementation will cause many context switches between the host/DAW and the other process if there are many tracks that use the plugin.

sjaehn
Established Member
Posts: 63
Joined: Fri May 03, 2019 6:05 pm

Re: Percussion Synthesizer

Post by sjaehn »

iurie wrote:If the user wants to load different plugins that were based on different versions of Qt, than the host needs to load in its address space two different shared Qt libraries which in the most of the cases will cause the host/DAW to crash due to various reasons....
[/quote]

I fully agree with iurie. If you really want to make a Qt-based plugin, you also should get sure that your DAW is not running on a different version of Qt. Thus, (all) your Qt plugins should run on the same version as your DAW. And you end up with (re-)writing all plugins for each specific version for each DAW. What a mess.

You have the same problem with GTK plugins. Maybe even worse. Ardour still runs on the ancient GTK2. Updating a plugin to GTK3 (and maybe next to GTK4) would break its compatibility with the (maybe) most important linux DAW.

This is the reason why many of the LV2 programmers use their own toolkits. Like robtk, AVTK, BWidgets or iuries redkite.

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

sjaehn wrote:I fully agree with iurie. If you really want to make a Qt-based plugin, you also should get sure that your DAW is not running on a different version of Qt. Thus, (all) your Qt plugins should run on the same version as your DAW. And you end up with (re-)writing all plugins for each specific version for each DAW. What a mess.
That DAW maybe running on GTK or Qt, or even pure X11 API. The problem will still persist when the DAW will load two different plugins that use different versions of, for sample, Qt. The process will need to load two different shared Qt libraries.

There is another scenario even when Qt versions are the same, and the host is based say on GTK. Most of the GNU/Linux distros will not provide a DAW build that offers a running LV2 Qt instance. To solve this, some plugins creates/deletes the Qt instance alone when the GUI of the plugin is opened/closed. Then the plugin one opens the GUI it will create the Qt instance. The second plugin that belongs to a different author will check if the Qt instance is running and because is running will open GUI2. When the user will close GUI1, the DAW will crash.

Basslint
Established Member
Posts: 616
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Percussion Synthesizer

Post by Basslint »

iurie wrote:
Basslint wrote: I'm thinking about writing an LV2 plugin with an interface made in QML which comunicates via OSC to the sound engine, so that the GUI and audio part are well separated. Your opinion as a much more experienced developer would be much appreciated :D
Sorry, I have misinterpreted what you mean by this. I thought you mean an audio module from Qt that access the audio engine. Probably you mean inter-process communication that uses OSC protocol? If you'll do this, than most probably any implementation will cause many context switches between the host/DAW and the other process if there are many tracks that use the plugin.
Yes, I meant the DSP code is run on a server that doesn't use Qt's libraries and the client uses QML, and they communicate via OSC. ZynaddsubFX already does this, by the way - I don't know if they are having any issues.

Anyway, I think Redkite is a very nice project. Some of the other plugin frameworks try to do too much, IMHO, even if they are modular - it'd be nice to have an UI toolkit specifically aimed at audio plugin that only does that. The only think I would miss from Qt is QML itself, because declarative GUIs to me are the easiest to write and read, and they also separate clearly the interface from the rest of the code.

I think zyn-fusion took a very good approach. If you have the time, please take a look at this article, I'd like to hear your thoughts on it.

By the way, I'm packaging both Redkite and Geonkick on openSUSE.
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]

Wanna make music on openSUSE? Check out GeekosDAW!

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

Basslint wrote: Yes, I meant the DSP code is run on a server that doesn't use Qt's libraries and the client uses QML, and they communicate via OSC. ZynaddsubFX already does this, by the way - I don't know if they are having any issues.
At least before ZynaddsubFX was running as separate process under LMMS. I think now as LV2 it runs in the address space of the host.
Basslint wrote:I think zyn-fusion took a very good approach. If you have the time, please take a look at this article, I'd like to hear your thoughts on it.
From my point of view zyn-fusion central idea was to implement declarative language for UI inspired from QML on top of a GUI PUGL API (toolkit). There is long debate like declarative language vs Widgets, at least due to parsing and interpretation a declarative UI should load slower, but I think this might be negligible in the majority of cases and depends of implementation. On the other hand hot load permits faster to make changes and separate some kind of UI, styling, theming.

Regarding OSC. If you are going to implement the DSP on a different process than the host/DAW this will be very inefficient. Use only in-process to transfer the state between GUI and the DSP, i.e. all should run in the DAW process, context switch between threads are faster. Also you'll add a new process running in the system, which may create other inconveniences for the system and the user. For example, the system may decide to kill/restart that process for a reason. This will not be a really self sufficient plugin, and vulnerable.
Basslint wrote: By the way, I'm packaging both Redkite and Geonkick on openSUSE.
Thank you. :) When is ready, I'll add a link to the package and the author in the README.

Basslint
Established Member
Posts: 616
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Percussion Synthesizer

Post by Basslint »

Thanks for the further explanation, Iurie.

Geonkick now has an openSUSE package (redkite as well, same repo). I tested it both standalone and LV2 under Ardour, and it works.
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]

Wanna make music on openSUSE? Check out GeekosDAW!

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

Basslint wrote:Thanks for the further explanation, Iurie.

Geonkick now has an openSUSE package (redkite as well, same repo). I tested it both standalone and LV2 under Ardour, and it works.
Hi, thank you :) I've added this in the README file.

Basslint
Established Member
Posts: 616
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Percussion Synthesizer

Post by Basslint »

iurie wrote: Hi, thank you :) I've added this in the README file.
No problem! Thank you for sharing this awesome program. Before the packages gets more popular, a question - do you prefer that packages keep the uppercase first letter (Redkite and Geonkick) or it's indifferent?

Also (not related to package, but could be useful to users), do you know any resources (books, articles, etc.) to learn about percussion synthesis?

Edit: actually, it would be better for consistency across distros if we could write them all lowercase (geonkick and redkite)
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]

Wanna make music on openSUSE? Check out GeekosDAW!

iurie
Established Member
Posts: 52
Joined: Fri Jan 04, 2019 3:38 pm

Re: Percussion Synthesizer

Post by iurie »

Basslint wrote: No problem! Thank you for sharing this awesome program. Before the packages gets more popular, a question - do you prefer that packages keep the uppercase first letter (Redkite and Geonkick) or it's indifferent?
A command line program or package as geonkick. I like more Geonkick for program title.
Basslint wrote:Also (not related to package, but could be useful to users), do you know any resources (books, articles, etc.) to learn about percussion synthesis?
I am not aware of a such book but I don't think there would be a really book on this, often produces alone discover some kind of tricks and techniques how to do this or that. Someone better will learn how to do this by searching video tutorials on "how to synthesize kick, snare, hit-hat", get a synthesizer and try to replicate that. Geonkick can replicate many cases. There are some cases that involves FM syntheis and I think this has to be improved for Geonkick.

rghvdberg
Established Member
Posts: 990
Joined: Mon May 12, 2014 7:11 am

Re: Percussion Synthesizer

Post by rghvdberg »

https://www.soundonsound.com/techniques ... d-on-sound

Plenty of in depth percussion synthesis in there.

iurien
Posts: 2
Joined: Fri Oct 30, 2020 10:50 am

Geonkick repo is go

Post by iurien »

Hi,

Asked by @unfa to explain why I have abandoned the Geonkick development.

It was fun to develop this project but taking into account technical aspects I felt that the software is not really helpful for musicians. One can create a drumkit and percussive sounds by using a DAW with its powerful plugins, automation and routing and create high quality drumkits and export them to formats like sfz, play samplers with sfizz or DrumGizmo.

Even if Geonkick synthesizes the sound at the end it saves the sound into the memory buffers, which are played by the sampler module (a simplified sampler). In this way Geonkick can't have velocity expression for parameters like other synthesizers or can't map different samples for different velocity range like sampler players (sfizz or liquidsfz). To enable this I wanted to develop layers to velocity mapping but it would make a Geonkick plugin instance to take a lot of memory. In samplers because they usually are not synthesizing in real time, the samples can be shared between instances, also buffers can be of different size and this makes memory consumption less. Geonkick is not the case because every instance synthesize its own samples in real time, and needs a fixed preallocated memory for every instance.
To overcome this problem there can be moved the synthesis into the audio thread an synthesize on the fly, thus, taking more CPU and almost no memory. But if there will be say two instances with 16 instruments... than I don't know, maybe this is not much CPU. Anyway, this requires rewriting of the core synth to work differently.

Redkite that is used by Geonkick and the interface of which is made very close to Qt I haven't seen being used by someone, and there are similar projects like plugl or JUCE that have more features probably.

For now these are my conclusion and I have decided to freeze both projects. If my mind will change, than maybe I'll restart the development.
Thank you for all who contributed with ideas to this project.
Last edited by iurien on Fri Oct 30, 2020 11:36 am, edited 1 time in total.

iurien
Posts: 2
Joined: Fri Oct 30, 2020 10:50 am

Geonkick repo is archived

Post by iurien »

Hi,

Asked by @unfa to explain why I have abandoned the Geonkick development.

It was fun to develop this project but taking into account technical aspects I felt that the software is not really helpful for musicians. One can create a drumkit and percussive sounds by using a DAW with its powerful plugins, automation and routing and create high quality drumkits and export them to formats like sfz, play samplers with sfizz or DrumGizmo.

Even if Geonkick synthesizers the sound at the end it saves the sound into the memory buffers, which are played by the sampler module (a simplified sampler). In this way Geonkick can't have velocity expression for parameters like other synthesizers or can't map different samples for different velocity range like sampler players (sfizz or liquidsfz). To enable this I wanted to develop layers to velocity mapping but it would make a Geonkick plugin instance to take a lot of memory. In samplers because they usually are not synthesizing in real time, the samples can be shared between instances, also buffers can be of different size and this makes memory consumption less. Geonkick is not the case because every instance synthesize its own samples in real time, and needs a fixed preallocated memory for every instance.
To overcome this problem there can be moved the synthesis into the audio thread an synthesize on the fly, thus, taking more CPU and almost no memory. But if there will be say two instances with 16 instruments... than I don't know, maybe this is not much CPU. Anyway, this requires rewriting of the core synth to work differently.

Redkite that is used by Geonkick and the interface of which is made very close to Qt I haven't seen being used by someone, and there are similar projects like plugl or JUCE that have more features probably.

For now these are my conclusion and I have decided to freeze both projects. If my mind will change, than maybe I'll restart the development.
Thank you for all who contributed with ideas to this project.

Kott
Established Member
Posts: 343
Joined: Thu Mar 21, 2013 12:55 am
Location: Vladivostok

Re: Percussion Synthesizer

Post by Kott »

This is not cool. We don't have many percussion synths, and I still find Geonkick promising.

tavasti
Established Member
Posts: 1148
Joined: Tue Feb 16, 2016 6:56 am
Location: Kangasala, Finland
Contact:

Re: Percussion Synthesizer

Post by tavasti »

I also like geonkick. But it is opensource, someone else can continue development.
Linux veteran & Novice musician

Latest track: https://www.youtube.com/watch?v=ycVrgGtrBmM
More my music https://audiu.net/users/tawaste

Post Reply