PlanetZ forums - scopeusers.com

PC are not suitable for advanced concepts too ! and we use it every day ...

The irony of that post is.....

The only plugins I have spent money on (about $600 worth) in the past 6 months have been for my CW / SFP system!

Every time I get tempted to buy native plugs, I fire up the CW boards and am blown away by the sound.

LOL

Quote from Angus,

"Unfortunately, sales were extremely poor, and the development environment has major shortcomings"

Funny, I've felt the same way about most of his releases. Some of my friends rave about them, but personally I just haven't seen anything that grabbed me. The closest was DR-008, but I think both the NI and Linplug stuff is better.

Oh well!

his comment about SFP (which I assume he means SCOPE DP) being like Reaktor and "Lego" building-block-like is much too simplistic. one does connect graphical representations of code together, but this is just one aspect of the design process. one can freely assign DSP-allocation, manage DSP-usage, and create new DSP modules from scratch using the existing "math" atoms, as Flexor is seemingly so eloquently demonstrating (whenever it comes out). this doesn't even consider the powerful GUI tools and flexible (and efficient) parameter-retaining methods (for Preset Lists + Project-settings)

he obviously didn't dig in deep enough, and/or is a "Strict Coder" and found the DP-method of development to be too different from what he was used to. in the right hands, the DP-environment invites experimentation and innovation, it's kinda like being in a huge room full of electronic components and all the tools to build something (plus the factory to design the interface). Reaktor does one small aspect of what DP allows and its audio quality is only suitable for certain applications, IMHO (sample-based). this analogy is not 1:1, in the least.

someone in the subject's thread said that SFP is suitable for synthesis, but not drum-synthesis... huh? they use the same concepts/atoms. comments like these force me to discount the source.

as per "advanced concepts" or whatever this comment was... I guess we will see. Solaris and Flexor are very progressive concepts (together they could potentially be astonishing) and even my latest stuff is progressive from a "synth-quality-for-the-money" standpoint. Physical Modelling is one of the most advanced synthesis concepts around today and what do they think the Six-String is? Granular is on its way and I am working on some ideas in FM and Additive synthesis. I'm just wondering what they seem to think *cannot* be done in SCOPE DP... one just needs the time and creativity, it seems to me.

also, this would be an interesting time to ask you guys what "advanced" (read as non-subtractive) synthesis (or unique processing method) should be concentrated on for future development? what is REALLY missing that none of the existing or forthcoming devices will not allow?

besides bug-fixes...


<font size=-1>[ This Message was edited by: wavelength on 2003-09-01 16:42 ]</font>

I think you guys misunderstood him... he's talking about custom functionality like disk-streaming in BFD etc... such things would be extremely difficult to implement within SFP without some serious help from Creamware.

You have to understand that most developers who work in C and who are able to come up with their own ways of doing things may not appreciate the way Scope DP works. Doesn't mean they are dissing the platform necessarily!

Each platform has its advantages and disadvantages... face that fact. It's true there is nothing in native systems to compare to Modular3. However, I personally would much rather use a native sampler and run it through Pulsar filters.

peace


<font size=-1>[ This Message was edited by: dArKr3zIn on 2003-09-01 15:19 ]</font>

Well trouble is, I don't know what can be done !
It's like : I have Reaktor Session and I download what is " offered " if no one use the granular cloud delay or underdog, less used modules well then ...

If I had the list of atoms, I could say " ohh, easy ! just do this and that, no big deal "

When I look ( sigh ) at Flexor modules, I feel more untapped potential !

I'am more looking forward and oddly high end tech are used to make " old " tools ( B2003, Six Strings )

VA wise I'am a little happily saturated ! with your synths, Stephen, and Solaris, I'am fulfilled but if you want to make an another SparC or Uberplastic ... hmmmmm ...

What would make me drool is odd creations from modulars ( Python Pro ) or hybrids : a little touch of everything + smart construction / routing / modulations ...

i think it's also worth bearing in mind that FXpansion dropped out of SCOPE development before SFP3.1 existed. In fact MiniMax, Pro One, Vinco, ModIII, B-2003 etc. were not even a dream then. In fact Mod2 probably hadn't even happened when Angus dropped out.

