About CLAP

[baconpaul]

<grr kvr is hard to use>

[elnn]

This is entirely possible with CLAP and how Surge implements polyphonic modulation. Basically there's two ways you can address a voice "PCK" (port channel key)" which is tied to a midi key and "note id" which is not. The Host has to provide unique note ids to the synth, and the synth terminates them.

The difference is in cases with long releases where you still want individual modulators per voice with repeated keys and you don't want to rotate channels or want polyphony higher than 16.

It's not easy going from PCK to note id. Surge had some internal structure which made it simpler than other synths. But if you use surge with the modulators your voice lifetime is as long as your release, and a second voice on the same key starts a fresh set of modulators.

I'm glad to hear that.

I've a question that, I believe, relates to possible voice architectures in general.
Might that mean that rather than the host modifying a singleton plugin-state array, CLAP effectively makes it possible to carry a state-array by voice/note id?

Let me add that the beauty of the concept is that developers like us can gradually upgrade their paradigms. I see Parameter Modulation and MPE as a stepping stone to Polyphonic Parameter Modulation based on PCK, which in itself is a step towards support for NoteIDs. Once NoteIDs are established *and* Parameter Modulation, one can support NoteExpressions in CLAP, and eventually in VST3 as well. At least, this is how it could work for us.

It's interesting to see how detailed and organized you are about the roadmap of your work. I wonder if it comes with practice, skill, genes, or just general Germanhood.

[baconpaul]

I've a question that, I believe, relates to possible voice architectures in general.
Might that mean that rather than the host modifying a singleton plugin-state array, CLAP effectively makes it possible to carry a state-array by voice/note id?

Sort of yeah. A more accurate way to think about it is clap is an event processor. “Note” like events come with coordinates which are the address of the note. So a modulation with note -1 is global and a modulation with note x applies just to note x. Add on a few more events to coordinate notes (especially a plugin to host note end event) and you get the result you are thinking of, just through a different mechanism

[elnn]

I've a question that, I believe, relates to possible voice architectures in general.
Might that mean that rather than the host modifying a singleton plugin-state array, CLAP effectively makes it possible to carry a state-array by voice/note id?

Sort of yeah. A more accurate way to think about it is clap is an event processor. “Note” like events come with coordinates which are the address of the note. So a modulation with note -1 is global and a modulation with note x applies just to note x. Add on a few more events to coordinate notes (especially a plugin to host note end event) and you get the result you are thinking of, just through a different mechanism

I see, that's great and exciting.

ah,
so the polyphonic magic is conjured by the fact that instead of simple event messages in one direction of host->plugin we get event ports with some bi-directionality for each note id. It feels coherent!

Though I'm not sure I understand the intended difference between param_value and _mod.

[baconpaul]

Thats exactly right

Param value vs mod. Short version is value is like dragging the slider and mod is another channel to non destructively change the value in the engine. Kinda like an lfo in your synth doesn’t actually wiggle the target knob.

So parameters have two amounts - their value, a permanent saved value updating the ui, and their modulation, a transient additive value which changes the engine but not the patch

[syntonica]

[u-u-u]

Bitwig recently started to allow feedback in it's internal routing with 1 sample delay.
And it's factory delay and reverb devices allow for inserting other devices/plugins in the feedback path, so I'd say the standard is in good hands if there is a solution at all

I think this is just wrong. The Bitwig 4.3 changelog says "one audio buffer" delay for send feedback routing. So such feedback routings have to be used with care.

1 sample feedback routing on plugin or internal device level is unrealistic from a technical point of view. To do some sort of modular 1 sample feedback path structure, a new 'dsp plugin format' would be required. Maybe a Grid module that can contain multiple of those feedback modules which could be routed inside that module. The Grid module then would compile and optimize its internal module structure into something that can be processed efficiently. (some sort of simplified Reaktor Core)

[ThomasHelzle]

Sorry, that was a typo - I intended to write buffer, not sample. Thanks for the correction.

Bitwigs Grid presets actually get re-compiled for the current processor. Not sure if it's just on my older CPU, but when I switch presets, I get the on-the-fly-compiling flyout.
Graphics tools do that for a long time (recompiling the whole node tree I mean)...

