How do you guys make your own plugins?

[tomg]

Sorry, but tomg, your example doesn't really proove anything. By arranging code a bit differently ( a matter of the ++ operator placement, which I think is not even standarized per say), the develeopper can get the same result as gcc, if that is what's wanted.

I have no idea about Synthedit.

The point is simply this. All of us rely on more people than some would like to think we do, especally when it comes to computer code. It's true that fixing SE at code level is just as impratical as fixing C++ at the code level. We all rely on others to fix the bugs in their tools so we can fix the bugs in ours. It's the circle of life

Regards

[mbell]

All the various c++ standards leave various things un-standardized. These things are allowed to vary between compilers, and they all still fit the "standard" of valid code. Now msvc++ has had some problems in the past, but as far as I know, it is a fairly mature product at this point. The situation is a bit different from SE.

[shamann]

The point is simply this. All of us rely on more people than some would like to think we do, especally when it comes to computer code.

Sure, but some of those reliances sit higher up the chain than others. Surely as an entrepreneur, you're familiar with the concept of single point of failure.

It's nothing against SE and I have no vested interest in maintaining rank, but if you use SE to make things for others, you have no other recourse if SE goes horribly wrong somewhere. You do have more options with lower level and open development platforms. Sure, they aren't infinite nor are they 100% self-sufficient, but there are more of them.

[tomg]

Here's another analogy for you...

There was a time that all C programmers were looked at the same way SE programmers are treated today. Most people had no problem. Some people hated C. It took jobs away from real programmers and it was a slow pig.

C was (and still is) a pig. You call functions and assembly routines that you have no idea how they work but you rely on them to run your program.

People who wrote assembly or machine level were (and still are) the real programers. Everybody else uses what is called a high level programming language.

Lisp, C, C++, Basic, Fortran, Cobol...ect Some are object oriented Visual Basic, Visual C+ ...ect.. SE is in this class and is just as viable as any high level language. It's like "Visual Basic for DSP".

High level programs are compiled to machine code. The closer to assembly the faster and smaller it is. Machine horse power is a factor. Nobody and I mean nobody would run a C++ complied OS on a 1MHz processor with 64K of ram. Times change C++ is now ok and everywhere. Even basic runs fast enough to write applications. I predict that times will continue to change, so if you need to deal with that fact please do so

Regards

[CC4]

so what do you call those of us that understand this:



a lot more than this?:

[bduffy]

Gettin' pretty geeky in here...

[The Chase]

Here's another analogy for you...

There was a time that all C programmers were looked at the same way SE programmers are treated today. Most people had no problem. Some people hated C. It took jobs away from real programmers and it was a slow pig.

C was (and still is) a pig. You call functions and assembly routines that you have no idea how they work but you rely on them to run your program.

People who wrote assembly or machine level were (and still are) the real programers. Everybody else uses what is called a high level programming language.

Lisp, C, C++, Basic, Fortran, Cobol...ect Some are object oriented Visual Basic, Visual C+ ...ect.. SE is in this class and is just as viable as any high level language. It's like "Visual Basic for DSP".

High level programs are compiled to machine code. The closer to assembly the faster and smaller it is. Machine horse power is a factor. Nobody and I mean nobody would run a C++ complied OS on a 1MHz processor with 64K of ram. Times change C++ is now ok and everywhere. Even basic runs fast enough to write applications. I predict that times will continue to change, so if you need to deal with that fact please do so

Regards

bloody brilliant and so true.

[mm_FX]

All well and good, but I don't think that's the real issue here. The theory you espoused above still doesn't change the fact that if you develop in SE and sell the resulting plugins, when your paying SE-plugin customer encounters a bug in the SE engine which messes something up in said SE-plugin, you won't be able to fix it.

[shamann]

All well and good, but I don't think that's the real issue here. The theory you espoused above still doesn't change the fact that if you develop in SE and sell the resulting plugins, when your paying SE-plugin customer encounters a bug in the SE engine which messes something up in said SE-plugin, you won't be able to fix it.

Yes, but why address anything directly when times will continue to change?

[shamann]

Oh right, I forgot this:

[mm_FX]

[sonicfire]

(...)
Has anyone tried the very recent "PLugin COnstructor" ? Is it a worthy SE concurrent ?

[shamann]

(...)
Has anyone tried the very recent "PLugin COnstructor" ? Is it a worthy SE concurrent ?

http://www.digital-craftsmen.com/

Also, see the top news item on KVR's front page.

[A3ntar]

Well, I have no idea how a person would go about programming Synthedit, if they type code or not, but I disagree to put C++ on the same "height" level ( from machine ) as Synthedit.

A good C++ developper can look at piece of code and immagine the Assembly intructions that the compiler will produce. And if they don't like what the compiler is actually producing they can write their own. Synthedit is on a much higher level IMHO. To me it looks like a bunch of modules that you link together. I assume as well that the produced VsT will be an exe framework that would load the SE modules from resources and interpret as run. So a slight overhead is expected.

The closer you are to the hardware the longer the code you would have to write, this is why higher level languages were developped, to abstract as much as it can from the hardware. But how high is the cutoff between what is a useable programming language and a bunch of modules that you link together. I mean, if it gets even higher, we basically going only to be binding libraries together and doing no code at all, thus loosing a lot of flexibility.

Is sythedit bad? I don't think so, every tool has it use and it's users. But don't forget that Synthedit was also made in a high level language from a third vendor, and thus you have another layer of "dependability". The name of the game thus becomes a balance between dependability, ROI, and TTM.

[mm_FX]

Well, you can write your own DSP modules for SE in C++ or whatever, and effectively use it for its GUI and architecture. In fact as a GUI environment it's probably light years better than the VSTGUI library.

However, the fact still remains that, compared to a well-written properly-coded plugin, SE plugins usually are pretty CPU-intensive and feel rather clunky (pretty much like Visual Basic apps . Let's face it, you're always running the SE engine hidden away, showing just the patch surface itself (i.e. something like the Ensemble Panel in Reaktor). And again, you're always at the mercy of the stability of that engine that you're wrapping your creations in.

I'd also be interested to know how many of those people selling their SE plugins actually bought SE rather than using the shareware version? There's something that doesn't sit right about making money off a tool you didn't pay for, no matter what the technicalities of the license agreement are.