i also believe most SCOPE developers are users too, whereas Angus dropped the platform completely so he obviously was never that keen on the Pulsar concept, otherwise he'd still be using the system even though he isn't developing for it anymore. He moved to VSTi development because it was more lucrative - he stated as much on his website (and maybe even here at the z) at one time. For some it's love over dollars. i'm not saying the guy shouldn't earn money, just that him commenting on SCOPE when he probably hasn't even used/heard SFP3.1 is a bit rich.

Glad he did that VST-AU Adaptor though.

<font size=-1>[ This Message was edited by: Mr Arkadin on 2003-09-01 19:14 ]</font>

On 2003-09-01 14:33, wavelength wrote:
someone in the subject's thread said that SFP is suitable for synthesis, but not drum-synthesis... huh? they use the same concepts/atoms. comments like these force me to discount the source.

I believe you were refering to my post and that's not what I meant at all. I was refering to point that more simplistic sample drum players like DR-008 are better off left to the native VSTi world. IMHO the power of the scope platform is better suited to fx and synthesis as this is where the real benefit of DSP comes in.

- sinix

On 2003-09-01 16:24, sinix wrote:

On 2003-09-01 14:33, wavelength wrote:
someone in the subject's thread said that SFP is suitable for synthesis, but not drum-synthesis... huh? they use the same concepts/atoms. comments like these force me to discount the source.

I believe you were refering to my post and that's not what I meant at all. I was refering to point that more simplistic sample drum players like DR-008 are better off left to the native VSTi world. IMHO the power of the scope platform is better suited to fx and synthesis as this is where the real benefit of DSP comes in.

- sinix

gotcha true enough...

I actually think Angus was pretty on the mark when he talked about the building blocks thing - i.e. the atoms - and the 1+1=2 maths argument. Maths is maths. However, some maths is more complex than others.

The fact is that the *vast* majority of plugins available for SFP use the Creamware atoms. There are a few exceptions - firstly, the Timeworks plugins, and Michael Olsen sure did a great job of converting his CPU-based algorithms to SHARC format. One of the few other custom-atom-equipped devices I can think of are the Obsidian devices, and those which Obsidian developed for FXPansion. I'm sure that anyone who has used these devices will acknowledge that the DSP programming there was not that great at all, in retrospect. The same also goes for the DSPDev stuff (or is it DaDev now?) - custom atoms, but not very stable, or IMHO good-sounding.

It's certainly true that Creamware did an amazing job of making some killer algorithms available in the Scope 'atoms'. And every device which uses them (including FleXor!) will understandably sound great. However, I think that when it comes to custom DSP atoms, unless the author is *very* skilled, or has serious help from Creamware or Analog Devices, then the chances of making a good-sounding algorithm are very small.

And the fact is that many developers want to incorporate new interesting technologies into their work... this is very difficult on SFP without Creamware-assistance. In C++ and native systems it is far more accessible and 'logical' to develop new functionalities. There are many readily-available, relatively cheap development tools, and a *huge* amount of literature on the subject. On the other hand, I can't think of many SHARC assembler textbooks.

Now, consider this from a developer standpoint. The amount of resources required to code SHARC properly are pretty large. And look at the market size - it's tiny compared to potential VST sales. So I think it's pretty understandable that most 'established' developers do not support it.

<font size=-1>[ This Message was edited by: dArKr3zIn on 2003-09-01 16:56 ]</font>

<font size=-1>[ This Message was edited by: dArKr3zIn on 2003-09-01 17:00 ]</font>

Stephen, about drums ...
I would REALLY like ...
A massive percussions machine !
Drumvox is killer but I'am thinking vaguely about Newscool the Reaktor ensemble !

4 sine with pitch and level knob + pitch and level envelope ( just AD ), ringmod and FM receive and send to other + light FX section ...

And YOU could add many many more enhancements and additions : attack, hold, decay envelopes for lots of parameters, more waveforms .... etc etc well you have at least one customer for an ultimate and definitive percussions tool !!

