Is it possible to develop a VST using Visual Basic 6?
-
- jaaathmaster
- 2690 posts since 1 Jun, 2001 from Marlow, S. Bucks, UK
No, using good APIs means that coding is both quicker in the first place AND cross platform. There are standard file I/O libs for C++. Using these would make your code naturally cross platform, and save you time rather than writing platform specific file reading/writing code. Why compromise?nollock wrote:
For sure write abstracted interface for somthing like patch file i/o but dont write a cross platform one untill you need it. It would be a waste of time.
Music with dinner is an insult both to the cook and the violinist.
-
- KVRist
- 216 posts since 10 Jan, 2003
To be honest, I don't know them. To make it a bit clearer: I don't like the operator overloading idiocy of C++, and I don't like the lack of abstraction and type safety in stdio.
I imagine the object pascal libraries don't suffer from either of these as badly, but can you, for instance, write to a string as easily as to a file?
The other problem, of course, is that there's no sensible way of handling pathnames. You've just got to write separate code paths.
I imagine the object pascal libraries don't suffer from either of these as badly, but can you, for instance, write to a string as easily as to a file?
The other problem, of course, is that there's no sensible way of handling pathnames. You've just got to write separate code paths.
-
- KVRian
- 1153 posts since 10 Dec, 2003
ok so file i/o was a bad example. But i realy do think you have missed the point. Are you saying everything should be coded cross platform even though you have no need for it? Should sombody go to all the trouble of finding and intergrating cross platform libs for graphics and the gui ect.. even though you have no intention of making the product cross platform?griels wrote:No, using good APIs means that coding is both quicker in the first place AND cross platform.nollock wrote:
For sure write abstracted interface for somthing like patch file i/o but dont write a cross platform one untill you need it. It would be a waste of time.
There are standard file I/O libs for C++. Using these would make your code naturally cross platform, and save you time rather than writing platform specific file reading/writing code. Why compromise?
chris
-
- KVRer
- 10 posts since 24 Nov, 2003
It's good programming practice to make things as portable as possible, WHERE possible...
Perhaps that shouldn't be taken to the extreme that you sacrifice your programs functionality and slow the process of developement considerably.
The thought to consider in general practice is the re-useability of the code you write. Will you be able to plug that same code into a new project later on down the line? Because if you could, you might save yourself and others a lot of time. Using portable code that is based on a long standing standard is a good way to ensure the re-usability of your code (good commenting will help you too
).
I have coded many MIDI utilities for myself and my daily hobby music... this in order to accomplish some tricks that aren't readily available to me in other software. Instead of re-coding my MIDI input/output setting screens and new MIDI message polling and such... I am able to re-use the same code very easily.... partially due to my code being highly modular and partially because it adheres to a standard I have used accross all of my apps.
Perhaps that shouldn't be taken to the extreme that you sacrifice your programs functionality and slow the process of developement considerably.
The thought to consider in general practice is the re-useability of the code you write. Will you be able to plug that same code into a new project later on down the line? Because if you could, you might save yourself and others a lot of time. Using portable code that is based on a long standing standard is a good way to ensure the re-usability of your code (good commenting will help you too
). I have coded many MIDI utilities for myself and my daily hobby music... this in order to accomplish some tricks that aren't readily available to me in other software. Instead of re-coding my MIDI input/output setting screens and new MIDI message polling and such... I am able to re-use the same code very easily.... partially due to my code being highly modular and partially because it adheres to a standard I have used accross all of my apps.
-
- jaaathmaster
- 2690 posts since 1 Jun, 2001 from Marlow, S. Bucks, UK
No, I'm just saying that as abstraction can save you time, you might as well use it until it starts costing you timenollock wrote:ok so file i/o was a bad example. But i realy do think you have missed the point. Are you saying everything should be coded cross platform even though you have no need for it? Should sombody go to all the trouble of finding and intergrating cross platform libs for graphics and the gui ect.. even though you have no intention of making the product cross platform?
chris
Start with the best intentions, then cross the bridge of such technicalities when you come to them, instead of burning your cross platform bridges at the start? 
Music with dinner is an insult both to the cook and the violinist.
-
- KVRian
- 922 posts since 26 Mar, 2003 from Guildford, England
If you use something like Qt, your C++ will already be portable between UNIX, Linux, Windows and OSX. You just need to recompile it!
It is a really nice set of classes, and is pretty powerful (with help fom the meta object compiler). Its got features similar to the VCL, but without using non-standard C++.
I've only just discovered it - it looks fantastic.
It is a really nice set of classes, and is pretty powerful (with help fom the meta object compiler). Its got features similar to the VCL, but without using non-standard C++.
I've only just discovered it - it looks fantastic.
-
- KVRAF
- 4644 posts since 28 Nov, 2002 from Chicago
Borland's C++ Builder and Delphi environments switched to using Qt when Kylix was released.
It seems that Borland are steeping away from Qt with the release of BuilderX, but versions of C++Builder and Delphi with native Qt support are still available.
It seems that Borland are steeping away from Qt with the release of BuilderX, but versions of C++Builder and Delphi with native Qt support are still available.
Someone shot the food. Remember: don't shoot food!
-
- KVRian
- 1153 posts since 10 Dec, 2003
Okgriels wrote:No, I'm just saying that as abstraction can save you time, you might as well use it until it starts costing you time
chris
-
- KVRian
- 1153 posts since 10 Dec, 2003
you should check here too..texture wrote:If you use something like Qt, your C++ will already be portable between UNIX, Linux, Windows and OSX. You just need to recompile it!
It is a really nice set of classes, and is pretty powerful (with help fom the meta object compiler). Its got features similar to the VCL, but without using non-standard C++.
I've only just discovered it - it looks fantastic.
http://www.atai.org/guitool/
-
- KVRist
- 216 posts since 10 Jan, 2003
This, of course, is one of the major problems with most "platform-independent" stuff. They lock you into their platform.valley wrote:It seems that Borland are steeping away from Qt with the release of BuilderX, but versions of C++Builder and Delphi with native Qt support are still available.
No a criticism of open-source stuff, but I've seen too many CORBA implementations go wrong...
