Very importmant for other users !

haim · Post by **haim** » Thu Jul 07, 2005 5:28 am

Hi to everyone

I'm a Creamware user almost from their beggining, and I really love that concept and platform. I'm bouth - mac and pc user, and I for almost a year waiting to give a chance people from creamware to write driver and SFP for OSX. We already know the result of that ... now problem is the same ... there is no drivers for XP64 ... not even close ...

I was read all posts here about that ... but one thing is sure ... YES I WANT TO CROSSOVER TO XP64 ... it's not about the speed or something like that ... it's about the RAM memory ... 2gb of ram ... only in 32bit ... that is the problem ...

Cause of that ... I'm forced to do something that I really don't want to ... today I sold my SCOPE and start to build my concept on some other platforms ... Thats all ... Best wishes to Creamware ... Rest In Peace with your bussiness politics ...

Regards

Haim Jovan

bgarlow · Post by **bgarlow** » Thu Jul 07, 2005 5:44 am

sorry...to...see...you...go

fra77x · Post by **fra77x** » Thu Jul 07, 2005 5:46 am

Great decision my friend, good luck, that thread is a joke...oops...

Gordon Gekko · Post by **Gordon Gekko** » Thu Jul 07, 2005 5:48 am

rest in peace with your choice, you've just ditched the best audio platform available today

btw, if you want to address creamware i suggest you do it through an email, this forum is not tied to the company

narly · Post by **narly** » Thu Jul 07, 2005 9:31 am

First - Wrong forum...?

Second - I understand certain portions of a studio must move forward. However, if Scope is important, why not include the Creamware setup on a "legacy" platform while moving the rest forward? It seems there are users with fairly minamilistic hosts that support Scope adequately and reliably. There are also plenty of ways to integrate multiple machines in a studio.

I used to have an Oasys card and couldn't believe the constant whining about Win2000/XP/OS-X drivers - as though this lacking made the card trash...which is rediculous. This is the kind of tripe I keep seeing now about Scope. These are tools for making audio/music - and are still quite functional at that.

I also draw a parallel here to experience as an IT Manager and the ire harbored by users that we weren't on the bleeding edge of software available on the market. Yet, the same complaintants could not enumerate a single functional issue with the deployed versions. Of course, they too had no insight into the economic implications beyond their own nose. Unfounded infatuation with technology is both expensive and dangerous, IMO. This may not be your case, however I see such threads bemoaning the lack of forward development by Creamware and wonder what the real issue is to cause such dissatisfaction. The situation with Creamware isn't ideal, but this stuff is far from dead.

Many would like to see updated drivers, and other forward progress, but I personally can't justify scrapping the capabilites offered by the platform. I guess it's a decision some will come to naturally as they progress along their own path, but to blame Creamware is a cop-out. Like a golfer who consistently buys new clubs thinking it will improve his game

If Scope is such a good thing (and I dare say it is) a way could be found...

Lot's of people still using gear that have zero manufacturer support.

Just my $0.02 Have fun with your new platforms!

symbiote · Post by **symbiote** » Thu Jul 07, 2005 11:10 am

32-bit supports up to 4Gb of RAM.

XP64 isn't even out yet, it's still beta software. Beta software tends to change alot until it becomes a proper release, so developing stuff for it at this point will lead to alot of modifications and wasted energy (as you have to re-do things 2-3-10 times that you can just do right the first time.)

I agree, Linux and OSX support would be a much preferable focus.

BTW, good look with your other platform. VST doesn't support 64-bit. Have fun =P

Shayne White · Post by **Shayne White** » Thu Jul 07, 2005 4:34 pm

DXi does.

Post by **hubird** » Thu Jul 07, 2005 4:40 pm

strange to see people subscribe here, just to say hey folks, I quit Creamware

@ Haim, if you subscibed earlier, you would have seen discussed that (XP)64 point to death, and very to the point btw.
You made a mistake, my friend

Btw, good 'subject' you choose: Very importmant for other users...completely right, but in the opposite direction

[ This Message was edited by: hubird on 2005-07-07 17:46 ]

Billy goat gruff · Post by **Billy goat gruff** » Thu Jul 07, 2005 5:40 pm

Interesting that as an experienced user you only now join this forum

(Edit: sorry Hubird, you already said that) ...........just to make this news public.

Methinks it's time to butt a troll off a bridge.

[ This Message was edited by: Billy goat gruff on 2005-07-07 19:07 ]

Post by **hubird** » Thu Jul 07, 2005 6:32 pm

mwrahhh...troll?