well Stephen, pleased to read that you're considering FM and Additive stuff

Is a DX-ish thing too outdated ?
I really LOVE my TX7 and compared to NI's FM7 I consider the 12bit original more beefy, though it's indeed a little noisy.
Nevertheless the FM7 was the trigger to buy the TX and I'm seriously considering to get the hifi version TX802 as well.
There are some real gems in that huge library of DX7 presets - I'd be curious how those would sound in SFP.
Since FM is extremely sensitive to math, so even if a faithful reproduction of the DX7 structure isn't the most innovative concept, it might end with something new.
And of course you could add your regular stuff for the not-so-faint-of-heart, too.

cheers, Tom

advanced methods? how about fft or any other form of spectral analysis and resynthesis? I'd suppose that's near impossible. I think anything that requires off-line analysis is impossible. I think some of what the coders say are true, in that SFP simply doesn't have the ability to handle non-realtime synthesis. (FFT needs 1 off-line analysis and a buffer to hold the info)

Something else that's impossible because of the memory limitation is any form of algorithmic composition, be it stochastic or not. You'd definitely need to be able to handle arrays and matrices. There could be a way, I'm not sure.

Either way, I'm definitely not under the impression that the DP package can beat hard coding in terms of versatility. The newest DP package is always the limit, and ther are certain things that you just can't work around. I don't have the DP so I'm just speaking from the general "impression" I get.

But then, the sound quality of the realtime stuff is just superb. That in itself is worth it. And maybe I can do the off-line stuff with memory requirements elsewhere. It makes perfect sense.

On 2003-09-01 16:54, dArKr3zIn wrote:
I actually think Angus was pretty on the mark when he talked about the building blocks thing - i.e. the atoms - and the 1+1=2 maths argument. Maths is maths. However, some maths is more complex than others.


It's certainly true that Creamware did an amazing job of making some killer algorithms available in the Scope 'atoms'. And every device which uses them (including FleXor!) will understandably sound great. However, I think that when it comes to custom DSP atoms, unless the author is *very* skilled, or has serious help from Creamware or Analog Devices, then the chances of making a good-sounding algorithm are very small.

And the fact is that many developers want to incorporate new interesting technologies into their work... this is very difficult on SFP without Creamware-assistance. In C++ and native systems it is far more accessible and 'logical' to develop new functionalities. There are many readily-available, relatively cheap development tools, and a *huge* amount of literature on the subject. On the other hand, I can't think of many SHARC assembler textbooks.


<font size=-1>[ This Message was edited by: dArKr3zIn on 2003-09-01 16:56 ]</font>

<font size=-1>[ This Message was edited by: dArKr3zIn on 2003-09-01 17:00 ]</font>

what has to be understood here is that an "adder" or "multiplier" code-atom does not have a sound-quality in and of itself. CreamWare does provide us with fully-realized oscillator/mixer/filter, etc modules (if we choose to use them), but ALSO very basic, low-level code atoms to make new oscillator/mixer/filter, etc modules, if we want to. the "Flexor" oscillators will sound NOTHING like the original CreamWare oscillators... they are built from very basic code-atoms, from the "ground-up"... the Adern people have been very clear about this. just because CreamWare supplies us developers with stable code modules does not dictate what the sonic outcome will be. DP does allow access to a very deep level of coding, if one wants to go down that road.

you also said: "And the fact is that many developers want to incorporate new interesting technologies into their work... this is very difficult on SFP without Creamware-assistance."

what specific technologies are you talking about? in what way does CreamWare make this difficult to someone like me? where are you getting your info from? i feel only limited by my time (= money) and my own personal abilities/imagination/ limitations, not by CreamWare.

i guess i just don't see the same issues that you are expressing, beyond what limitations are inherent to DSP-based technology, as a whole.

On 2003-09-01 17:20, kensuguro wrote:
advanced methods? how about fft or any other form of spectral analysis and resynthesis? I'd suppose that's near impossible. I think anything that requires off-line analysis is impossible. I think some of what the coders say are true, in that SFP simply doesn't have the ability to handle non-realtime synthesis. (FFT needs 1 off-line analysis and a buffer to hold the info)

