Is there anything ground breaking on the horizon?

[SparkySpark]

1. Jeez's stuff.
2. Energy XT.

/SparkySpark

[SJ_Digriz]

As far as I know, all c++ applications are using the same fundamentals, otherwise it would be a different language.

This is where you are dead wrong. The idea that a filter is a filter is a filter is a filter is totally wrong. The same when it comes to sound generation. The same for modulation etc. There is so much a good programmer can do with those functions that aren't available to the SE drag-n-drop mentality it boggles the mind.

And, I have yet to hear an SE synth that didn't sound exactly like all the rest. I've downloaded dozens of them and created a few myself. It is a waste of time from my point of view.

[whyterabbyt]

Yeah, CDP has just been updated to v5; some interesting new stuff in it by the sound of it....

[McLilith]

For the love of God, would you please stop?!

As a neutral party, let me try to settle this.

The coders in this argument, for the most part, understand the nature of Asm/C/C++/Delphi etc much better than most (not all) of the SynthEdit people. Many of the SynthEdit people have distorted ideas about what limitations exist in those programming languages.

While it's possible to build something interesting in SynthEdit, most users will probably not take the time to code their own unique modules. For that reason alone, most SynthEdit users will be working with a smaller scope of possibilities than the Asm/C/C++/Delphi coders. It should be somewhat reasonable to expect a greater likelihood that two randomly chosen SynthEdit plugins would resemble each other, than two randomly chosen plugins created with Asm/C/C++/Delphi.

Where the possibility for greater variation exists, and especially where the greater likelihood for variation exists, so exists the greatest likelihood for something truly groundbreaking and innovative to emerge. Notice, I didn't speak in absolutes. There's nothing to prevent some groundbreaking innovation to spring forth from SynthEdit, but it just isn't as likely to happen. Also, the same concept could probably be coded in a traditional programming language, and be a more efficient plugin.

