The days of one G5 being enough are dead! Here comes the

[chrispick]

Originally posted by Timeline:
...it seems like handling various third party AU's in DP is currently being done very well so why not direct it to another processor on a dedicated MOTU card.

I agree; this is the more elegant solution.

The issue here isn't just the need more proc power for VIs (i.e., calculation), but also audio tracking access (i.e., hard drive data throughput). It makes sense to keep both aspects as localized as possible with minimum strain to the system. Dedicated procs and drives is the simplest way to do this, I think.

Third party companies like UA, Powercore and Muse already make dedicated processor hardware, so there's precedent. I think MOTU could profit by offering their own "AU accelerator card," to coin a term.

<small>[ July 26, 2005, 11:25 AM: Message edited by: heavypick ]</small>

[grimepoch]

I certainly think that everyone's points, problems and desires are valid, my biggest point is that the crux of this issue is larger than MOTU, and the solution is complicated.

For instance, one solution is for MOTU to create a node based approach like Logic that allows MAS plugins to run across network boundaries. There has to be a reason why Logic doesn't allow AUs to run across boundaries, and a lot of that is (speculation) due to the limitations of the AU structure.

The problem with a solution that addresses AUs specifically is that I believe the AU guidelines and structure are outside of the control of MOTU, this is an apple specific API and the hardware for which it would need to run, in my opinion, might not be worth the effort, or even worse, not give the performance that you want. AU's are written for the processor, in this case a PowerPC, so either there would need to be a PowerPC setup on that card or the functionality would have to be emulated.

Even further, you more than likely are not going to see the performance you'd want because a PowerPC is NOT a DSP chip, and DSP chips are MUCH faster since they are designed for that specific purpose. This is why these cards exist and work so nicely, however, they require code specifically written for them. This is why they are fast at what they do.

Just like someone else mentioned, the TDM system works so well because limits are placed already on what you run on it. This is not the case with the AU specification, it's open ended as it should be.

I spent a few years on the LADSPA mailing list while that plugin API was being created, the price you pay for flexibility is that it limits your guarantees. Even with this group of people there are such VASTLY different things being really wanted, it makes the problem not even complex, but in some instances, un-doable. I kind of relate it to the DJ problem, you can only play one song at a time so there will always be happy people out there dancing, and pissed off people because you aren't playing what they want.

Unfortunately, unlike the Access people, it seems here that MOTU doesn't want to discuss things. Do they even read this? Maybe. But us hashing out these issues like this between each other allows us to share our knowledge and experience, share our understanding of limitations and maybe solutions so that we know what we really want as well.

That said, would someone PLEASE make a 8 SPDIF(Optical&Coax)/AES/EBU to ADAT that requires ONE piece of hardware

[Timeline]

Thanks Rick, I've gained some knowledge from your posts.

I understand but have a few more questions.

If AU's are specifically written for PPC than what happens when Intel is online? Do they emulate to process the plugs then?

Do we see a drop in efficiency and would this not be the perfect time to produce a card as I described to keep the system fast.

[chrispick]

Originally posted by enc0der:
Even further, you more than likely are not going to see the performance you'd want because a PowerPC is NOT a DSP chip, and DSP chips are MUCH faster since they are designed for that specific purpose. This is why these cards exist and work so nicely, however, they require code specifically written for them. This is why they are fast at what they do.

That's a good point. Still, a dedicated PPC unit may not be such a bad idea. Something akin to Muse's Receptor, except for AUs instead of VSTs. Have it IO through a dedicated card maybe?

[grimepoch]

Let me add also, it's not a question of desirable or elegance, because I'd be at least the third in line for an AU accelerator, the question is if it's do-ab le. And I speak of this in terms of the actual AU software programming.

The elegant solution is one which takes any AU and accelerates it. No difference in the programming necessary. I've looked at plugin source code, I've written code to use them, I've studied the functionality of the realtime access to them. I don't think it is even remotely simple, and from an architure standpoint, you are really just adding another processor to the system. The fact that it is dedicated doesn't make a huge amount of difference.

I think we should be asking Apple for 4 or 8 core processors, and at the same time, asking MOTU for better cross computer boundary solutions. Why use ethernet? Why not create music bus like mLan? Ethernet is horrible in the latency department. If Xgrid is available today, why aren't we using that? What are the latency guarantes of Xgrid?

What about running soft synths and using an xwindows type system to display them on your main system? I've done this with VNC on my Reaktor machine, and VNC is built into Tiger now (vncserver).

Hell, the TWO single things that MOTU could do to make me amazingly happy are this:

(1) Freeze as fast as possible
(2) Allow over-firewire audio/MIDI connections between computers.

[grimepoch]

I should clarify, the specific versions of the AU's we've received are compiled for the PowerPC. When the mactel systems ship, I've read that OSXi does in fact have PowerPC emulation built into it for legacy application support. There are some benchmarks out there, definitely not something you are gonna want to run for long.

