SCOPE 64 Bit beta..........?

[iSiStOy]

Let's also admit I don't even have 1% knowledge of how much DSP assembler and C++ abilities are needed to understand what porting the core platform to OSX means...
No framework nor prog. pattern as a helper that I can think about here, but S|C's own one (but maybe for Graphic User Interaction)! Tremendous work!

[astroman]

well, since it's waiting anyway... to add some speculations about stuff
the DSP part is likely fairly self-contained, because the system ran well under Mac OS9
(which is as far from Windoze as you can think)

I'd rather expect problems with enforced security handling of memory blocks which has become a major issues since buffer overflow (and similiar) attacks. Scope acts as a kind of compiler in many cases and must modify execution code in memory during runtime. The original system was completely unlimited in that context, as M$ either wasn't aware of such potential 'security problems' or simply ignored them.
I wouldn't want to bet my right arm on any fix (or strategy) M$ offers... they are well known for clumpsy solutions.
Assuming that Scope does 'compile' stuff, the original module (which may not even be a CWA design) could reveal flaws in specific circumstances NOW, which were not traceable under a 32bit OS.
Even the smart MacOS memory handling had similiar issues - and Apple's developement team had coders of the highest regard in industry that time.

One may assume that these 2 ideas have some probability at least...
Such stuff is more difficult to handle, as you don't fix some messed window content (for example), which you could directly adress.
Instead you deal with a code generator, whose (abstract) results may fail in some way... and typically only under specific circumstances.

I have no idea if this really applies, but it's a valid scenario that could cause tremendous delays due to 'late discoveries' of bugs or whatever you like to call that.
As we all know THERE IS NO flawless software out today - it cannot be.
The shere size of the object code gives you a good estimation how many lines of code were required.
It's impossible to iron out everything above a give maximum because there's not enough time.

BUT... that's only half of the story.
Even if someone would in fact write a flawless piece of code, it HAS TO run in an environment that definitely IS NOT flawless to the same degree.
I've lost track, but when M$ released Win2k, they claimed to have fixed 45k bugs from Win98.
Code size has increased in magnitudes since then... go figure yourself
(not sure about the versions as it's been some time, but the 45k is correct)

We also know from experience that mobo chipsets can be pretty buggy, too.
Some bugs even make it to features and aren't fixed on the hardware, but by specific code to handle them...
It's a jungle out there...

That's why I'm not even surprised that a company like Sonic Core has to delay their schedule in the way we currently experience.
You can't simply fight that with headcount - this is not about stylesheets for a website.
It's fairly abstract code handling... not using (something like) a C compiler, but writing the complier itself.
And this device has to work in an environment that's beyond your own control...
(to be honest... it's also beyond reason... but that's mho and a different story)
You get the idea ?

cheers, Tom

[nightscope]

I would think that once the white coats at SC get current the software good and ready, bringing some smaller and more I/0 featured products into the Xite range might be a relatively easy and quick thing to do.

ns

PS I know nothing.

[dawman]

IMG_1691.jpg

[nightscope]

Meanwhile, the new UK Coalition Govt. spending cuts begin to bite.

RAF takes delivery of the latest Huntin' Dog Attack Plane.

dogplane.jpg (122.26 KiB) Viewed 3426 times

ns

[iSiStOy]

The fact you can create specific modules inside scope software, from atomistic components & then execute them would confirm that a compiler of some sort exists inside the platform.
I also seem to understand what you mean about the os platforms themselves and their own "evolutions".
Regarding 64bit driver for scope pc, I imagine both soft and driver must be opened up and partly rewritten.
For the soft, I guess there are specific data types that are to be replaced by others, compliant with 64bit.
But for driver, I quite really don't know what would have to be done.

Well... It's surely not like applying styleheet to a web form

[menno]

And Im looking forward to the day where SC announce that the Pulsar, Pulsar2, Scope and Scope2 are legacy products and will therefor not receive any new updates. Any company in the world has to earn money to survive, innovate and create. And let us be honest - there're EXTREMELY few on this forum that are prepared to invest any more money on their Scope environment.

I for one invested more money in the Scope 5.0 upgrade. I doubt I'm alone

[Sounddesigner]

And Im looking forward to the day where SC announce that the Pulsar, Pulsar2, Scope and Scope2 are legacy products and will therefor not receive any new updates. Any company in the world has to earn money to survive, innovate and create. And let us be honest - there're EXTREMELY few on this forum that are prepared to invest any more money on their Scope environment.

I for one invested more money in the Scope 5.0 upgrade. I doubt I'm alone

The 4.5/5.0 upgrade was a no-brainer upgrade for me and many. I'm not convinced the developers of all the instruments/Effects/drivers/etc are truly getting financial justice proportional to all the hardwork for everything in that upgrade, and that upgrade is by faaar more of a user/customer benifit then S|C. It was EASY for many people to buy used cards and then buy the 4.5/5.0 upgrade and enjoy much of what the SCOPE Platform has to offer without spending much with S|C. They either bought their PCI cards {wich S|C tech-supports and is doing more expensive developement for that will be a further benifit to those users) used or from Creamware. 4.5/5.0- it's a no-brainer, am i wrong?
Don't get me wrong i believe every little bit of support financially to Sonic Core helps but that particular upgrade is more of a user benifit by far, and truly one of the best bargains on the market OF ALL TIME, am i wrong? Again S|C could have made smaller versions of XITE-1 rather then a 5.0 for SCOPE PCI, wich might have been more profitable since many users of SCOPE PCI don't really spend any true money with S|C or third-party, and discontinued pci, but they did'nt.

S|C has too much work on their plate, but for now i think this needs to be. It's great their trying to do SDK, PCI, XITE-1, etc all at once ATM cause i think that's just how it needs to be, but at some point they need to start making business moves not charity ones. Extreme bang for the buck offers when dealing with expensive-to-design and maintain dsp platforms won't work for the developers, that's better suited for Native-World.


EDITED

[ARCADIOS]

we all have to admit that it is almost impossible to be 100% satisfied one by one by 1 company.

there are thousands of different directions a company can follow.
we just get the one that S|C chooses.

and i do not think that there is out there in the market any company that does it ALL in ONE.

to me still the SC pro boards are expensive 2000euros.... since i have all of the software.
but thats technology.
Like RAM DDR1 is more expensive than DDR2.....so....SCOPE PCI is MORE EXPENSIVE THAN XITE in comparison

This Discussion here became a wishlist for scope future editions.
well in that point of view, i would deffenately wish to have a XITE as it is... 3000 ok.BUT>>>>with a nice exlusive SONICORE SEQUENCER.
that would be the real FULL studio for us...... i think

sequencer....64bit i mean offcourse....hmm?