That said, there are a lot of traditional programmers who can be very rude at times to the SynthEdit developers. (I won't mention any names--there should be no need for that.) If you happen to be a coder and don't like SynthEdit, that's great! Just don't use SynthEdit, and you should be happy. However, if you know someone else who does use SynthEdit, and they are happy with it, then let them be happy with it.

There's a proper niche to be filled with SynthEdit. Not every plugin requires a lot of calculation and optimization just to perform its intended task properly. For example, I wanted a proper ring modulator (one with 2 inputs and no built-in oscillator) it took probably 5 minutes to launch SynthEdit and create my simple plugin. There would have been no real advantage to me, in using a traditional programming language for that tiny plugin.

I think SynthEdit is great for rapid developement of simple or modestly complex plugins that don't need any breakthrough technology. If you want to create something truly cutting edge, or something utterly complex, you should probably use a traditional programming language. If you only know SynthEdit, and you manage to create something advanced like this, then god bless you.


take care,
McLilith

[McLilith]

Oh yeah, I still say the ultimate playground for synth design is hardware.

(Of course, that hardware can contain some firmware and software, if you like.)


take care,
McLilith

[stefancrs]

As far as I know, all c++ applications are using the same fundamentals, otherwise it would be a different language.

This is where you are dead wrong.

No All c++ software is written using the same fundamentals. Those fundamentals build up the language. I've used a fair amount of languages, and I do know that each language within itself always is built upon the same fundamentals. How you declare variables, how you add basic type variables together (in c/c++, use the + operator, you know...) and so forth. The fundamental building blocks. You cannot change those, because if you do, it won't be the same language any longer.

The idea that a filter is a filter is a filter is a filter is totally wrong.

Exactly what I'm trying to say. Even if you're using the same filter, you can make it do different things to the sound.

The same when it comes to sound generation. The same for modulation etc. There is so much a good programmer can do with those functions that aren't available to the SE drag-n-drop mentality it boggles the mind.

Yeah, I know, probably vice versa as well. And I consider myself a programmer when working in SM as well. It's another IDE and another language, but it's still programming.

And, I have yet to hear an SE synth that didn't sound exactly like all the rest. I've downloaded dozens of them and created a few myself. It is a waste of time from my point of view.

Uh? You think that for instance drumatic and unknown sound the same? How?

Btw, and this goes to everyone reading this:
You do ofcourse know that any waveform can be represented as a series of sines. With that in regard, does all synths sound the same? Because their fundamental waveforms can be built using just sines?

Ofcourse not.

SE has had a tremendous impact on computer based music, and as I see it, SM will probably have a bigger impact. But only time can tell.

[Amberience]

I personally consider these "DIY vst" programs to be the future. Programs like Reaktor, Max/MSP, Synth Maker, and Synth Edit... well, they are the future. Some people, no matter how formulaic their modules seem to be, they come up with some real fresh ideas and takes on old solutions - sequencers for example.

I love the fact that we don't have to rely on anyone who proposes themselves as a business.

[SJ_Digriz]

No All c++ software is written using the same fundamentals. Those fundamentals build up the language. I've used a fair amount of languages, and I do know that each language within itself always is built upon the same fundamentals. How you declare variables, how you add basic type variables together (in c/c++, use the + operator, you know...) and so forth. The fundamental building blocks. You cannot change those, because if you do, it won't be the same language any longer.

Again pure ignorance. Do you have any clue of the math involved in a filter? You can of course just download some c based fft library and do a call to it. But that would be stupid. In that context sure SE makes sense. But that isn't how you go about writing filter code. It's not just a shared library that everyone calls upon.

The idea that a filter is a filter is a filter is a filter is totally wrong.

Exactly what I'm trying to say. Even if you're using the same filter, you can make it do different things to the sound.

NOOO this is exactly what I am NOT saying. Adjusting the f**king sliders on a filter has nothing to do with modifying the actual math model that performs the filtering. You can make 2 single Q, 12db LP filters that don't sound ANYTHING like eachother. I guess until you see the actual formulas that get used for filtering this won't make sense. You have so many options within a filter for how it works on the signal it's not funny.

Yeah, I know, probably vice versa as well. And I consider myself a programmer when working in SM as well. It's another IDE and another language, but it's still programming.

I can't argue with that because I don't know SM other than the info. I haven't tried it. I don't want to get into the "it isn't coding" argument. That was never my intention. But I have used SE and I can tell you it is NOT coding any more than a person making there own CD compilations is a musician.

Uh? You think that for instance drumatic and unknown sound the same? How?

I've never heard unknown so I can't make the comparison. But I'll say that many of the SE "not" synths sound exactly like the SE synths. Drumatic is no exception.

Btw, and this goes to everyone reading this:
You do ofcourse know that any waveform can be represented as a series of sines. With that in regard, does all synths sound the same? Because their fundamental waveforms can be built using just sines?

Ofcourse not.

This again makes it seem to me that you have never seen the code that creates an oscillators output or the code that performs the filtering. You continue to make it sound like there is only one function that does it.

SE has had a tremendous impact on computer based music, and as I see it, SM will probably have a bigger impact. But only time can tell.

I didn't say it didn't. Also, I didn't say that these weren't great tools for individuals to do things with. I just maintain that if you want anything unique that you will have to roll your own.

Do you think that the people writing audio modeling software are just downloading a C++ library and tacking on the bits that make whatever instrument sound? Let's hear that Hydratone EQ from SE or SM. Or like Urs said, go ahead and replicate some of his work. You can't BECAUSE IT ISNT SOME STOCK LIBRARY YOU CAN DRAG OVER AND LINK.

[SJ_Digriz]

OT rants are way more fun that staying On Topic.

[pw]

I personally consider these "DIY vst" programs to be the future. Programs like Reaktor, Max/MSP, Synth Maker, and Synth Edit... well, they are the future. Some people, no matter how formulaic their modules seem to be, they come up with some real fresh ideas and takes on old solutions - sequencers for example.

I love the fact that we don't have to rely on anyone who proposes themselves as a business.

ahh, except those who create these 'DIY' programs, they are businesses too right?

[Urs]

SJ_Digriz,

I think the fundamental problem in understanding stefancrs is, in Synthmaker you can actually create new objects on source code level and they'll be compiled to native code with its built-in compiler.

The reason why I posted Reaktor 5 as a ground breaking thing on the horizon is just that. It has a nifty environment that lets you create new blocks on a pretty low level, and compiles it. And it comes with an extensive library of examples, i.e. physical models of diodes, capacitors and resistors etc. - that should serve for a nice playground, and I'm indeed considering to prototype some algorithms in Reaktor 5.

Nonetheless, to me "ground breaking" has that certain flavour of "complexity". So I would guess that it works inverse proprotional to the strengths of visual environments. I've seen MAX/Msp cracks working on simple FM synthesizers for weeks, just to get the idea of different 4-operator algorithms working. Sure, it's possible, but you won't save any time over hand knitted software when you've got to deal with hundreds of wires... so, here I'm with you

Cheers,

Urs

[stefancrs]

No All c++ software is written using the same fundamentals. Those fundamentals build up the language. I've used a fair amount of languages, and I do know that each language within itself always is built upon the same fundamentals. How you declare variables, how you add basic type variables together (in c/c++, use the + operator, you know...) and so forth. The fundamental building blocks. You cannot change those, because if you do, it won't be the same language any longer.

Again pure ignorance. Do you have any clue of the math involved in a filter? You can of course just download some c based fft library and do a call to it. But that would be stupid. In that context sure SE makes sense. But that isn't how you go about writing filter code. It's not just a shared library that everyone calls upon.

I think you're just misunderstanding me.
You do know that I am a audio c++ programmer for a living? I coded my first softsynth (in C) in 1997, and I made the oscillators and filters without the help from any book or online resources. I majored within the DSP field (the D-course was in Digital Signal Processing). You still make filters, in for instance c++, by using standard components. They are just lower level than in for instance SE.

The idea that a filter is a filter is a filter is a filter is totally wrong.

Exactly what I'm trying to say. Even if you're using the same filter, you can make it do different things to the sound.

NOOO this is exactly what I am NOT saying. Adjusting the f**king sliders on a filter has nothing to do with modifying the actual math model that performs the filtering. You can make 2 single Q, 12db LP filters that don't sound ANYTHING like eachother. I guess until you see the actual formulas that get used for filtering this won't make sense. You have so many options within a filter for how it works on the signal it's not funny.

I've derived my fair set of filter algorithms, that's not what this is about. For instance, if you feed a filter back into itself, you've made a new filter. It will sound different from when not feeding it back into itself. If you let the filters output modulate the filters cutoff frequency, it will again be a new algorithm and implementation, and it will sound different.

Yeah, I know, probably vice versa as well. And I consider myself a programmer when working in SM as well. It's another IDE and another language, but it's still programming.

I can't argue with that because I don't know SM other than the info. I haven't tried it. I don't want to get into the "it isn't coding" argument. That was never my intention. But I have used SE and I can tell you it is NOT coding any more than a person making there own CD compilations is a musician.

Nor is c++. Only assembler is coding. No. Only direct opcodes is coding. Anything else is just using premade assembly code generated by other persons or softwares.
It's hard to draw the line.

Uh? You think that for instance drumatic and unknown sound the same? How?

I've never heard unknown so I can't make the comparison. But I'll say that many of the SE "not" synths sound exactly like the SE synths. Drumatic is no exception.

An opinion I guess. That's ok

Btw, and this goes to everyone reading this:
You do ofcourse know that any waveform can be represented as a series of sines. With that in regard, does all synths sound the same? Because their fundamental waveforms can be built using just sines?

Ofcourse not.

This again makes it seem to me that you have never seen the code that creates an oscillators output or the code that performs the filtering. You continue to make it sound like there is only one function that does it.

I've seen it plenty of times and I've coded quite a big amount of oscillators with different algorithms and implentations myself. I just wanted to make a point that just because the fundamentals are the same the result does not have to be. But the irony in my argument got lost somewhere

SE has had a tremendous impact on computer based music, and as I see it, SM will probably have a bigger impact. But only time can tell.

I didn't say it didn't. Also, I didn't say that these weren't great tools for individuals to do things with. I just maintain that if you want anything unique that you will have to roll your own.

Which is what a lot of people do. In SM. In SE. In Delphi. In C++. In ASM. And so on.

Do you think that the people writing audio modeling software are just downloading a C++ library and tacking on the bits that make whatever instrument sound? Let's hear that Hydratone EQ from SE or SM. Or like Urs said, go ahead and replicate some of his work. You can't BECAUSE IT ISNT SOME STOCK LIBRARY YOU CAN DRAG OVER AND LINK.

No, I don't think that's what they (we) do, I know it isn't. I didn't imply that.
No doubt, I could replicate Hydratone EQ or Filterscape in SM. Why wouldn't I be able to? I don't have to rely on stock library stuff in SM. I can implement whatever algorithms I want, graphically or in the code module.

For some reason, you seem to approach my arguments as if I'm someone that does not know how programming works. But I've been programming for about 18 years, and quite successfully I might add. Instead of reading what I really say, you read lots of stuff into my arguments. Please don't

[Z3R0T0N1N]

after all this time there is still the argument being made over and over that 'how much can you do with the same oscilator?' blah blah blah, drool.
There are TONS of third party oscillators and filters, and you can easily write you own.
You can easily build your own oscillator or filter using low level modules.
and here's the one that just kills me:
the eternal argument that everything out of synthedit is a subtractive synth...

?????????????????
wtf.

what can i even say to that? are you f**king retarded?

my ass off.

[whyterabbyt]

Urs quoth And it comes with an extensive library of examples, i.e. physical models of diodes, capacitors and resistors etc. - that should serve for a nice playground, and I'm indeed considering to prototype some algorithms in Reaktor 5.

Really? Its has component-level modelling as well as low-level DSP stuff?

[McLilith]

the eternal argument that everything out of synthedit is a subtractive synth...

?????????????????
wtf.

what can i even say to that? are you f**king retarded?

my ass off.

Yes, some people exaggerate the percentage of subtractive synths that are produced with SynthEdit, versus other products produced with SynthEdit.


take care,
McLilith