CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[Super Piano Hater 64]

Actually, C++ compilers of the past used to convert C++ code to pure C before the compilation starts. If they were "completely" different, that wouldn't have been possible.

Converting code from one language into another is the same thing as compilation.

[S0lo]

I wouldn't say "completely". But yes they differ allot. Still, most of C code can compile perfectly in C++. Infact, the ++ in C++ was named to mean "one step ahead of C". Actually, C++ compilers of the past used to convert C++ code to pure C before the compilation starts. If they were "completely" different, that wouldn't have been possible.

That was during the time when C++ was mostly considered to be 'C with classes', but C++20 is a completely different language compared to that. Yes you can write C (or mostly write C, a couple things are not supported in C++, like type punning) and compile it with a C++ compiler,

I don’t think I’ve said otherwise. But still even C++20 is not really “completely” different. I’d say more like “further away”.

but at that point you'd just be making things difficult for yourself.

That depends on “who” and “what”. I’ve seen things done with C++ that are far more confusing to people than when done in plain C. And yes, I’ve been a C++ teacher for a few years before.

[S0lo]

Converting code from one language into another is the same thing as compilation.

Yes, yet they did C++ to C to machine code instead of C++ to machine code at the time. Probably because it was easier or at least more convenient. Hence not “completely” different

[Super Piano Hater 64]

Converting code from one language into another is the same thing as compilation.

Yes, yet they did C++ to C to machine code instead of C++ to machine code at the time. Probably because it was easier or at least more convenient. Hence not “completely” different

Compiling via C does not make the source language similar to C. Lots of languages do this without being particularly C-like. I can sit down and write a program to read HQ9+ source code and output C, but it would be ridiculous to try to use it to illustrate an alleged similarity between HQ9+ and C. Nobody would listen to that nonsense.

C++ is certainly more C-like than HQ9+, but these similarities have nothing to do with the way any of them is compiled. It's a non sequitur and it only serves to confuse people about what a compiler does.

[S0lo]

C++ is certainly more C-like than HQ9+,

Made my point

but these similarities have nothing to do with the way any of them is compiled.

One could easily call that “nonsense” because of the phrase “nothing to do”.

[mystran]

The mental model you should use when writing modern C++ is completely different from the mental model you would use when writing C. This is what makes the two languages "completely different languages" even though there is indeed an intersection in language syntax that is large enough that it is possible to write code that compiles as either (and generally also works as long as no exceptions are thrown).

This is why I'd suggest just learning modern C++ directly if you plan on learning C++ because that way you don't need to unlearn the mental model you would use when writing C... but we should really take this into forum 33 as it's kinda off-topic here.

[S0lo]