The "Long Delay" inside the Grid (that allows for feedback) has a minimum of 0.02ms, but you can't put plugins into it's path directly.

Interesting times

[Burrito Whisperer]

A new plug-in format... Sounds terrifying and exhilarating at the same time. I was forced to switch from windows to mac a few months ago for school and the m1 problem has been exhausting, but going over just some off the benefits clap brings seems like a move in the right direction. Really hoping Ableton isn't last to the party if this catches on.

[u-u-u]

When the GPU Audio developer starts talking about CLAP, he gets really excited :

(at about 33:30)

[kunzs]

I'm not a dsp developer but I asume that every plugin format has some sort of mechanism for the plugins to report a list of their controllable parameters to the plugin host.

Will there also be the possibility for a plugin to report the list of parameters in some kind of organized way? For example in groups of 8? This would fit perfectly into the remote controls approach of hosts like Bitwig and Ableton.

Right now if I want to change plugin parameters on my Ableton Push (used with Bitwig) I'd have to map out the controls into device pages by myself.

I think this would be awesome and could help to glue plugins more to the UX of the host (including hardware controllers)

[baconpaul]

Params in clap have a path so are groupable

There is indeed a quick controls draft extension (but it is still a draft I believe) allowing a plugin to advertise control pages to things like logic quick controls or what not. I need to check if this is out of draft but even if so I am unsure of the implementation status

[kunzs]

Params in clap have a path so are groupable

There is indeed a quick controls draft extension (but it is still a draft I believe) allowing a plugin to advertise control pages to things like logic quick controls or what not. I need to check if this is out of draft but even if so I am unsure of the implementation status

That sounds awesome! Thank you for the fast reply!

[BlindMusician]