firubbi · Post by **firubbi** » Fri Jul 08, 2005 9:05 am

someone plz explane 2gb ram in 32bit.. so we cant put 4gb ram into our PC!!!!

On 2005-07-07 06:28, haim wrote:
it's about the RAM memory ... 2gb of ram ... only in 32bit ... that is the problem ...

firubbi · Post by **firubbi** » Fri Jul 08, 2005 9:16 am

@haim... is it already sold. how much do you want for that? plz reply....

..

Post by **garyb** » Fri Jul 08, 2005 12:11 pm

On 2005-07-08 10:05, firubbi wrote:
someone plz explane 2gb ram in 32bit.. so we cant put 4gb ram into our PC!!!!

afaik, this is a motherboard issue.

dehuszar · Post by **dehuszar** » Fri Jul 08, 2005 3:15 pm

Actually, I'm pretty sure it's a Windows OS design decision, as both Windows 2000 Server (through a hack) and Linux, have always been able to support more than 2GB (think about your average application DB server).

Tom? Any thoughts?

Sam

astroman · Post by **astroman** » Fri Jul 08, 2005 4:33 pm

On 2005-07-08 16:15, dehuszar wrote:
...
Tom? Any thoughts?
...

yes, but only one...

the first systems I sold had 128 Kilo(!)Bytes (50% of a Celeron's cache) of memory that had to be shared between an OS, a GUI, some application code and the data to be processed.
Yes, I did work - even with an application called Word 1.x those days.

My first multiuser server (Oracle6 under MacOS7) did run perfectly on a machine containing no more than 12 MegaBytes (for 10 clients)

dunno how much mem space that Oracle thing could adress, but it never was a point as you could simply distribute the database over several instances.
And don't expect it to be slow because the data had to be fetched from disk.
Such database engines have a guaranteed access cycle within a defined number of head-moves, which operates much faster in a huge amount of data than a stupidly programmed direct memory access

Performance depends on the quality of program code and the design of the application only - and nothing but that.
There are a few rare (or exotic) exceptions, but one 1, 2 or 4 GigaBytes en bloc are just pure nonsense or the inability of programmers to properly structure their data.
Give me one example where this memory amount is unavoidable.

cheers, Tom

at0m · Post by **at0m** » Fri Jul 08, 2005 6:11 pm

Here's a nice description of the memory limitations. We don't know the specific demands of his software, he should have better specified what he used Scope for. It's well possible that 2GB for some reason isn't enough. His description is just too vague to concern all Scope users.

Hey astroman, you keen on programming in assembler again eh?

darkrezin · Post by **darkrezin** » Fri Jul 08, 2005 6:19 pm

The only conceivable benefit of >2GB memory at this point is being able to use lots of huge sample libraries.

I've read the cakewalk white paper on 64bit CPU/OS for audio purposes, but I just don't really buy it.

The only thing available at this point is a 64bit cakewalk sonar beta, and that's about it. Seems slightly weird to jump in right now...

astroman · Post by **astroman** » Sat Jul 09, 2005 1:20 am

On 2005-07-08 19:11, at0m wrote:
...Hey astroman, you keen on programming in assembler again eh?

is there any relation between a programming language and the memory usage of the application ?
I actually use a data processing toolkit that happens to be coded in assembler (not by myself of course) and can take advantage of huge amounts of memory space.

Yet the performance increase is only up to a certain amount of data. There is a point where a certain access strategy is simply not appropriate. In other words: even if the data is loaded to memory access my be slow due to the wrong method.

But most important: you have to maintain data integrity and that WILL become a problem if your memory chunks get too big.

You do not even have the slightest chance to reliably update a (say) 1GB accounting file from PC memory under any current office OS.
It WILL fail one day or another.
Maybe a badly manufactured bit bucket on the chip, maybe a hit by a cosmic ray, maybe a user pulled the plug or whatever - a ton of things that can go wrong and are worse with increasing amounts of memory.

Therefore I really do consider the requirement of a 4 GB block as nonsense.

The 'load a huge sample lib to memory' example is the best proof against this strategy.
How long does it take to load a complex Akai lib of 1 GB to memory ?

Possibly a workable approach if it's your one and only lib, which you only load once without any changes at all - but what if things need to get off and new things into memory ?

On the other hand there's Giga - doing a one time indexing of the files and it just plays the stuff from disk even over a network.

Now, please tell me what approach is more smart - and in what format are the real big pro libs

cheers, tom

Post by **garyb** » Sat Jul 09, 2005 10:18 am

thanks.
of course the topic is nonsense, intentionally or not.