The plugin writers will have to compile their plugin for the mactel chipset, and hopefully, will still provide both for us with older hardware at that time, code that is compiled for the PowerPC.

If a plugin uses stuff like Altivec, well, I am not sure what happens. Do the mactel compilers do a good job of changing the machine code for what is available in the intel processor? I am sure that is a GOOD question. However, for those that have created their plugins for different processors, they can probably bring any special optimized code they wrote over from their wintel version. Some might write high level enough that this isn't a problem at all.

I don't think a plugin PCI processor is a bad idea, but I don't know enough about OSX to know how hard it would be to get the OS to use it, or, what sort of limitations it would have with the PCI bus.

To me the biggest problem with multi-computer solutions is that none of us wants to be using a bunch of monitors from different machines, or having to go load up a bunch of things differently on each machine for every session with clients and such. I just use the same instruments on the other machines right now, but every once in awhile, I'd REALLY like to use something different.

To think out loud, if I could control a bunch of machines from one master session of DP, it would be most productive. Any maybe, even hook them all together through firewire, this way, you could still use devices like powerbooks and the mini if you just had them sitting around. Sure, there are limitations still to this, but it might be a nice avenue to getting there.

I'd like the GUIs to display on the main machine. I'd like to run the other machines as headless as possible, meaning, I realize that starting/stopping DP (or some DP Node) might require input, and other OSX related issues on that machine. however, when I have DPNode running on the secondary machine, I want the main DP box to completely control it.

I would like to be able to channel audio and MIDI to and from the other device, and route the inputs and outputs to the other device. Even further, I'd like all those settings stored on the main system.

This is one solution. This is not processor sharing, but concurrent setup solution and automation.

Outside of that, I'd like to explore processor sharing. in other words, Xgrid. If you are connected over 10Mbit, 100Mbit, 1Gbit, what kind of performance hits are you going to take? How does it choose which threads to push over to the other system? What kind of latency are you going to see? Should you install a separate interface for it and remove any other networked devices including the internet for the fastest throughput?

What about developing a new connectivity standard? Serdes processor bus? Just for superthreading? (This is the term for using processors across computers).

Which brings up a new point, and maybe some of you have researched this, I have not. Massive compute farms don't indicate their real time use. The turn around latency may be too high with existing code, and maybe that's where a problem is as well.

I am sure most of you have heard the analogy that a stationwagon full of backup tapes delivered over the freeway is faster than a T1 connection will ever be. Point being, what we need to know is how well a computer farm will work for us in realtime situations. I think this has been where a lot of the problem comes from.

[richardein]

Jayman, I'm not sure exactly what Slave was referring to, but I think he was alluding to a very expensive system consisting of, say, xserves networked via pci fibrechannel cards - the card itself adds $500 to the cost of each machine. How Supernode itself would fit into that isn't clear from the Googling I've done but I suspect the point of using fibrechannel with the node software is to create a very fast and powerful "single computer" comprised of a group of xserves.

That is, to the enduser, it looks like you're using a single box , but that box is actually comprised of a bunch of cpus, with vi's and plugins utlizing the available power as if it were one machine.

Hope that's clear. This concept is, technologically, much more sophisticated than the MIDI Networking and audio networking we've discussed elsewhere. I dunno if software is commercially available that can do that for the mac and Core Audio. If there is, then that would certainly address the issues discussed on this thread in a very impressive fashion. There may be some proprietary software (I've heard rumors about some in places like Hans Zimmer's Media Ventures or at Skywalker) but I haven't heard of anything off the shelf.

[Timeline]

I see what you mean.

I really don't want to deal with a bunch or even two PPC's even if Serdes processor bus & superthreading was supported.

I have to fly around and have to bring this stuff with me from time to time and laptops would be great but not at 24/96 x 50 tracks.

I shipped my G5 recently to Nashville for overdubs and it was a pain in the ass and that's just one friggin machine.

I guess only MOTU and the brains in Boston could narrow in on this PCI card concept and tell us what could or couldn't be gained. I sure wish MIT dudes were viewing some of this!

Thanks again for a great conversation

Cheers

[grimepoch]

Completely understood, I use my studio in one location, so my needs in this are different. As I am sure almost everyone's are.

To me, it is very educational to learn what others are using, and how they are getting by.

I've also not used Xgrid, I was told that the code that uses it has to be compiled to use it as well, which might be another problem. Maybe in DP you can wrap a thread around the AU executing routines that you can then throw off to another system. If I knew MOTU even cared I'd research it, but I don't see a point in trying to find a good solution if all I could do is mention it here

