I’ll let you know when I find pub/sub in assembler. ![]()
Would you prefer a version written in hard core c++ larded with template bloat from boost to avoid leaks? I will admit that garbage collection would kill a quasi realtime app like GP.
I’ll let you know when I find pub/sub in assembler. ![]()
Would you prefer a version written in hard core c++ larded with template bloat from boost to avoid leaks? I will admit that garbage collection would kill a quasi realtime app like GP.
Would you prefer a version written in hard core c++ larded with template bloat from boost to avoid leaks?
No - we would prefer to continue using the notification system that we already developed in C++ that works extremely well with our quasi realtime app!
The thing is, the underlying problem has nothing to do with the existence or not of a notification system. It has to do with the way the plugin API works. When you change a parameter in a plugin editor, the plugin notifies the host and all widgets mapped to that parameter will be notified and that’s extremely efficient. However, if you change a plugin parameter from the host (whether it’s a widget, GP Script, the PSD, whatever), the plugin generally does not notify the host which is why other widgets mapped to the same parameter aren’t notified.
Most likely the proper solution is to intercept the calls to the VST API that is used to set plugin parameters and then “fake” a notification back to the host where widgets are already “listening” for changes on specific parameters.
hard core c++
I’ve been writing programs for 36 years. Started with Basic, Quick Basic, then C, then Visual Basic, ALGOL and more C, then C#, java. And now for the last 5 years C++. In my opinion C++ is not very hard. You need to pay attention to details, yes, but interfacing in C# with C/C++ (for example for using low-level MIDI) isn’t easier: lots of marshaling, especially if you want callbacks from C/C++ flowing back to C#.
I think you can make a mess of your code using any language.
To be honest: I avoided C++ a long time because I thought it to be too complicated, but now I’ve seen the light ![]()
My € 0.02
Btw: Rust is on the bucket list
Gotcha beat at 53 years, buddy. I learned basic in eighth grade in 1972, PL/I in 1975 (I think). Yes, Virginia, there were computers back then that didn’t use vacuum tube flipflops. I started writing C++ back when it was only a C preprocessor and the standard template library was a research project at Stanford and HP.
The explicit memory ownership of everything for safety in rust is very attractive, though the code ends up looking like **** to me.
The explicit memory ownership of everything for safety in rust is very attractive
Maybe - I’ve looked at Rust - it’s a horrible language from a Knuth perspective (think literate programming) I would have preferred it if they had leveraged the syntax of a language like Pascal and extended it.
Everyone is trying to take bits of Haskell (that Optional concept that we are starting to see everywhere came out of the Maybe type in Haskell) but these days modern versions of C++ have such things as unique pointers and optional as well so it’s no longer clear (at least to me) that Rust really buys one much.
Functional programming seems like the safest model but it’s very difficult and slow!
PL/I
PL/1 showed up in the late 60s — what was really hilarious was the Cornell version called PL/C into which you could throw almost anything and still get a syntactically correct (compilable) program.
when it was only a C preprocessor
Are you talking about CFront or just C with classes?
Gotcha beat at 53 years, buddy.
Impressive. I didn’t mean to start a contest
, just that I used a lot of languages.
Almost certainly CFront, around 1988. Also learned Smalltalk around that time with a coworker. Two others took an Eiffel class. Professional life was mostly Fortran up until then.
No contest or slight intended, Frank.
Speaking of being impressed, I’m impressed with my new assistant that has read a lot more technical and API documentation than I, and takes being kicked in stride and never complains! It writes a lot of code that I have to rework–or ask it to reorganize, which is often a lot more than refactoring–but it usually produces bug-free code. All told, I think our little team is 5x more productive than me alone.