Closed akimaze closed 1 year ago
Thanks! That looks great. I'll look more closely later today. I'll also look more at the instrument deletion bug. To reproduce the bug, do I revert https://github.com/kmatheussen/radium/commit/5cf3bbb30176d53fec8e187ca44e69fe32d9d167 first, and then select a preset from the preset browser?
On Sun, May 22, 2022 at 9:14 PM akimaze @.***> wrote:
Hi this is the most important feature that I missed the most in Radium, so I tried to implement it.
Now it look s like this:
[image: image] https://user-images.githubusercontent.com/63190361/169711298-4465caa0-b841-4a41-ae8d-a5d38d0f8918.png How it works Searching
In order not to create some tag system etc. I adopted a solution similar to the one in LMMS. Presets can be in any number of subfolders. The search searches through all subfolders and returns results that match not only the file names but the folders as well. For example, if we are looking for bass, all files containing the word bass will be displayed, but also all other files that are in a subfolder with the name containing the word bass :
[image: image] https://user-images.githubusercontent.com/63190361/169711362-339fcbdf-5bba-43d2-9b96-a4ed0a9823e7.png
In my opinion subfolders are better than the tag system - creating presets is much faster when you only have to enter the filename. Playing
When you press the left mouse button on the preset a temporary instrument is created and it plays the note selected with the currently checked note button at the bottom of the preset panel. You can change octave by F1, F2 keys. We can also add checkbox to enable/disable this feature. But this feature is essential for me.
Currently only one note is playing but i the feture we can add mode to play chords. Creating and adding instrument to current track
Simply double click on preset in the tree to add instrument and assign it to current track. Previous instrument is not deleted. Added instrument name is changed to preset file name. Showing/hidding preset panel
I added option in menu, by default its visible. Opportunities for the future
We can add tabs on the top to add samples folders and saved blocks to import to project. Configuration
Currently Preset Browser searches ~/Radium Presets folder. I tried to add configuration in preferences but I don't know how implement saving this path from QLineEdit. I added Preset browser" tab, but in the future (when there will be samples/blocks tabs) its name should change to "Browser" and there will be more content. Other bugs
I found a bug that makes a deadlock in instrument deleting, see 5cf3bbb https://github.com/kmatheussen/radium/commit/5cf3bbb30176d53fec8e187ca44e69fe32d9d167. I don't know this is right solution but after that change preset browser preview preset works always. Optimization
To enable preset playback I create an instrument and when the mouse button is up I remove the instrument. It is quite slow, but I think you probably know a better solution. Maybe hidden instrument for preset preview. That's too hard to me to make (I don't know Radium sources so well currently). Performance
Currently, I checked the search performance on a small number of presets, so I don't know how it will work on a large number of presets. Code
I don't know Radium sources so well currently, so some things may done wrong or not optimal. I tried to write code in your style.
I hope you enjoy this feature. If you want to include it in Radium. Feel free change anything you want.
You can view, comment on, or merge this pull request online at:
https://github.com/kmatheussen/radium/pull/1383 Commit Summary
- a8b0526 https://github.com/kmatheussen/radium/pull/1383/commits/a8b0526d782014e2f107cfe07729e09b4899ceca Initial working version of preset browser.
- 5cf3bbb https://github.com/kmatheussen/radium/pull/1383/commits/5cf3bbb30176d53fec8e187ca44e69fe32d9d167 Fix deadlock when we create instrument during remove another one.
- 113ff77 https://github.com/kmatheussen/radium/pull/1383/commits/113ff7733bb6af59db3211582f8d1d275240dfd0 Make preset browser smaller at start.
- 3398837 https://github.com/kmatheussen/radium/pull/1383/commits/339883782a6f564c2c75c2c1d9e60df096c0df78 Added getPresedBrowserFrame().
- cd46ac8 https://github.com/kmatheussen/radium/pull/1383/commits/cd46ac8d3bea4848bc625a6a514d1c5ee11c088f Ability to select the note that will be played after holding down the mouse button on preset.
- 7cc5a21 https://github.com/kmatheussen/radium/pull/1383/commits/7cc5a21652ee404844d160af8fd8aa3a3a0ff20b Code clean.
- e96f052 https://github.com/kmatheussen/radium/pull/1383/commits/e96f052fa960e0ea42424b23bb922273d01c4a4d Check file extension.
- ed52920 https://github.com/kmatheussen/radium/pull/1383/commits/ed52920bce7b95f5170bbb5778c3bd2cfd5a4b89 Play preset only on left mouse button click
- 73a1b4e https://github.com/kmatheussen/radium/pull/1383/commits/73a1b4e69fb1156b5adcf32b6af2d447a1d0a601 Ability to show/hide preset browser.
- 9ef20f5 https://github.com/kmatheussen/radium/pull/1383/commits/9ef20f5b8d1fcb538b61c3fab1237450f1b9f5b5 Ability to set preset root folder, preset browser tab in preferences.
- 77fa53f https://github.com/kmatheussen/radium/pull/1383/commits/77fa53f9b22e97d2d84a4c05351b4a9ff0156e78 Clean up includes.
- af17699 https://github.com/kmatheussen/radium/pull/1383/commits/af17699bf9ac0e0097667f74c26e50b190e2888d Remove uneeded log.
File Changes
(11 files https://github.com/kmatheussen/radium/pull/1383/files)
- M Makefile.Qt https://github.com/kmatheussen/radium/pull/1383/files#diff-6db49199de1888ef7b005968889aa4d336cabfa196959b7881e1c0fd43c106e4 (15)
- M Qt/EditorWidget.h https://github.com/kmatheussen/radium/pull/1383/files#diff-dbe3b3ce279f7a7abe3f0759ec975d92000c505669d4d4c6f4b2043ae8c89b42 (4)
- M Qt/FocusSniffers.h https://github.com/kmatheussen/radium/pull/1383/files#diff-8cd6e9fb632d3037c2b3e73fec3a042fa2c3d6fe3d29c97f5a363a6d0014efea (2)
- M Qt/Qt_Main.cpp https://github.com/kmatheussen/radium/pull/1383/files#diff-c7703c2fda9fb7695b156de0cbdf522aa5e8c3f6269de90eb45cc8ff6b14cfff (16)
- A Qt/Qt_PresetBrowser.cpp https://github.com/kmatheussen/radium/pull/1383/files#diff-67d36ca2dc4a331c01917e13c852df286c0ddd2fc279e7c1ad0a5308de130770 (418)
- A Qt/Qt_PresetBrowser.h https://github.com/kmatheussen/radium/pull/1383/files#diff-47d25137473761fa84bc2d2023208a2145e6ffe4d7bd9300d804879d3563dfbd (30)
- M Qt/Qt_preferences_callbacks.cpp https://github.com/kmatheussen/radium/pull/1383/files#diff-d3014e1268f03cf2ab93106cdc8115ecf6e8ecc8c4c79d159e30071a0bb62ddc (5)
- M Qt/qt4_preferences.ui https://github.com/kmatheussen/radium/pull/1383/files#diff-645fa1fbeed113bd66ae37f1650ed19df4f54881f14c0e6b727ab2b6096d4afe (54)
- M api/protos.conf https://github.com/kmatheussen/radium/pull/1383/files#diff-1b1912b8deff148d1f643eda1cee50ae5d3fc7ae0699b58fc60740a97e9ff810 (2)
- M audio/Juce_plugins.cpp https://github.com/kmatheussen/radium/pull/1383/files#diff-02c99496e30e5150ed0073e7d1da0d2aabe48a9b612d792e70483d31be2d78ac (4)
- M bin/menues.conf https://github.com/kmatheussen/radium/pull/1383/files#diff-1dd657b4a8be77ecc42663f77291034d6d043d4a5df4243a4b00d3d21fbd5d0a (1)
Patch Links:
- https://github.com/kmatheussen/radium/pull/1383.patch
- https://github.com/kmatheussen/radium/pull/1383.diff
— Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/pull/1383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX3J7UQ5EVLABUBT25ZSLVLKBTDANCNFSM5WTZQTNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
You just need to click the various presets quickly (I need about 10-20 clicks), and at some point the Radium window will freeze. With this fix (https://github.com/kmatheussen/radium/pull/1383/commits/5cf3bbb30176d53fec8e187ca44e69fe32d9d167) it never happened.
Everything seems to work fine. It's very good that the browser automatically updates when files are created.
I was a little bit confused in the beginning though since it seemed like the instrument was deleted immediately after it was created when you clicked on them. Of course, it's actually supposed to do that, and you must double-click to create an instrument, not single-click as I did. But it would probably be good if there was an option to create an instrument without it showing up briefly in the mixer. I'll see if I can fix that.
I can also reproduce the deadlock. It seems to be something deeply wrong. Your fix is probably fine though, but I would like to understand what happens.
Okay, I understand what happens. I don't know if you studied it, but in case not, it's not so deep problem, it's caused by calling juce::MessageManager::getInstance()->callFunctionOnMessageThread while holding the JUCE_show_hide_gui_lock lock. This causes a deadlock because 'callFunctionOnMessageThread' is not async and the message thread itself can't run anything because it's trying to obtain the JUCE_show_hide_gui_lock lock
The JUCE api for 'callFunctionOnMessageThread' even warns about this deadlock! :-) https://docs.juce.com/master/classMessageManager.html#a554f81587d57127c9cb5be72aced11c1
I was a little bit confused in the beginning though since it seemed like the instrument was deleted immediately after it was created when you clicked on them. Of course, it's actually supposed to do that, and you must double-click to create an instrument, not single-click as I did. But it would probably be good if there was an option to create an instrument without it showing up briefly in the mixer. I'll see if I can fix that.
That would be great, and if it could be possible to add a flag that the instrument should not be saved in the project file. Then we could not delete it on mouse up event and if someone presses the same preset a second time, we could use it again (simply play note).
I was also wondering if it is possible to determine which plugin the preset is using without loading it. Then, if you select another preset that uses the same plug-in, you could only load its state not recreating the whole instrument. But I don't know if it is possible.
On Tue, May 24, 2022 at 9:42 AM akimaze @.***> wrote:
I was a little bit confused in the beginning though since it seemed like the instrument was deleted immediately after it was created when you clicked on them. Of course, it's actually supposed to do that, and you must double-click to create an instrument, not single-click as I did. But it would probably be good if there was an option to create an instrument without it showing up briefly in the mixer. I'll see if I can fix that.
That would be great, and if it could be possible to add a flag that the instrument should not be saved in the project file. Then we could not delete it on mouse up event and if someone presses the same preset a second time, we could use it again (simply play note).
I was also wondering if it is possible to determine which plugin the preset is using without loading it. Then, if you select another preset that uses the same plug-in, you could only load its state not recreating the whole instrument. But I don't know if it is possible.
Yes, that's possible. ".rec" files are hash tables, which you can read using the functions in common/hashmap.c (see "get_preset_state_from_filename" in Presets.cpp). You use "name" to find plugin name, and "type_name" to find plugin type (e.g. "VST") (see audio/audio_instruments.cpp).
Message ID: @.***>
On Tue, May 24, 2022 at 10:41 AM Kjetil Matheussen @.***> wrote:
On Tue, May 24, 2022 at 9:42 AM akimaze @.***> wrote:
I was a little bit confused in the beginning though since it seemed like the instrument was deleted immediately after it was created when you clicked on them. Of course, it's actually supposed to do that, and you must double-click to create an instrument, not single-click as I did. But it would probably be good if there was an option to create an instrument without it showing up briefly in the mixer. I'll see if I can fix that.
That would be great, and if it could be possible to add a flag that the instrument should not be saved in the project file. Then we could not delete it on mouse up event and if someone presses the same preset a second time, we could use it again (simply play note).
I was also wondering if it is possible to determine which plugin the preset is using without loading it. Then, if you select another preset that uses the same plug-in, you could only load its state not recreating the whole instrument. But I don't know if it is possible.
Yes, that's possible. ".rec" files are hash tables, which you can read using the functions in common/hashmap.c (see "get_preset_state_from_filename" in Presets.cpp). You use "name" to find plugin name, and "type_name" to find plugin type (e.g. "VST") (see audio/audio_instruments.cpp).
(Not entirely sure about the names of the hashmap keys, but just open the files in a text editor, and you should find the information you need there)
Here's a more-than-half-finished patch to add option to create invisible audio-instruments. It's not hiding mixer strips and it's not hiding mixer connections, but I'm on my way out and don't have time to finish it, but you can assume it's going to be finished when I get back. :-)
I was trying to speed up preset loading by code like this (only reload plugin state):
if (isLegalInstrument(presetDemoInstrument)) {
// try modify instrument
disk_t *file = DISK_open_for_reading(filePath);
if (file) {
hash_t * preset = HASH_load(file);
DISK_close_and_delete(file);
if (preset && HASH_has_key(preset, "audio")) {
hash_t* audio = HASH_get_hash(preset, "audio");
if (audio) {
struct Patch *patch = getPatchFromNum(presetDemoInstrument);
if (patch) {
hash_t* pluginst = HASH_get_hash(audio, "plugin_state");
if (pluginst) {
PLUGIN_recreate_from_state((SoundPlugin *)patch->patchdata, pluginst, false);
int notenum = root->keyoct + 24 + selectedNote(); // default is 36 C2
if(notenum>=0 && notenum<127)
{
playnote_id = playNote(notenum, 120, 0, 0, presetDemoInstrument); // startuje granie nuty
}
stopIgnoringUndo();
return;
}
...
But with VST3 plugins (Surge XT), the note is not played. But when I open plugin GUI and click in piano key they works. Is something else needed here? VST2 works OK.
OK I found that i need add:
std::this_thread::sleep_for(std::chrono::milliseconds(50));
after
PLUGIN_recreate_from_state((SoundPlugin *)patch->patchdata, pluginst, false);
to hear note, so is there any way to check instrument is ready?
OK now presets loading works a lot faster but there are some todos :
std::this_thread::sleep_for(std::chrono::milliseconds(50));
)? And make preset preview instrument invisible. I didn't apply your patch because I had modified code. But you can safely commit to this branch or merge :-)
Great work! Sorry for late reply.
Should I delete hash_t* ?
No need, it's garbage-collected using BDW-GC.
How to check plugin is ready (currently I added std::this_thread::sleep_for(std::chrono::milliseconds(50));)?
Plugin should actually be ready. Maybe it's a JUCE bug, or I haven't used the JUCE api correctly. I'll check.
Small note to your code: It's extremely important that startIgnoringUndo() is followed by stopIgnoringUndo(), so just to be 100% sure that's done correctly, it's probably better to use the radium::ScopedIgnoreUndo class instead.
I can't see anything about this in the JUCE API. I guess it's another VST3 quirk in juce. Do you only have to call 'std::this_thread::sleep_for' after calling 'PLUGIN_recreate_from_state', or do you also have to call it after 'createAudioInstrumentFromPreset'?
I can't see anything about this in the JUCE API. I guess it's another VST3 quirk in juce. Do you only have to call 'std::this_thread::sleep_for' after calling 'PLUGIN_recreate_from_state', or do you also have to call it after 'createAudioInstrumentFromPreset'?
Only in this one place (PLUGIN_recreate_from_state
). I suspected that maybe reading state of plugin is made in another not synced thread and I should use a callback or something else to start play note. I think createAudioInstrumentFromPreset
do other things after reading plugin state so maybe plugin has enough time to load its state.
However, loading only the plugin state is much faster than creating the entire instrument and plug-in. This makes searching, or rather auditioning, multiple presets (of the same plugin) much more enjoyable. I'm just not sure if other things should be loaded here, such as the state of the radium compressor, filter. Are they also saved in .rec preset?
Small note to your code: It's extremely important that startIgnoringUndo() is followed by stopIgnoringUndo(), so just to be 100% sure that's done correctly, it's probably better to use the radium::ScopedIgnoreUndo class instead.
That should be more safety (I didn't know about that solution before). For the next week, I don't have time to change that. So you can change that if you don't want to wait for me.
On Tue, May 31, 2022 at 9:04 PM akimaze @.***> wrote:
I can't see anything about this in the JUCE API. I guess it's another VST3 quirk in juce. Do you only have to call 'std::this_thread::sleep_for' after calling 'PLUGIN_recreate_from_state', or do you also have to call it after 'createAudioInstrumentFromPreset'?
Only in this one place (PLUGIN_recreate_from_state). I suspected that maybe reading state of plugin is made in another not synced thread and I should use a callback or something else to start play note. I think createAudioInstrumentFromPreset do other things after reading plugin state so maybe plugin has enough time to load its state.
Everything should be initialized after PLUGIN_recreate_from_state has returned. This looks like a JUCE bug, especially since it only happens with VST3. Maybe it's working in the juce7 branch? I guess the reason you don't have to wait when using createAudioInstrumentFromPreset could be that createAudioInstrumentFromPreset waits until the next audio block has been processed, if I remember correctly.
However, loading only the plugin state is much faster than creating the entire instrument and plug-in. This makes searching, or rather auditioning, multiple presets (of the same plugin) much more enjoyable. I'm just not sure if other things should be loaded here, such as the state of the radium compressor, filter. Are they also saved in .rec preset?
Yes, all instrument settings such as radium compressor, equalizer, and so forth, should all be saved in the .rec files.
Message ID: @.***>
I've pushed the complete "optional invisible instrument" patch to master: https://github.com/kmatheussen/radium/commit/dd413aa7b2173607e016ab5ee48bfb2106a6b91c
And here is a better fix for the deadlock: https://github.com/kmatheussen/radium/commit/888cdf773ac1f69185b3d492767844061afc3651
The reason for the delay is that on macOS only the GUI need some time to be deleted in the background before the plugin can be deleted. If not you get a crash at program shutdown. This is documented in the JUCE api, and I have also experienced it myself. If I remember correctly it's caused by a badly designed API from Apple. So on Linux and Windows your fix is fine, but I want to run the same code as much as possible on all three platforms.
Hi, I made git rebase
, added radium::ScopedIgnoreUndo
, reverted my deadlock fix. But I noticed few bugs:
radium::ScopedIgnoreUndo
but also with previous start/stopIgnoringUndo()
). It only happens sometimes. deletePresetDemoInstrument()
to delete instrument when preset browser is destroyed, it should be also called when someone load or create new song. I didn't found the right place in source code. Is the hidden instrument saved in project? I think it should not be saved.
I found that the unneeded undo is made by PLUGIN_call_me_very_often_from_main_thread()
by this two lines:
if (is_old && s_euds.size() > 0) // || Undo_num_undos() != s_last_undo_num)
add_eud_undo(s_euds, s_stored_effect_nums, curr_time, s_last_time, s_last_undo_num);
Its made sometimes when preset browser use PLUGIN_recreate_from_state(plugin, pluginState, false);
I guess this should fix the undo:
kjetil@tthp:~/radium_presetbrowser$ git diff audio/SoundPlugin.cpp
diff --git a/audio/SoundPlugin.cpp b/audio/SoundPlugin.cpp
index 67d9ac742..dc85902e4 100644
--- a/audio/SoundPlugin.cpp
+++ b/audio/SoundPlugin.cpp
@@ -1493,7 +1493,8 @@ static void add_eud_undo(QVector<EffectUndoData> &s_euds, QHash<instrument_t, QS
if (patch != NULL) {
//printf(" EUD undo %d: %f\n", eud.effect_num, eud.effect_value);
- ADD_UNDO(AudioEffect_CurrPos2(patch, eud.effect_num, eud.effect_value, AE_ALWAYS_CREATE_SOLO_AND_BYPASS_UNDO));
+ if (patch->is_visible)
+ ADD_UNDO(AudioEffect_CurrPos2(patch, eud.effect_num, eud.effect_value, AE_ALWAYS_CREATE_SOLO_AND_BYPASS_UNDO));
}
}
}
And temporary instruments are saved to disk, so that needs to be fixed as well.
Thanks fixed :)
Here's patches to fix saving only visible instruments to disk:
https://github.com/kmatheussen/radium/commit/e5dc108fdcbf622c4b30e816d3d3bce132545099 https://github.com/kmatheussen/radium/commit/1bce67619f8ad23015c3b61bf7434c129260785f
Note that I haven't tested when there are invisible instruments in the mixer though.
I'm on a short vacation and I'll check/test when I get home.
Sorry for delay. In the meantime, I installed pkgconf
, and it turns out that compilation only works with pkg-config
. With pkgconf
I get a lot of undefined reference errors from QT. It took me a while to figure out what has changed in my environment.
I rebased the pull request. It seems that the hidden instrument is not being saved. But sometimes the modular mixer is empty.
Steps to reproduce:
But when you change view to "normal" mixer by clicking "M" button you can see all instruments.
What happens, at least to me, is that the scrollbars have been moved so that the modules are not visible. So I can just scroll back. I guess this happens because invisible instruments are positioned very far away from the other modules.
Yes you are right, the scrollbar range is very large. I didn't notice that the first time.
I added removing preset browser instrument, so loading another song or create new song works now :)
The extremely large mixer scene rect seems to be caused by a quirk/bug in Qt. The scene rect is automatically calculated from the visible items in it, but if the mixer hasn't been shown yet, it's also calculated from the invisible items. This workaround seems to work. I'm not sure if it'll always work though:
kjetil@tthp:~/radium_presetbrowser$ git diff Qt/
diff --git a/Qt/Qt_Main.cpp b/Qt/Qt_Main.cpp
index 04d7618b7..4e2395d70 100755
--- a/Qt/Qt_Main.cpp
+++ b/Qt/Qt_Main.cpp
@@ -2570,11 +2570,21 @@ protected:
// No, we still need to do this. At least in qt 5.5.1. Seems like it's not necessary in 5.7 or 5.8 though, but that could be coincidental.
if(num_calls_at_this_point<150/_interval)
updateWidgetRecursively(g_main_window);
-
+
+ // Show mixer briefly to workaround a Qt quirk/bug causing SceneRect size to be calculated from invisible items when the scene hasn't been shown yet.
+ // (Fixes extremely large Mixer scene rect if previewing preset before opening the mixer for the first time)
+ {
+ if(num_calls_at_this_point==50/_interval)
+ GFX_ShowMixer();
+
+ if(num_calls_at_this_point==70/_interval)
+ GFX_HideMixer();
+ }
+
Thanks! Great work! I'm going to hide the preset browser during startup though, and I'm probably going to move the preferences line edit somewhere else.
Added couple of commits:
0df6a0f0f8db868e53fe2f8837a9856990c15d08 1521ad6fd3b988cff20b729344fb1d356c5f205f
Fix for preferences: 0b4c48c6c8a8caf59c7963961fffb0d0af3c2886
Great news, thanks for merging :)
I'm going to hide the preset browser during startup though
It would be great if displaying/hiding state of the preset browser would be saved in the configuration file to not to have to turn it on/off every time you launch Radium (depending on the user's preferences).
I'm going to hide the preset browser during startup though
It would be great if displaying/hiding state of the preset browser would be saved in the configuration file to not to have to turn it on/off every time you launch Radium (depending on the user's preferences).
Yes, good idea. That scheme would probably fix #1378 as well if done for all windows...
Done: 4f52c7b658874780f2af8f0c399c7c21c0145678
Hi this is the most important feature that I missed the most in Radium, so I tried to implement it.
Now it look s like this:
How it works
Searching
In order not to create some tag system etc. I adopted a solution similar to the one in LMMS. Presets can be in any number of subfolders. The search searches through all subfolders and returns results that match not only the file names but the folders as well. For example, if we are looking for
bass
, all files containing the word bass will be displayed, but also all other files that are in a subfolder with the name containing the wordbass
:In my opinion subfolders are better than the tag system - creating presets is much faster when you only have to enter the filename.
Playing
When you press the left mouse button on the preset a temporary instrument is created and it plays the note selected with the currently checked note button at the bottom of the preset panel. You can change octave by F1, F2 keys. We can also add checkbox to enable/disable this feature. But this feature is essential for me.
Currently only one note is playing but i the feture we can add mode to play chords.
Creating and adding instrument to current track
Simply double click on preset in the tree to add instrument and assign it to current track. Previous instrument is not deleted. Added instrument name is changed to preset file name.
Showing/hidding preset panel
I added option in menu, by default its visible.
Opportunities for the future
We can add tabs on the top to add samples folders and saved blocks to import to project.
Configuration
Currently Preset Browser searches
~/Radium Presets
folder. I tried to add configuration in preferences but I don't know how implement saving this path from QLineEdit. I added Preset browser" tab, but in the future (when there will be samples/blocks tabs) its name should change to "Browser" and there will be more content.Other bugs
I found a bug that makes a deadlock in instrument deleting, see https://github.com/kmatheussen/radium/commit/5cf3bbb30176d53fec8e187ca44e69fe32d9d167. I don't know this is right solution but after that change preset browser preview preset works always.
Optimization
To enable preset playback I create an instrument and when the mouse button is up I remove the instrument. It is quite slow, but I think you probably know a better solution. Maybe hidden instrument for preset preview. That's too hard to me to make (I don't know Radium sources so well currently).
Performance
Currently, I checked the search performance on a small number of presets, so I don't know how it will work on a large number of presets.
Code
I don't know Radium sources so well currently, so some things may done wrong or not optimal. I tried to write code in your style.
I hope you enjoy this feature. If you want to include it in Radium. Feel free change anything you want.