The part about Logic that bothers me is that it is in their interest now (Apple) for DP not to be great compared to Logic, just like the fact they won't talk about how they are doing the node processing. Not that I don't blame them, I know they want to sell more software, but it certainly seems like a conflict of interest if the MOTU people want to work with Apple on certain aspects? DP is dependent on the OSX architecture, and core audio, and certain limitations there, and with the execution model of OSX that are limiting and outside of MOTU's control.

Imagine what routines are going on behind the scenes in OSX that you have no control over? That are can cause a spike? A blocking IO? Memory swapping? Checking your email? I bet there are a lot of optimizations that can be made if we knew what we didn't need in the OS and what we do.

But then again, this is the difference between dedicated hardware and hardware that is generic in use.

There are SO MANY variables here, and everyone has touched on them. Hard drive speed, bus speed, memory speed, latencies, various interfaces. More VIs, less VIs, harware DSP cards. I run at most 20 tracks at once, some people WAY MORE, some people WAY LESS. I think what a lot of people want is to know what they should expect out of their system, or when they know something is wrong and they aren't getting the most out of it. That was one of the reasons I joined this list specifically.

And seriously, the only way I think to know is doing just what we are, talking to other people who have these setups, and are using them, to see what kind of performance they are seeing.

Now, I feel better about my setup. It would be nice to be able to give people solid facts about performance, but again, the variables, which when people ask questions about why something isn't working, the first response question is (DP version, OSX version, Memory?, Dual Processor?, Interface?) And we all do seem to have answers for people

What I think is funny, is that the most processor hungry VI that I use feels like it is MX4, and that is MOTUs! Which hopefully means they use that as a metric when optimizing!

[Jaysplace101]

nothing to say..... just wanted to be the one to push this thread over 100 posts.

j

[jr213]

NOW it's OVER.

<small>[ July 26, 2005, 03:05 PM: Message edited by: jr213 ]</small>

[Jaysplace101]

Jayman, I'm not sure exactly what Slave was referring to, but I think he was alluding to a very expensive system consisting of, say, xserves networked via pci fibrechannel cards - the card itself adds $500 to the cost of each machine. How Supernode itself would fit into that isn't clear from the Googling I've done but I suspect the point of using fibrechannel with the node software is to create a very fast and powerful "single computer" comprised of a group of xserves.
That is, to the enduser, it looks like you're using a single box , but that box is actually comprised of a bunch of cpus, with vi's and plugins utlizing the available power as if it were one machine.

Hope that's clear. This concept is, technologically, much more sophisticated than the MIDI Networking and audio networking we've discussed elsewhere. I dunno if software is commercially available that can do that for the mac and Core Audio. If there is, then that would certainly address the issues discussed on this thread in a very impressive fashion. There may be some proprietary software (I've heard rumors about some in places like Hans Zimmer's Media Ventures or at Skywalker) but I haven't heard of anything off the shelf.

If only we could get our hands on something like this! Golly, it would kill. I really wonder if it's actually out there. Seems like the technology is there. If Slave would just come back and fill us all in!

j

[qo]

Interesting discussion. Somewhat OT, but Rick, I share your concern about Apple's move to compete in the DAW space. You're absolutely right that it results in a relationship that is risky and less beneficial than it could be. Can MOTU be expected to feel comfortable explaining to Apple that, if they could modify OSX a tad, to provide app developers with some service, foo, then MOTU would be able to come out with [insert mind-blowing feature (MBF) here that will revolutionize the DAW market]? How does MOTU ask Apple for foo without revealing MBF (as a means to justify the need for foo).

In some cases, it's certainly possible to make a case for an OS change, without revealing MBF, but not in all cases. Too, what incentive does Apple have in implementing foo, if foo is not requisite to growing Logic's market share?

Frankly, I was shocked when the Emagic/Apple deal was announced. It's been bad for Logic users specifically, IMHO, (support charges added at a time of increasing application unreliability), and it's been bad for music production on the Mac in general.

Now, I realize that Apple is a business and can do whatever it damn well pleases, so long as it adheres to applicable law. If someone asks for a modification to OSX, Apple has every right to ignore it. The point is simply that the conflict-of-interest waters are muddied a bit by the turbulance of competition.

<small>[ July 26, 2005, 04:54 PM: Message edited by: qo ]</small>

[chrispick]

Originally posted by qo:
Frankly, I was shocked when the Emagic/Apple deal was announced.

I think it came on the tail of their unexpected success in the film/video NLE market with Final Cut. Suddenly, the pro-level A/V market was too lucrative to pass on to others.

Prior to that, Adobe Premiere, Media100 and Avid were Mac NLEs of choice. Now, only Avid has remained on this platform. And that may only be because many pros -- and, more importantly, their clients -- will pay their exorbinant premium because the brand name is synonymous with pro-level product. Avid owns Digidesign, should that business motif seem familiar.

<small>[ July 26, 2005, 04:11 PM: Message edited by: heavypick ]</small>

[sdfalk]

Media 100 is still on the mac..unless this just happened.