New CLAP plug-in host assessment / development...

[rncbc]

hi there,

currently hacking my way trough clap and indulging into my own offspring qtractor...

as a matter of fact I'm facing some strange issues, possibly my own infantile mistakes--to my defense, I've started the clap business just a couple of days ago, so don't sue me just yet--and on the example clap-plugins, for instance clap-synth seems to never recognize a note-off; note-ons are piling up alright and hanging forever :S...

so, is there a more specific forum to this kind of questions, specially dedicated to the (rare) host developers, or am I left alone pissing in the dark ? :)...

tia.
cheers

ps. summer vacations are nig, what a better time to deal with a brand new plugin spec, yay?

[robbert-vdh]

Do you have any code you can share? I had already checked the branches in the Qtractor repo but I couldn't find anything related to CLAP.

[rncbc]

no public code at the moment, sorry (summer is comig though;))

[abique]

Could you set a break point here?
https://github.com/free-audio/clap-plugins/blob/main/plugins/core-plugin.cc#L708

[rncbc]

Could you set a break point here? https://github.com/free-audio/clap-plugins/blob/main/plugins/core-plugin.cc#L708

it's gettin stranger, after update to clap 1.0.0, clap-synth fails with this kind of assertion:

.../clap-helpers/include/clap/helpers/note-end-queue.hh:46: bool clap::helpers::NoteEndQueue::checkValidEntry(int32_t, int16_t, int16_t, int16_t): Assertion `noteId >= -1' failed.

was on clap 0.26.0 until yesterday (I think) and the assertion wasn't being triggered at all but note-offs weren't caught; now hitting a note just crashes the whole thing :(

[baconpaul]

Heya @rncbc good to connect again! (You may remember we worked on making surge VST3 work in qtractor a few years ago)

Surge works as a CLAP pretty reliably at this point and may be a useful thing to try as a second choice? I also got a few others ported and ready to go. It could help eliminate moving parts perhaps?

You can grab the surge nightly with a pre-compiled clap from https://surge-synthesizer.github.io/nightly_XT or just build it yourself. They are all CLAP 1.0.0 so make sure you pull your clap and clap-helpers to the next branch (unless @abique has updated).

One thought: Are you checking the note ports extension properly? The core plugin should accept midi and clap note events but make sure it says so?

Happy to help; would be great to have an OSS Host running CLAP :)

[rncbc]

the code shown above was sourced from clap-host:
https://github.com/free-audio/clap-host/blob/d59c0cb76c2de1942d853fdc9da160cdc098decf/host/plugin-host.cc#L657
and there I see none of a reference to note_id initialization :/
will try and force it -1 when I find the time to look at it again
byee

[robbert-vdh]

Oh yeah in both versions it's actually using uninitialized memory. Which is obviously a thing that probably shouldn't be happening.

[baconpaul]

SO 0.26 and 1.0 are the same ABI but a different version. You need to pull your code to make sure your clap version is 1.0 (we have been changing it this week ahead of the official 1.0 start next week so you are in a transition period). Make sure you are using 1.0 of everything at link time.

Yes, you need to set note_id to -1 (if you aren't supporting note ids) or better to an incrementing note id (so you can) if the plugin supports CLAP_DIALECT_NOTE; You can also ignore CLAP_DIALECT_NOTE and just send midi if the plugin supports CLAP_DIALECT_MIDI

[rncbc]

yay. having ev.note_id = -1, lo and behold, it started to work, note-ons and note-offs alright!

at least for now I'm happy again ;)
cheers

[baconpaul]

Wonderful!

I'll either send a PR to the demo host or bug @abique about it before we do the official launch. Thanks for your pre-release patience!

[baconpaul]

@rncbc if you are strict MIDI 1 in QTractor one option is

1. Make sure the CLAP note port supports CLAP_DIALECT_MIDI and if it doesn't fail to load
2. Don't send CLAP_EVENT_NOTE_ON/OFF events
3. Just send CLAP_EVENT_MIDI events with the midi payload

basically don't use any of the extended note, midi2, mpe, or polyphonic API and just dump your raw midi into synths which accept it

I bet most synths will support CLAP_DIALECT_MIDI (although it is not a requirement).

And of course if you do that you won't get the sparkly new features like note expressions and polyphonic modulation. But you will get started.

Surge will work fine with that mode.

[rncbc]

hi, there

here introducing clap_test_scan as the current barebone in the genre that 's suitable to boarding the qtractor_plugin_scan in a near future...

however, there are very strange issues that must get tamed before I proceed with my quest

please have a look and tell what I'm really doing wrong, as there appears to have a very strange issue (briefly explained in the README.md).

thanks in advance && cheers

[rncbc]

yes, it scans fine too:

> build/src/clap_test_scan 
/usr/local/lib/clap/clap-saw-demo.clap
CLAP|Clap Saw Demo Synth|0:2|1:0|8:0|GUI,EXT,RT|/usr/local/lib/clap/clap-saw-demo.clap|0|0x3b528100

yeah i suspect there's a missing virtual dtor or some uninitialized data, or else, in the example clap-plugins, especially on the CLAP Synth (index=0).

byee

[baconpaul]

Great. I fixed some bugs with the clap saw demo but - depending on how far you got - when you use the ui it will use the host timer and posix fd extensions to render the gui.

I think we just need to debug the clap-plugin index 0! I will but @abique on discord also but I think the note id in host and fix to plug will help

I’m considering moving my clap-Val to be clap-info and have a more robust information query. Would host it on either surge or free audio repo then. But everything I write is in the spirit of open contribution so if there’s things you find useful pls fire over a pr or a patch here. I will add the ! Right now :)

[baconpaul]

OK anyway updated clap-val with the !. Thanks!

for what its worth, a very quick check on macOS and the clap-plugin doesn't throw an error (which is, of course, consistent with some memory error). If I get some time I'll try it with ASAN also.

[rncbc]

funny thing is that, as told you before, the debug build (with asan) doesn't complain a thing: it's really the non-debug build that is having trouble o.O

[rncbc]

here goes a backtrace caught in gdb:

> gdb build/src/clap_test_scan 
GNU gdb (GDB; openSUSE Tumbleweed) 11.1
Reading symbols from build/src/clap_test_scan...
(gdb) run
Starting program: .../clap_test_scan/build/src/clap_test_scan 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
/usr/local/lib/clap/clap-plugins.clap
free(): invalid pointer

Program received signal SIGABRT, Aborted.
0x00007ffff75506ac in __pthread_kill_implementation () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff75506ac in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff74fd6f6 in raise () from /lib64/libc.so.6
#2  0x00007ffff74e6814 in abort () from /lib64/libc.so.6
#3  0x00007ffff754379e in __libc_message () from /lib64/libc.so.6
#4  0x00007ffff755afbc in malloc_printerr () from /lib64/libc.so.6
#5  0x00007ffff755cfdc in _int_free () from /lib64/libc.so.6
#6  0x00007ffff755f9e3 in free () from /lib64/libc.so.6
#7  0x00007ffff67e6558 in clap::AudioBuffer<double>::~AudioBuffer (this=0x512440, 
    __in_chrg=<optimized out>) at .../clap-plugins/plugins/audio-buffer.hh:45
#8  0x00007ffff68113de in clap::VoiceModule::~VoiceModule (this=0x5121c0, 
    __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/modules/voice-module.cc:23
#9  0x00007ffff68114c6 in clap::VoiceModule::~VoiceModule (this=0x5121c0, 
    __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/modules/voice-module.cc:23
#10 0x00007ffff680e082 in std::default_delete<clap::VoiceModule>::operator() (this=0x426af0, 
    __ptr=0x5121c0) at /usr/include/c++/12/bits/unique_ptr.h:95
#11 0x00007ffff680d736 in std::unique_ptr<clap::VoiceModule, std::default_delete<clap::VoiceModule> >::~unique_ptr (this=0x426af0, __in_chrg=<optimized out>)
    at /usr/include/c++/12/bits/unique_ptr.h:396
#12 0x00007ffff680d46b in std::array<std::unique_ptr<clap::VoiceModule, std::default_delete<clap::VoiceModule> >, 8ul>::~array (this=0x426ab8, __in_chrg=<optimized out>)
    at /usr/include/c++/12/array:99
#13 0x00007ffff6810a86 in clap::VoiceExpanderModule::~VoiceExpanderModule (this=0x426a48, 
    __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/modules/voice-expander-module.hh:15
#14 0x00007ffff684bec2 in clap::(anonymous namespace)::SynthModule::~SynthModule (this=0x426a00, 
    __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/plugs/synth/synth.cc:155
#15 0x00007ffff684beea in clap::(anonymous namespace)::SynthModule::~SynthModule (this=0x426a00, 
    __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/plugs/synth/synth.cc:155
#16 0x00007ffff67ffd10 in std::default_delete<clap::Module>::operator() (this=0x42b3a8, __ptr=
    0x426a00) at /usr/include/c++/12/bits/unique_ptr.h:95
#17 0x00007ffff67fd3f4 in std::unique_ptr<clap::Module, std::default_delete<clap::Module> >::~unique_ptr (this=0x42b3a8, __in_chrg=<optimized out>) at /usr/include/c++/12/bits/unique_ptr.h:396
#18 0x00007ffff67f132e in clap::CorePlugin::~CorePlugin (this=0x42a440, __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/core-plugin.cc:42
#19 0x00007ffff684c4ce in clap::Synth::~Synth (this=0x42a440, __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/plugs/synth/synth.hh:6
#20 0x00007ffff684c4f2 in clap::Synth::~Synth (this=0x42a440, __in_chrg=<optimized out>)
    at .../clap-plugins/plugins/plugs/synth/synth.hh:6
#21 0x00007ffff67f734f in clap::helpers::Plugin<(clap::helpers::MisbehaviourHandler)1, (clap::helpers::CheckingLevel)2>::clapDestroy (plugin=0x42a4e0)
    at .../clap-plugins/clap-helpers/include/clap/helpers/plugin.hxx:165
#22 0x0000000000403d92 in clap_test_scan::Impl::close_descriptor() ()
#23 0x0000000000402407 in clap_test_scan::close_descriptor() ()
#24 0x0000000000402923 in clap_test_scan_file(QString const&) ()
#25 0x0000000000402b1e in main ()
(gdb) 

[rncbc]

@baconpaul : looking good your clap-saw-demo synth (see below):

and to no surprise it plays note-on and -offs correctly, I think :) but the GUI doesn't show anything fancy nor activity status at all... is that still in the works or am I missing something again :)

nb. my clap_test_host already implements clap_timer_support and clap_posix_fd_support (otherwise the GUI wouldn't show up :))

[baconpaul]

@rncbc i send a quick email to your email address in your github profile with a question, if yu get a chance. Thanks!

[rncbc]

do i need reply here also?
anyway the answer was yes
😏

[rncbc]

@baconpaul btw, i suspect the clap-saw-demo synth is leaking on dtor somehow, maybe missing to unregister a posix-fd ?

in my clap_test_host (a prototype to qtractor boarding, ntl.) i've forced a cleanup of all registered timers and posix_fds as an ultimate measure on the host side... otherwise it might (and will randomly) crash some time later...

just guessing, on a multi-instance host like qtractor and all the others that matter, it might be a good hint ;)
byee

[baconpaul]

Oh thanks I'll look

[baconpaul]

I see where this FD leak is coming from. It is a bit irritating to fix but I will fix it next day or so. Thank you very much!

[baconpaul]

Oh and I see exactly the same crash as you do with the clap-plugins on linux.

[rncbc]

also btw, like we're at it

is there any officially sane procedure on how to scan for clap plugins, system wide?

to my understanding, it's all still resorting to a file-system scan, instantiating plugins in-process address-space, by loading the shared-objects (aka DLLs) one by one, and grabbing their runtime properties?

is there any other way that i don't know about?
tia.

[rncbc]

q.e.d.

[baconpaul]

Right ha. So you are correct that to get all that info you need an instance. And I guess I’m right to know enough about the plugins to show it exists you do not.

I guess it depends how you structure your daw. If you loaded a clap and it had a different gui state than your scan would you recover? A well formed (but annoying) clap could implement has gui as rand % 10 > 5 on a per instance basis

[rncbc]

mind you, if you look closer to the qtractor plugin inventory listings, it does scan on all that metadata at scan time;
LV2 does it without any interference with the process address-space, being the safest in all regards to my knowledge;
now, CLAP, is just another kid in the block (and fails that long well-regarded safety point) ;)

no worries, I'm still in

[baconpaul]

Oh and the spec strongly suggest that init and deinit are very fast and rely on no external resources. In practice they are noops in the plugins I have written. Which is why I made the mistake of dll -> info is code free, since my paths are just buckets of no op and data structure returns. (I was wrong of course there is code)

[baconpaul]

Yeah we could have designed it so that at least the plugin descriptions weee separate resources but that’s so clumsly on win and lin where bundles are kinda weak. As far as things like params and ports and guis and stuff though that’s a per instance not a per class feature of a clap

[baconpaul]

@rncbc if you grab the latest https://github.com/surge-synthesizer/clap-saw-demo, the FD and timer leaks on linux should be resolved. Curious if you see otherwise. It's a bit tricky and still haven't documented it but will do so this weekend.

[rncbc]

hi @baconpaul , looking good, behaving better :)

one question, is the GUI resizable ?

ps. my test host runs on latest clap v1.0.2,

[rncbc]

@baconpaul oh and I forgot to report an issue with your clap-saw-demo GUI: it crashes the whole show (host included) if you turn the mouse-wheel on any empty (blue) area..

cheers

[baconpaul]

And that's great! I realized a more efficient way I can do the same unsubscribe behavior so I'll take one more turn at it, but really appreciate the confirmation. Also see now FD or Timer leaks in BWS43b6.

And on wheel - ha! Well thanks for that bug report...

the GUI is resizable but only the header and footer resize. So it is resizable in "a demo of resizable UI' sense but not in a "good ui" sense.

All the 1.0.x are of course inter-compatible (they are mostly doc and cmake changes so far, and a couple of variable names in draft extensions). There's a macro which says if your clap is compatible with the target somewhere. I'll pull that to 1.0.2 soon (I had it at 1.0.1 but 1.0.1 had a cmake bug which led to 1.0.2 after I backed down to 1.0.0 :) )

Also it's so great you have this running! Just because a few folks have asked, what does a release process look like for you? Could this be something people could run in QTractor this summer?

Thanks for your patience and collaboration getting this working too.

[rncbc]

hi, just to let you know that some preparations are up in the qtractor front: xclap branch's been setup as a test-bed--currently a stub, but watch out for code about to pour in over the next days :)

cheers

[abique]

This isn't a problem, unless we pass incorrect flags in the note-ports extension.

[baconpaul]

Yeah ok.

Then @rncbc indeed it is intended. Again the spec let’s a plugin choose not to implement midi1 and the clap plugins don’t today.

The saw demo and all the juce plugs (odin dexed surge family) do though

[baconpaul]

I’m surprised surge xt effects doesn’t show up as 4:2 audio and surge xt as 2:6. The fx has a sidechain as does xt and xt has 3 stereo outputs. Are you using activated vs available ports perhaps in your scan?

[rncbc]

well, qtractor don't support sidechains, remember?

[baconpaul]

Oh! I didn't remember that I'm sorry.

Of course SFX and SXT will run fine without them.

[rncbc]

hi, on-going CLAP support in qtractor xclap branch:
plugin scan, instantiation, state load/save, audio and MIDI processing, GUI are all generally working and showing, hopefully;)

a few niceties are still missing like transport info, GUI-to-host parameter updates, MIDI mappings and many other details that I don't quite remember now.

cheers

[rncbc]

parameter changes from the generic UI to plugins are now working; automation should work too (as of rncbc/qtractor@740cffbd)

still missing at this time:

• parameter updates from plugin GUI to host/generic UI;
• transport info updates.

byee

[robbert-vdh]

Awesome! Everything seems to mostly work here! I only noticed that for stepped parameters (and perhaps also other parameters?) the display value and the value shown in the input box are sometimes different: (this happened while modifying the value with the up and down arrows)

And Qtractor seems to SIGABRT when scanning https://github.com/baconpaul/airwin2clap (which exposes ~250 plugins):

qtractor_clap_scan_file("/home/robbert/.clap/airwin-to-clap.clap")
ASSERT failure in QList::at: "index out of range", file /usr/include/qt6/QtCore/qlist.h, line 459

Thread 1 "qtractor" received signal SIGABRT, Aborted.
0x00007ffff42b236c in ?? () from /usr/lib/libc.so.6
>>> bt 10
#0  0x00007ffff42b236c in  () at /usr/lib/libc.so.6
#1  0x00007ffff4262838 in raise () at /usr/lib/libc.so.6
#2  0x00007ffff424c535 in abort () at /usr/lib/libc.so.6
#3  0x00007ffff4feb071 in  () at /usr/lib/libQt6Core.so.6
#4  0x00007ffff4feb3a5 in qt_assert(char const*, char const*, int) () at /usr/lib/libQt6Core.so.6
#5  0x00007ffff4feb468 in  () at /usr/lib/libQt6Core.so.6
#6  0x0000555555815df2 in QList<QString>::at(long long) const (this=0x7fffffff7230, i=8) at /usr/include/qt6/QtCore/qlist.h:459
#7  0x0000555555c4bc9c in qtractorDummyPluginType::qtractorDummyPluginType(QString const&, unsigned long, qtractorPluginType::Hint) (this=0x60e0002e6740, sText=..., iIndex=0, typeHint=qtractorPluginType::Clap) at /home/robbert/Documenten/projecten/forks/qtractor/src/qtractorPluginFactory.cpp:1212
#8  0x0000555555c4c4a1 in qtractorDummyPluginType::createType(QString const&) (sText=...) at /home/robbert/Documenten/projecten/forks/qtractor/src/qtractorPluginFactory.cpp:1244
#9  0x0000555555c49ec9 in qtractorPluginFactory::Scanner::addTypes(QList<QString> const&) (this=0x604000524e90, list=...) at /home/robbert/Documenten/projecten/forks/qtractor/src/qtractorPluginFactory.cpp:1140
(More stack frames follow...)
>>>

[rncbc]

@robbert-vdh:

And Qtractor seems to SIGABRT when scanning https://github.com/baconpaul/airwin2clap (which exposes ~250 plugins):

maybe fixed now with rncbc/qtractor@17be7f81

[robbert-vdh]

Had to manually remove ~/.clap/airwin-to-clap.clap from the blacklist, but it seems to work now!

[rncbc]

parameter updates from plugin GUI to host/generic UI;

crudely done in rncbc/qtractor@e424f240

[rncbc]

hi @baconpaul , @abique et al. one question that is currently blocking me (in addition and clarification to #103):

it boils down on whether and when is a host allowed to call clap_params->flush():
a) when the plugin is deactivated (inactive as in the doc);
b) when the plugin is not processing (as in the doc);
c) when the host/plugin is not in the audio-thread context;
d) all of the above?

it would make sense to me at least that only condition c) is sufficient, so that clap_params->flush() could be deferred to/called in the main-thread idle routine context, as long some request_flush flag is set.

[rncbc]

put it another way: so in any case before the host ever calls clap_params->flush():
a) must deactivate() the plugin;
b) must stop_processing() the plugin;
c) must do it in the main-thread (iow. never call it in the audio-thread);

if all or any of the above but c) is what the documentation is actually telling: then I don't see the use of ever calling flush() besides at initial instantiation or activation (or a restart).

so why would a plugin call a clap_host_params->request_flush() anyway? puzzles me :)

[robbert-vdh]

That's no true. The function can be called:

• From the main thread, if the plugin has been deactivated.
• From the audio thread, if the plugin is still activated but processing has been stopped.

If processing is still happening then parameter changes are flushed as part of the process function. Flushing is so parameters can be synchronized while the plugin is not processing audio. For instance when changing parameters in a GUI.

[rncbc]

ok. thanks for the clarification
I shall proceed my host implementation following your precious hints.
thanks again.

[robbert-vdh]

You're very welcome! Looking forward to trying to finished implementation. :)

[baconpaul]

Also @rncbc we are doing weekly or bi-weekly point updates (1.03, 1.0.4 etc...) clarifying the documentation. If there's things you found hard going, would love to incorporate your feedback into making the spec more approachable and unambiguous.

[rncbc]

@robbert-vdh :

... noticed that for stepped parameters (and perhaps also other parameters?) the display value and the value shown in the input box are sometimes different: (this happened while modifying the value with the up and down arrows)

the display value is now round()'ed as are the spin-box values when in face to stepped parameters (integers in qtractor model); hope rncbc/qtractor@354bc3f fixes it!

[robbert-vdh]

They should be floored/truncated instead of rounded. As in, if you have a stepped parameter with a value of 1.99, then that counts as an integer value 1.

(I have not yet tried this commit though!)

[rncbc]

ok. just reverted to truncf() in the origin (host), rncbc/qtractor@f9d5819d6

on the other news:

transport info is also in place already, but only with seconds-timeline info for the time being
although current tempo (bpm) and time-signature are being there reported, I have serious doubts about the whole beats timeline... but not so troublesome as spotted by #114 :)

[rncbc]

hello all,

The good news are: Qtractor CLAP support is almost ready to merge into develop/master and make it into the nightly snapshots, OBS and Launchpad repos.

The not so good, but ain't so bad either, are: there's still one thing that bugs me down however: plugin restart, params rescan/clear and what not; are there any (current) CLAP plugin out there that uses or needs this anyhow for the testing?

cheers

ps. take notice once the merge is effective, the xclap branch will get deleted and commits will get squashed, meaning that all hashes posted in this discussion will go into oblivion forevermore. thanks

pps. UPDATE: it is done: qtractor >= 0.9.26.45git.456f88 (master/develop) has CLAP support already. enjoy!

[baconpaul]

I don’t know if any plugins that use that today. We’ve been talking about writing stress test plugins for exactly this reason but have not yet

[baconpaul]

Also congratulations!! That’s awesome!

[rncbc]

hi again,

now for a different matter: asking whether CLAP does support or indeed have an interface or extension to list and select banks and programs (or presets) eg. via MIDI bank_select + program_change mapping, somehow?

not wishing to pesk anyone about this, but VST2,3 does have one of a kind and both have been implemented in qtractor for quite some time.

has this been oversighted or is there already something equivalent and I missed it?

should a new discussion be started on this subject or is it not going to happen ever or so soon?

[baconpaul]

So plugins can choose to respond to midi program changes however they want of course since it is just a message, but no, we shipped without any extensions to do things like advertise all your presets. A discussion on that would be great.

I think the rough view is that program change works but the other ideas that, say, vst3 has have proven really hard going on devs, but we don’t have an answer in then1.0 extension set

[robbert-vdh]

The main reason for not having any extensions for VST2-style programs is that they are simply not very flexible. They're almost always short, hardcoded lists of presets. Those programs work fine for General MIDI-style instruments without a GUI, but modern plugins tend to have their own preset browser with support for metadata and the ability to save your own presets. A CLAP extension that allows the host to access and interact with those presets is likely going to be much more useful than oldschool program lists.

[rncbc]

VST3 have it also and please don't confuse "presets" with "programs" : the former (a preset) is generally regarded as a plugin state, represented in a POD (blob) format that only the plugin understands... while the later (programs) should be exposed as a list of addressable plugin settings (via MIDI channel bank_select+program_change messages) that might or not map N:1 to presets (note N>=1, so one preset might expose a single or even a multiple set of so called "programs").

oh, and programs are read-only from the host pov: you may read the list of programs, select the current program, or get notified when changes are done under the plugin's premises--you don't really edit it whatsoever.

[rncbc]

so given the above, all "programs" related cruft is now scrapped from qtractor as a CLAP host ;)

thanks

[rncbc]

one another question re. note-name extension, which is already supported in qtractor: the question is: should it be inferred that, when a plugin provides any note-names, then it's a drums or percussion instrument, with different or non-harmonic/non-chromatic/atonal voicing per key, or in other words, it's a non-melodic preset perhaps?

thanks in advance.

[robbert-vdh]

No, the only thing you can infer from the plugin providing note names is that it assigns names (don't even need to be semantically relevant) to notes. You can check if the plugin has the CLAP_PLUGIN_FEATURE_DRUM_MACHINE feature, but there's obviously no hard requirement for plugins to add these features to their features list.

[baconpaul]

Yeah for instance we may want to re-assign note names for non-12-note scale tunings one day in surge, since there’s relatively good names for some scales, and also we can label the scale roots at least. And that would definitely be harmonic/melodic. (We have not done any of this yet but just giving an example)

[rncbc]

ok. thanks, no further questions :)

[abique]

You could rely upon the features in the plugin descriptor for that?
You could have a multi-sampler that provides note names.

[abique]

Ah Robbert already replied!

[rncbc]

just to let you know

Qtractor 0.9.27 is out!
guess is an absolute first on the free/open-source arena :)

cheers

[baconpaul]

Yes you are the first open source shipping clap daw! Congratulations! And thanks for working through things with us.

[baconpaul]

Oh looks like anklang will be close behind though - some really great progress there too!