PlanetZ forums - scopeusers.com

I know you are,go on if TC can do it with their pci and pci-e Powercore then so the hell can you.Ok so you're not sure how the winds going to blow.Will it go towards pci-e or pci-x.Knowing you lot you've probably already done both, developed and tested the drivers to boot,Give us a clue dammit!!!!

who would buy a new card ?
for the full price... ?

I assume the majority of existing users would prefer a way to 'upgrade'... as loyal customer etc.

the original (years back) prices were tough, and could be, as there was a huge software bundle included.
now ALL existing customers have this software bundle - and (once nonexistent) competition is a concern (TC/UAD).

you can bet that they DID NOT do any evaluations of whatever bus system - they don't have the resources nor do they have the time, and chances for any 'returns on investment' are close to zero.

the mobile segment is expanding - laptops and MacMinis (or their noname equivalents), and there's the cashcow atm

all rumours say the next generation will be a networked box, ethernet, firewire, usb2 or whatever

cheers, Tom

I have a Fireface RME, and it works excelent with firewire (alot of bandwidth).

how i would love to have a firewire scope... that would be the killer producer instrument. the posibility to go anywhere there is a simple computer and record, synthesize and produce is just amaizing! studios are passe..

I said it once, but repeating it is not bad, maybe it will reach CWA ears:

The way to go is a box wich has a potentially very fast proprietary port plus a second small hardware in different versions allowing the connection on any kind of interface, present or future. So you can buy the Scope box, then you can buy a small device to interface it for firewire or pcmcia, or a small card to connect the box to Pci, normal, E or X, naturally you can buy various types so you hook everything to desktop in your studio, to laptop when you're around...

This way they should only upgrade the interfaces, keeping the core as is and most of all you could hook the same box to different systems choosing the best one when possible.

On 2006-08-27 07:10, alfonso wrote:
... a potentially very fast proprietary port plus ...
So you can buy the Scope box, then you can buy a small device to interface it for firewire or pcmcia, or a small card to connect the box to Pci, normal, E or X, ...

what makes you confident that a company of CWA's size (and resources) is capable to develope a new ultra-fast digital transfer format ...

...within the same move outperforms Magma as an established supplier

... and does all this for a lower price (otherwise there wouldn't be much need to start at all)

...This way they should only upgrade the interfaces, keeping the core as is and most of all you could hook the same box to different systems choosing the best one when possible...

I'd be more than happy if you could point me to one (real world) example where this degree of abstaction and code compatibility was achieved to at least 50%...

your ideas make perfect sense in context of a new design from scratch - though I'd still be concerned about the demands in developement resources.
To 'patch' an existing system in(to this concept) is wishful thinking imho.
oops - and of course... how is the protection retained between all those 'abstract' layers... ?

cheers, Tom

<font size=-1>[ This Message was edited by: astroman on 2006-08-27 08:46 ]</font>

Well astro,
no more developing efforts than redesigning the whole hardware for each interface everytime...at least they could focus only to a part of it, big work at the beginning and smaller efforts in the future.

I'm not an expert in any way, but it seems a logical project to me. I might be wrong though....

On 2006-08-27 08:43, astroman wrote:
I'd be more than happy if you could point me to one (real world) example where this degree of abstaction and code compatibility was achieved to at least 50%...

The new ASB boxes are the most relevant (real world) example. What creamware have there hardware wise is the beginning of a new era of SFP. As in Alfonso's suggestion, they have a uniform DSP based core mainboard throughout the range, with the only real differences between the different models being the 'interfaces' & interface (front & rear panel) PCBs. Obviously a larger & more complex version of what they have is essential for a new Scope box & it won't arrive on anyone's desktops this side of Xmas, that much is certain.

I think Alfonso's suggestion is maybe quite close to what Creamware might go for. Although developement & manufacturing costs might prohibit the developement of lots & lots of different interface options.

My one concern is that Creamware make the same mistake they did with the Noah & don't release any keyboard versions of their ASBs, thus detaching themselves from a huge market of keyboard enthusiasts & buyers. I personally think that would or could be a fatal decision profit wise.

On 2006-08-27 10:14, Shroomz wrote:
... I think Alfonso's suggestion is maybe quite close to what Creamware might go for. ...

from it's paradigm it actually is, but far from how Alfonso would like to see it imlemented (according to his description above)

that's why they will choose a 'network type' interface (complying to an existing standard), as it's the most straight forward way to deal with 'hidden hardware', via a software buffer, aka socket or whatever one preferes to call it.

Alfonso's suggestion is perfectly correct from the engineering point of view, as is his conclusion about 'less maintainance effort later'

The problem is the level of abstraction and complexity at 'firmware' level.
The abstract meta-interface needs driving software for each type of plugin (pci, cardbus, usb, fw etc) and for itself requires an integration into each OS.

This is far too much effort for such a limited market as the DAW's.
An ASB is in no way related to this type of interfacing - it's a classical bi-directional network interface.

(sidenote)
exactly this argument was used to switch a lot of developement over to C++ 15 years ago - resulting in overbloated code that yielded the opposite
It's unquestioned today that to fulfill proper re-usability requirements is far too complex and time consuming (expensive) for 90% of all software projects.

cheers, Tom

<font size=-1>[ This Message was edited by: astroman on 2006-08-27 12:10 ]</font>