Definitely not just the syntax that is the intersection, but more also the semantics behind pointers, pointer operators, multidimensional arrays, pointers to pointers, pointer to functions, casting and memory allocation. Many young C++ devs don't know how memory internally works because they're too busy trying to understand the STL/STD. (now you could rightfully argue that they don't have to). The matter is controversial. Check the following, but read ALL the answers including the replies.

https://stackoverflow.com/questions/598 ... learning-c
https://www.quora.com/Which-one-should- ... t-C-or-C++

but we should really take this into forum 33 as it's kinda off-topic here.

Yes

[Super Piano Hater 64]

but we should really take this into forum 33 as it's kinda off-topic here.

Yes

Looking forward to that. I went ahead and wrote that compiler I mentioned, just in case.

Code: Select all

#!/usr/bin/env python3

import argparse

TRANSLATIONS = {
    'h': 'puts("Hello, world");',
    'q': 'puts(SOURCE);',
    '9': 'lyrics();',
    '+': 'a++;',
}

INDENT = '    '

def c_escape(s):
    def escape(b):
        if b in (ord("\\"), ord('"')) or b < 32 or b >= 127:
            return '\\%03o' % b
        return chr(b)

    return '"' + ''.join([escape(b) for b in s.encode(errors='ignore')]) + '"'

def compile(path):
    source_lines = []
    body = []

    with open(path) as f:
        for s in f:
            for c in s:
                if c in TRANSLATIONS:
                    body.append(TRANSLATIONS[c])
            source_lines.append(s)

    print('#include <stdio.h>')

    source = c_escape('\n'.join(source_lines))
    print("const char SOURCE[] = " + source + ';')

    print(LYRICS)

    print("int main(int argc, const char*argv[]) {")

    print(INDENT + 'unsigned long a = 0;')

    for line in body:
        print(INDENT + line)

    print(INDENT + 'return 0;')

    print("}")

LYRICS = r"""
const char *TENS[10] = {
    "",
    "Ten",
    "Twenty",
    "Thirty",
    "Forty",
    "Fifty",
    "Sixty",
    "Seventy",
    "Eighty",
    "Ninety"
};

const char *ONES[10] = {
    "",
    "-one",
    "-two",
    "-three",
    "-four",
    "-five",
    "-six",
    "-seven",
    "-eight",
    "-nine"
};

const char *BOTH[20] = {
    "No more",
    "One",
    "Two",
    "Three",
    "Four",
    "Five",
    "Six",
    "Seven",
    "Eight",
    "Nine",
    "Ten",
    "Eleven",
    "Twelve",
    "Thirteen",
    "Fourteen",
    "Fifteen",
    "Sixteen",
    "Seventeen",
    "Eighteen",
    "Nineteen"
};

const char *SINGULAR = "bottle of beer";
const char *PLURAL = "bottles of beer";

void bottles(unsigned int count, const char *location) {
    if (count < 20) {
        printf("%s", BOTH[count]);
    } else {
        printf("%s%s", TENS[count / 10], ONES[count % 10]);
    }

    printf(" %s ", count == 1 ? SINGULAR : PLURAL);

    printf("%s\n", location);
}

void lyrics() {
    unsigned int count = 99;

    while (count > 0) {
        if (count < 99) {
            puts("");
        }

        bottles(count, "on the wall");
        bottles(count, "");
        count--;
        puts("Take one down");
        puts("Pass it around");
        bottles(count, "on the wall");
    }
}
"""

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Compile HQ9+ to C')
    parser.add_argument('filename', metavar='<source>')

    args = parser.parse_args()

    compile(args.filename)

[moss]

My sum up of what happened during the first 3 weeks since the announcement:
https://www.youtube.com/watch?v=C0ne2scK3wA

[Enrize]

I really wish KORG jump on board as well. Can't wait to use Opsix and Wavestate Native with voice stacking and polyphonic modulation.

Any chance to negotiate with them about it?

[EvilDragon]

Korg will be slow about it. Plus they use JUCE so it's a bit more work to support those CLAP features.

[Enrize]

Does improved multi-core support also works on Apple M1/M2 (ARM) chips? Or it only improves x86 arch?

[PieBerger]

Does improved multi-core support also works on Apple M1/M2 (ARM) chips? Or it only improves x86 arch?

Works great on my M1 Air. Duplicating the same 12 voice Diva patch (in divine mode), I can run 25% more instances with multi-core enabled vs the VST3.

[DJMaytag]

Regarding Reason Studios, we would love to talk to them, but nobody has any contact and whatever official email addresses some of us have tried seem to have gone into the void. Maybe Reason users should talk to them and their execs and devs can contact us through cleveraudio.org

I think CLAP makes a lot of sense for DAWs regardless of current adoption because it's immediately a superset of any features they'd ever wish to support. All other formats can easily be wrapped to a subset of CLAP. Best part of such a strategy is that those wrappers are being developed in open source projects already: I just had a screenshot of a VST2 running as CLAP in my mailbox.

Just saw this, linked from ReasonTalk forums. If I had a winning strategy here, it would be getting Ableton on board with CLAP as the #1 goal, and Reason a close #2. As much as I would love to see Reason ditch their VST3 efforts and implement CLAP, I think the biggest breakthrough in adoption of CLAP would be getting Ableton to support it.

I wouldn't be holding my breath on Steinberg, Avid, or Apple opening things up to CLAP unless every other major DAW developer but those three were CLAP friendly. I'm not a dev, but I understand there's enough ire at Steinberg over the VST3 transition, that they could be very vulnerable to a lot of people ditching developing VST's in favor of CLAP, if there were enough hosts supporting it.

[Funkybot's Evil Twin]

I wouldn't be holding my breath on Steinberg, Avid, or Apple opening things up to CLAP unless every other major DAW developer but those three were CLAP friendly.

Avid is on board and were part of the original CLAP announcement.

From a major host perspective, it sounds like CLAP will exist in Bitwig, Reaper, Studio One, and Pro Tools in the future. And that's just based on who has said they were on board with CLAP. I'm sure some others are considering it behind the scenes or taking a wait and see approach. But yeah, I'm not expecting Steiny to adopt CLAP any time soon.