Does this help?
What is important to understand, is that there is no garbage collector in Pascal (in Pascal, we destroy what we've created). So, the use of abstraction is more "natural" than the use of interfaces in Pascal.
You can have a look at this discussion, about using the interfaces in a Pascal context: https://forum.lazarus.freepascal.org/index.php/topic,46181.msg328478.html#msg328478 (https://forum.lazarus.freepascal.org/index.php/topic,46181.msg328478.html#msg328478) .
It's should be mentioned, that the variable "a" is a reference to the instance only. So the below is legit code.
var a:THello; { b:TWorld; } begin a:=THello.Create; writeln(a.WhoAmI); a.free; a:=TWorld.Create; { <-this was my question here } writeln(b.WhoAmI); a.free;
Thanks for the reply, but I'm really unsure why GC is relevant here. In C++, I new/delete and in Pascal, it looks like it'll be Create/Free.
Thanks for the reply, but I'm really unsure why GC is relevant here. In C++, I new/delete and in Pascal, it looks like it'll be Create/Free.
Probably because the most used form of interfaces is reference counted. ("smart pointer").
My first project will be porting over my VST plugin from C++ for both Mac and Windows and there are a few changes I want to make at the very core that depend on polymorphism. And I have to say, the ability to cross-compile might mean I onlyI actually did quite a lot of VST programming in Pascal (the first Pascal VST host was written by me and subs. improved by TobyBear and Christian, I also translated FreeVerb3 by Yezar to Pascal and quite a bit more original ones) so Yes, VST plugins and hosts are perfectly feasible. Christian wrote a very nice framework for it, based on my and subs. TobyBear's work. Also note some of the people from FL studio independently did the same thing: Fruity loops was basically written in Delphi and some of the original programmers are forum members. As is Christian.
by TobyBear
So for sure, VST questions can be answered here as long as they are Pascal related.
I've got his VST 2.3 SDK Pascal translation lying around here somewhere. I'll have to update it to 2.4, but most of the heavy lifting is done.That's already done. Even the latest SDK is already translated /flattened to Pascal. Important for synth plugins. Effects are perfectly OK in lower versions. Note the newer versions seem to be slower, more hardware demanding.
My Google Fu must be lacking, as I had to scrape to get the 2.3 version.... :) Can you point me in the right direction?I've got his VST 2.3 SDK Pascal translation lying around here somewhere. I'll have to update it to 2.4, but most of the heavy lifting is done.That's already done. Even the latest SDK is already translated /flattened to Pascal. Important for synth plugins. Effects are perfectly OK in lower versions. Note the newer versions seem to be slower, more hardware demanding.
And I forgot the mention Frederic VanMol, who did the first translation for the VST client SDK and upon his work everything else is based. (But he worked/works for FL Studio) And I did the first host.
Probably because the most used form of interfaces is reference counted. ("smart pointer").
Oh! Okay! I was hoping I wasn't missing anything and it looks like I was, sort of. I'll have to watch out for that since I prefer malloc/free over RC.
If it's a success, I will definitely share the unit and it will be my contribution to putting another stake in the heart of Carbon. If it had been written in anything other than Pascal, wouldn't we all be Cocoaized by now?
My first project will be porting over my VST plugin from C++ for both Mac and WindowsThere is pl_AsioVST package which you can install via OPM which can help you to create VST plugins or ASIO applications. There are many included built in filters to built effects without much DSP knowledge. I am not quite sure, but I think it's only for Windows. It's a Lazarus port of this Delphi package: https://sourceforge.net/projects/delphiasiovst/
Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)More true than you think. Adobe were probably still sore about having to move from 68k to PPC! Plus, the whole "Apple killed my Flash Player!" thing probably didn't help much.
p.s. the cloud thing is a joke, I don't think that is related to cocoa.
Thanks! I'll check it out!My first project will be porting over my VST plugin from C++ for both Mac and WindowsThere is pl_AsioVST package which you can install via OPM which can help you to create VST plugins or ASIO applications. There are many included built in filters to built effects without much DSP knowledge. I am not quite sure, but I think it's only for Windows. It's a Lazarus port of this Delphi package: https://sourceforge.net/projects/delphiasiovst/
Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)More true than you think. Adobe were probably still sore about having to move from 68k to PPC! Plus, the whole "Apple killed my Flash Player!" thing probably didn't help much.
I did poke around in the LCL, but it doesn't have what I need. My GUI is fully drawn with my own widgets and interface. I need to open a window, draw on it and catch mouse and keyboard action and that's about it. My Windows and Cocoa classes are only about 250 lines each, so should be quick work to translate over, although I'm going to do the full package rather than the "only what I need" version that I have now.
All of the 2D drawing packages I've seen either rely on Carbon (extinct about now) or OpenGL (gently being shoved out the door by Metal as we speak.). What most people don't realize is that Cocoa and GDI are very highly optimized by their OSes and are extremely fast.
I just removed all my GUI drawing optimizations as they were slowing things down compared to just redrawing the whole window everything. I don't see either APIs going anywhere anytime soon. I was working on an OpenGL version of my GUI and when I got it running, it wasn't any faster since I still had to do the drawing in the cpu! (NanoVG, if memory serves.)
I'd forgotten about that. I think Adobe really, really wanted a 64-bit version, but Steve told them it was dead and to go Cocoa. Once upon a time, I had a far better finger on Apple's pulse, being in the industry. Now all I have are fading memories...
I'm more talking about the 2003-2010 era, and then specially the (somewhat sure) rumour that there was a 64-bit Carbon but only for Adobe, not for users.
Since Vista the drawing speeds of various operations change with GDI, and since the desktop became compositing, doublebuffering is often less needed.I still have to use double-buffering, otherwise I get flickering. Now that I'm redrawing the whole thing, I could maybe drop it, but the bitblit procedure to copy the buffer is so fast, it just makes things look better at 60fps. IIRC, the Cocoa NSView is still automatically double-buffered behind the scenes.
However extremely fast is IMHO too much honor. I don't know COCOA, Metal and its progression good enough to judge performance.
I use opengl at work for "live" images of a vision system, and it is very fast specially on Intel APUs of generation 4000 and later (because GPU upload is suddenly magnitudes faster than with older or PCIexpress cards). Uploading, drawing (scaled) large images (e.g. 28MB) and drawing 130.000 objects on top in the 0.1-1ms total range.For most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.
For most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.
Oh, okay, I see. Somebody should tell the rest of the world, though! ;DFor most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.
Actually that is wrong, and old school opengl thinking. You can actually calculate the triangles from your own more highlevel definitions using the geometry shader. I do that all the time because I only show one in every <x>(*) images, so I write quite dense abstract info per image, and only one in every <x> is actually going to be displayed and the expansion is fairly free using the geometry shader.
p.s. x (*) typically being 5 or even more.
Actually that is wrong, and old school opengl thinking. You can actually calculate the triangles from your own more highlevel definitions using the geometry shader. I do that all the time because I only show one in every <x>(*) images, so I write quite dense abstract info per image, and only one in every <x> is actually going to be displayed and the expansion is fairly free using the geometry shader.Oh, okay, I see. Somebody should tell the rest of the world, though! ;D
p.s. x (*) typically being 5 or even more.
I just wish there was one graphics standard we programmers could use and leave it up to the OSes to implement it, either offloading it to the GPU, or gracefully falling back to native where necessary. Millions of programmers would breathe a sigh of relief and maybe grow some hair back.
I agree, but Apple creating yet another competing standard (https://xkcd.com/927/) with metal, doesn't help things.No, they should have got together with Intel, NVidia and AMD, et.al., and created one together. OpenGL is fine, but getting long in the tooth with however many current versions there are...
I'm not sure to understand your question. However you can compile the above code without errors using 'conditional typecasting':It confirms that I had the right idea, but still the VST framework is passing around the wrong pointers. Overridden methods work fine, but additional fields and methods are not found whatsoever, even with casting.
I hope this can help you.
It may be better to introduce a common ancestor class. Something like this:That might be the solution I'm looking for, except that I cannot inject variables into my base class. :(
You can try using the composition instead of inheritance. Or try using some design patterns. In the absence of more specific information, I cannot give you more concrete suggestions.Thanks! That's okay. It would take more than one reply to try to explain how the VST framework works. It's not pretty, even on a good day. At its core, it's plain C with structs, but with a C++ overlay that adds a number of function pointers and opcodes and that all communicates back and forth with a host. I'm still sorting it all out...
I'm still trying to figure out how one LFO is modulating TWO parameters...Duplicating a bug in the original code (missing break statement) takes talent! :D