Dear u-he (and others discussing about CLAP),
I tried to contact the person responsible for the CLAP standard (Mr. Urs Heckmann from Heckmann Audio GmbH) but did not receive any answer to my suggestions related to the including of the accessibility requirements to the CLAP standard. I would like to say that, because of this, I have attached the message below (in quotes) that I sent to the contact address of CLAP standard:
"Dear CLever Audio Plugin Personnel (again),
I am Juho Tuomainen and would like to remind you that I have not
received a message from you in response to my message which I sent on
Monday, October 3rd, 2022, at 9:32 UTC+3.00, dealing with the
suggestion of including the mandatory accessibility requirements to
the CLAP standard before the Music Accessibility Standard would be
released (i.e. first stable version would be ready to use). Even
though this is not an urgent message, I would want to hear your
thoughts on how we would put the accessibility requirements to the
standard. I would like to clarify that I do not currently have
knowledge on working on standards like this but I have a student
account (GitHub profile name is juhotuomainen) and (possibly) I would
continue the work with the standard after the student status expires
(in November 2023) and, if you kindly joined me to the development
resources before that, I would at least provide some textual
information of the accessibility in general, so we would figure it out
on the side of CLAP standard to make it the first accessible music
software standard ever! Finally, in addition to this (stated in the
previous sentences), all the repositories I have joined to (and which
are not associated with my current school like the CLAP repository)
would be usable for me after the student status of my account expires.
For your convenience, my previous message is below these lines.
Yours faithfully,
Juho Tuomainen
2022-10-03 9:32 UTC+03.00, Juho Tuomainen <juho.tuomainen1@gmail.com> wrote:
Dear CLever Audio Plugin Personnel (and Mr. Heckmann),
I am Juho Tuomainen, a 24-year-old ICT (Barchelor of Business
Administration) student and doing my internship right now at the
Valteri school (and its Onerva school for the blind, visually impaired
and people with mental disabilities). I would like to tell you that
currently, there is no accessibility standard in the music industry
(dealing with the accessibility of digital music software and
hardware, and also other music products), which is contrary to the web
world with recommendations (and, actually, standards) Web Content
Accessibility Guidelines (WCAG), and Web Accessibility Initiative
Accessible Rich Internet Applications (WAAI-ARIA or ARIA). Because of
the lack of the accessibility standard in the music industry (and also
in the music tech industry), a common standaard, requiring the
accessibility as a mandatory requirement, in addition to other
software or any music-related product development lifecycle, would
only ensure that all the future products would have accessibility
requirements out-of-the-box and the existing products would have a
mandatory accessibility plan on improving the accessibility to the
fullest possible extend. This would apply to the entire software,
hardware and the music product field regardless whether the products
where open source, closed source, free or commercial. I would like to
clarify that I have been using (more or less) keyboards and virtual
instruments over 17 years, from which about 11 or 10 years I have used
the virtual instruments. Unfortunately, my practical experience is
that I still do not have full (100 %) access to the same features as
my sighted counterparts because the number of visually-impaired prson
is smaller compared to the sighted population. However, despite this
fact, the Way I see it, it does not excuse any developer in fleeing
the situation (i.e. from not doing accessible plugins for the
disabled, blind and visually impaired community). For this reason, the
CLever Audio Plugin standard would have mandatory accessibility
requirements integrated into it so that all the current (and future)
CLAP plugins would have mandatory accessibility features in them.
Furthermore, a wider standard covering the accessibility in the music
industry (called "Music Accessibility Standard (MAS") would also be
implemented in parallel to the CLAP standard. In this way, the
standards such as CLAP and VST would automatically use the Music
Accessibility Standard. However, since Music Accessibility Standard is
not yet generated or even stable version of it is not publicly
released, the accessibility requirements would be integrated to the
CLAP and, when the Music Accessibility Standard (MAS) 1.0 would be
ready, a link to the latest standard (updated when a new version would
be released) would be added to the CLAP developer documantetion. In
this way, in the end, all the standards, regardless of their
developers and whether they are open or closed source ones, would have
mandatory accessibility requirements. A benefit of this approach
currently in LAP (and later the benefit of Music Accessibility
Standard) would also generate more revenues to the companies (when
making commercial plugins) compared to the situation where the plugins
would only be purchased by sighteed users. Even though the number of
the disabled (and blind andn visually impaired) people is smaller
compared to the non-disabled community, the lack of accessibility
features, especially these days, would (in the worst case) lead to the
situations where some sighted individuals (or even schools,
institutions or other organizations like conservatoires) would not buy
the products if they did not see any accessibility-related information
on the products or on the web sites of the plugin manufacturers, since
the accessibility awareness in these institutions is, in the big
picture, gradually but steadily increasing all the time. In order to
ensure the maximum financial benefit (and a loyal customer base), any
company developing music hardware, software or releasing other
music-related products must have the accessibility features in their
products. Finally, the way I see it, before the MAS is released, the
CLAP standard would be a good place for including accessibility
requirements to it. What's more, it would put pressure to the other
companies (like Steinberg Media Technologies GmbH) to also start
implementing their accessibility features on CLAP plugins (and,
perhaps some other plugins like VST plugins) proacbitely or including
the accessibility features to the already-existing products.
Because of all the facts stated in the previous chapter, I would be
very interested in taking part into the creation of the Music
Accessibility Standard, and also follow the evolution of CLever Audio
Plugin standard in the years to come. To read more about my thoughts
about the standard (MAS), and also read possible suggestions on
interested parties, please goto the following address (or copy it to
the web browser's address bar):
viewtopic.php?p=8378671&utm_source=my_l ... nt=8378671
And, as always, please pass this information, together with the link
above, to your community at KVR, your CLAP partners and any other
companies you think might benefit from this standard (since I do not
currently  have networks that are as wide (person-wise) as yours).
However, please note that since I am currently a student, I am not
able to put as much time to the Music Accessibility Standard (or the
CLAP standard) as I personally want (most likely, this changes after
the intership is over aroud January 12th, 2023).
Yours sincerely,
Juho Tuomainen"
Kind regards,
Juho Tuomainen

[baconpaul]

Hello!

As you may know I’ve done quite a bit of work on both accesibility and clap.

The answer to your question in short is that clap is at a lower level of programming than accessibility apis. It is basically silent on the gui except for the fact that you receive an hwnd etc into which to render.

The parameters and so forth all use well documented fields in utf8 strings for all their names and paths which would allow accessible daws to expose them.

So while I think accesibility is critically important, the point in the api stack where clap participates means it has no opinion on the matter; it is simply at a level below the accesibility apis

Hope this helps