cppwin32 VS pure-data

I would imagine something like https://github.com/microsoft/cppwin32 would maybe be an easier way forward for that?

no, Microsoft has rewritten the windows API in C++ I think https://github.com/microsoft/cppwin32

An official work in progress Windows binding, still far behind of what C# existing bindings are capable of, or legacy toolkits like MFC.

Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it.

[0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making...

[1] - https://github.com/microsoft/cppwin32

If you want to use the old tooling, your C++ is going to be very "C with classes," and it's going to use a lot of weird datatypes that don't feel very C++ at all. Microsoft had a project for wrapping the Windows API in idiomatic C++, but appear to have abandoned it. If you choose to go down this road, Charles Petzold's Programming Windows is the book to get. Yes, it's 25 years old, but all the new stuff is just new COM controls (which you can look up in the API documentation)--the fundamentals of making a Windows API program work seriously have not changed.

Even Rust has a native projection of the windows API (which is actually pretty usable). This projection has the same roots as the C++ projection mentioned by u/amnesiac0x07C5. So I don't believe macros are a blocker here.

See : https://github.com/microsoft/cppwin32

Microsoft have recently put decent effort into making the Windows APIs more accessible to C++ users. One of these efforts is called C++/WinRT, and it specifically targets applications intended for "modern" Windows (Windows 8 and later). There's another effort underway at Microsoft for making the older Win32 API more C++-friendly, but it isn't documented nearly as well.

There is a similar project for C++, but it sadly seems to be dead already. The last commit was one year ago.

not that hard to wrap windows.h and undef the annoying stuff, and only a handful of files in your codebase will include it anyway. on the other hand stuff like this looks extremely worse and exactly like the kind of c++ that is hard banned in gamedev codebases

They are, actually, it's linked from the article: https://github.com/microsoft/cppwin32

Report bugs on the pd github https://github.com/pure-data/pure-data

You might be interested in clicking through the puredata source code.

https://github.com/pure-data/pure-data

> The other advantage is because these things were implemented in the 80s

Pd was developed in the mid 90s

> they are very computationally efficient

Not as efficient as it could be, though. For example, instead of proper SIMD instructions, the DSP perform routines only use manual loop unrolling, praying that the compiler will auto-vectorize it.

Finally, everything is single-threaded, leaving lots of performance on the table. FWIW, I have a PR for an asynchronous task API (https://github.com/pure-data/pure-data/pull/1357) and also a branch for multi-threaded DSP (https://github.com/Spacechild1/pure-data/tree/multi-threadin...).

> Any criticism or unwelcome suggestions are treated as an insult to Miller Puckette and the proponent is attacked, ignored, or advised to implement it themselves (ie to go away and not come back).

I don't think this holds for the general case, but there a certainly a few users caught up in Stockholm Syndrome :-) I can assure you that the developer team (which I am a part of) is very well aware of Pd's limitations and problems. Pd has seen quite significant UX improvements over the last few years, but the pace of development is very slow. Anyway, if you have specific criticism, suggestions or feature requests, feel free to open a ticket on GitHub: https://github.com/pure-data/pure-data.

As a side note, the minimalistic GUI itself won't change since it is an intentional design decision by Miller, but there is some effort to abstract the core/GUI communication to allow alternative GUI implementations. (Personally, I really dislike the current Tcl/Tk GUI - not because it's minimalistic, but because it's slow and buggy.)

> and idiosyncratic terminology (eg PD refers to module connectors as 'patch cords' just like on an analog modular synthesizer or mixer, but what synth people commonly call a pulse or a trigger is a 'bang' in PD).

Pd's 'bang' belongs to the control/event domain, you can't really compare it to trigger/pulse in modular synthesizers. (FWIW, there are several Pd externals that implement audio-rate triggers.)

> You can make it do anything, but unless you already have a very specific goals you will spend most of the time reinventing wheels in parameter space.

That's a fair point. It's important for people to understand that Pd vanilla is really a programming environment with only a minimal set of built-in objects that allow you to build higher-level abstractions. You definitely need a set of "abstractions" or libraries to be productive. Fortunately, there are many existing Pd libraries and they can be easily installed with Pd's package manager "Deken". The most extensive one is "ELSE" with nearly 500 objects, containing everything from band-limited ocillators, filters, sequencers, GUIs, etc. Personally, I have my own collection of abstractions that I made over the last years.

That being said, I would agree that you should always pick the right tool for the job. Just as you wouldn't write your website in C, you wouldn't pick Pd for typical EDM stuff (unless you have a very good reason). But for prototyping and experimental electronics it's a fantastic tool, I think.