Something else that's impossible because of the memory limitation is any form of algorithmic composition, be it stochastic or not. You'd definitely need to be able to handle arrays and matrices. There could be a way, I'm not sure.

Either way, I'm definitely not under the impression that the DP package can beat hard coding in terms of versatility. The newest DP package is always the limit, and ther are certain things that you just can't work around. I don't have the DP so I'm just speaking from the general "impression" I get.

But then, the sound quality of the realtime stuff is just superb. That in itself is worth it. And maybe I can do the off-line stuff with memory requirements elsewhere. It makes perfect sense.

http://www.music.buffalo.edu/lippe/pdfs/fft.pdf

<<< this might be of interest. this is certainly not my area of expertise, but it makes me wonder if a "look-up table" for the analysis could be done in real-time, kinda like a vocoder?

algorithmic composition is certainly possible using SCOPE DP, particularly something randomized. you could even conceivably do something of this using the ModIII, no?

<font size=-1>[ This Message was edited by: wavelength on 2003-09-01 18:38 ]</font>

However, I personally would much rather use a native sampler and run it through Pulsar filters.

peace

With Gigisampler and the Creamware samplers it seems like a waste of time to try and code a new one for SFP. I think Creamware knows what they do best and are doing it with great new instruments.

Creamware SFP definitely has weaknesses but it's strengths complement all the weaknesses of a computer based studio so sweetly.

<font size=-1>[ This Message was edited by: R-type on 2003-09-01 18:44 ]</font>

I read the KVR forum again, I understand what they're saying. Sample/resample based effects would be difficult to do on the creamware platform.

I agree but I can't see the need for good synths and instruments going away.

Hi Stephen

Yes, you are right that the maths functions do not have an inherent sound quality. I was speaking more about the other stuff on the platform, not absolutely about FleXor. FleXor is the brainchild of a very skilled person indeed, and I'm extremely lucky to be able to beta test them. However, the main crux of my argument is that Scope DP is not the greatest thing for implementing things like disk-streaming etc. And if you want some custom DSP functions it is extremely difficult to do it. Maths functions are one thing, but they are not as efficient as having a dedicated DSP atom for it. I don't want to argue with you or anyone, but if you would like to make a disk-streaming sampler for SFP, I'd like to see it

Also, from a developer perspective, Scope DP is not the greatest environment for debugging, etc. I'm just trying to offer some explanations as to why more developers don't program for this platform.

Don't get me wrong, I'm a staunch Creamware advocate, I wouldn't bother lugging my Magma box around with me if I wasn't. However, it's a fact that every platform has its strengths and weaknesses, Scope simply does some things better than others.

peace

On 2003-09-01 16:54, dArKr3zIn wrote:
...And the fact is that many developers want to incorporate new interesting technologies into their work...

... In C++ and native systems it is far more accessible and 'logical' to develop new functionalities. There are many readily-available, relatively cheap development tools, and a *huge* amount of literature on the subject. On the other hand, I can't think of many SHARC assembler textbooks.

Now, consider this from a developer standpoint. The amount of resources required to code SHARC properly are pretty large. And look at the market size - it's tiny compared to potential VST sales.

maybe they want to, but CAN they do ?
I don't see much innovative concepts on the FXpansion page. Drumsamplers are anywhere, even in SFP, disk streaming was originally introduced years ago and pattern sequencers exist since the C64.

C++ is a system that relies heavily on readymade libs, a plague of libs imho.
Compared to Scope DP there's not more 'freedom', but endless possibilities of messing things up.

The real stuff is still coded in assembler, but who's capable of doing that today ?
I guess less than 1% of professional programmers, forget about the hobbyists.
And if you know how to code this, it doesn't matter what chip you use it on, be it a Pentium, PPC or Sharc. With that skill level and talent you might some need assistance by CW in ultra low level interfacing (possibly), but not in program and system design.

A small but profitable market in the high end is far better than to be a noname in a huge competition of 'me-too's and struggle in the warez jungle.

my 2 cents, Tom