CURE for AMD 8131... CHAINED Plug ins!

[Trace]

Yes its back again. The call for UA to make Chained versions of their Plug ins is back. I know we never got an answer from anyone at UA on the feasibility of getting a chainer, but its easy to see that we REALLY could use one or something akin to it. Even if they came up with a SUPER CS-1 using their best plugs, i'd take that. 99% of the time I use the plugs in a predictible Channel Strip fashion and that would be the most useful and basic thing they could do. I see NO REASON why they can't at least do that. It would cut down on the audio transfers tremendously.

PLEASE UA, PLEASE give us something along these lines.

James I know you're out there somewhere and silently reading this. There are so many of us who have PCI-X G5's that would LOVE you guys is you could do us this one long time user request.

TRACE

 

[cAPSLOCK]

I have also often thought that if not a completely free form 'chainer' then two or three Nigelesque plugin groupings (racks) would be nearly as good, as long as we could change the routing order. Say a LA2A/1176/pultec-pro/Cambridge rack (in ANY order). This would solve 80+ % of my needs.

Of course, once they did this people would clamor for other configs.. So in the end a nice open rack would be the best of all While I am wishing it would be cool if it was fully routable so you could do parallel stuff with it as well as serial.

I just have a feeling that many UAD1 complaints could be lessened by such a thing. Less PCI bus trafic, lower latencies, and probably less native CPU use... Lovely.

I understand this may not be as high a priority as a new plugin, and I know the topic has been beaten to death... but it just seems like such a great idea!

cAPS

 

[xist2005]

I agree and cross my fingers

 

[Trace]

I would also welcome a stand alone Mixer app! I was thinking how nice it would be to be able to have a UAD Mixer, that was basically a series of channel strips and a rack of effects for Busses. I thought that was what would happen with the UAD 8I/O, but if they could somehow manage that it would also be a nice side product.

Anyway, back to the matter at hand. I can run something like 74 EX-1's successfully in my 2x1.8Ghz PCI-X G5. That was the high water mark for # of instances I can run. The limitations of the AMD PCI-X Tunnel make it impossible to get more out of my 4 UAD's, which I have in a Magma Chassis.

Giving us a Chained Classic Channel Strips using the 1176/LA2A/670/Pultec/Cambridge plugs would allow us to scratch a bit more out of our systems. They could call it the CS-2 and we'd have access to all the top UA Classic plugs in a neat channel Strip, with which we could enable just the plugs we need. Cutting down on the PCI traffic to and from the Card and lowering overall latency as well.

MAN I WANT THIS!!!

TRACE

 

[Trace]

Come on UA throw us PCI-X users a bone :0 CHAINED CLASSIC CHANNEL STRIP! This would lower the number of audio streams to and from the UAD-1 and i'd still be able to use my favorite plugs in one neat and efficient Plug.

1176/LA2A/670/Plate 140/Pultec/Cambridge plugs in one CS-1 style plug. You could make the Main window a simplified version of the normal GUI for each plug, with buttons in each section to click that opens the full edit GUI for each plug independently.
So if I want to tweak Fairchild 670 I just click on the Edit Button in the CS-2 and it opens the 670 Window.

Come on I know you guys can do this and it would make for a very efficient option, less Dithering and conversion, everything stays in the UAD til its finished, so only one Buffer cycle of latency too.

TRACE

 

[cowudders]

I still think something like the TC FX-Machine matrix (with preset saving) would be the way to go.

A 6x5 matrix with some little helper plugs like M/S, Pan/Volume and feedback options ....
This would be a monster!!

check out, how metric halo does it with their +DSP plug-ins:
http://www.mhlabs.com/metric_halo/products/mio/dsp/

For me and my kind of 'working', something like this would double the value of my two UAD cards! no bull.

cheers,
bernd

 

[Trace]

Yeah that looks real nice. It would seem like that wouldn't be too hard to do. I really don't understand why they haven't done this already. It seems to make so much more sense than the way they do it now, with all those audio tranfers across the PCI Bus. That is so inefficient. All that extra latency, the added dithering and sample rate conversions. It makes perfect sense to have the signal stay inside the UAD til it's finished. I REALLY HOPE they read these posts and consider this option seriously. Its not a very glamourous feature, but its a really good one functionally. MAN I WISH I HAD THIS NOW.

TRACE

 

[cowudders]

It would seem like that wouldn't be too hard to do.

Well, they could do it, for sure. 'Not hard to do' - I really don't know. I know also nothing about this chip, how the plugs load, if UA's architecture allows for that, etc.
And UA doesn't want to comment on this, so it seems ...

Its not a very glamourous feature, but its a really good one functionally

I disagree about the 'not glamourous' part.

cheers!
bernd

 

[Trace]

Well, they could do it, for sure. 'Not hard to do' - I really don't know. I know also nothing about this chip, how the plugs load, if UA's architecture allows for that, etc.
And UA doesn't want to comment on this, so it seems ...

Well the UAD-1's Processing unit is very flexible. It was designed to handle Audio and Video playback. Its a programmable DSP unit which allows it to take on added functions. Its that nature of the processor that made it possible for it to be used in the way we use it now. It really doesn't seem that its beyond the scope of what it can do. It seems only a matter of programming the actual plug in. Perhaps its a similar problem that kept them from coming out with the UAD 8I/O. I figure that if they can easily combine algos like the Pultec Pro, Nigel or a CS-1, then the same process could be used to create a Channel strip using all their best analog emulations or a plug like the FX Machine, which is freely configurable.

Since we've never heard a peep about any of this from UA over the years I would guess that its something they either can't do or have had a lot of trouble executing. I hope its not that they just don't want to commit the manpower to the task, for a plug that would probably have to be a free upgrade. I can't imagine that they would be able to charge for it. I'd pay for it, but how many others would.

TRACE

 

[streetbeats]

FWIW that MH DSP stuff doesnt look like it runs in the host at all...but in its own layer...

 

[cowudders]

I hope its not that they just don't want to commit the manpower to the task, for a plug that would probably have to be a free upgrade. I can't imagine that they would be able to charge for it. I'd pay for it, but how many others would.

I would, if there's something more than 'just' chaining. Like flexible feedback loops & preset (configuration) saving.

One could build big effects, normal ones like wicked Multiband Comps or strange stuff, which you can setup right now, but are a pain to reproduce in other projects ... and the benefit would be less PCI strain, too.

FWIW that MH DSP stuff doesnt look like it runs in the host at all...but in its own layer...

It runs on their 'MIO console', which is the equivalent to RME's totalmix or MOTU's cuemix. It's just an example how flexible AND simple such a matrix could be.

cheers,
bernd

 

[UAJames]

Hi guys,
Sorry I hadn't posted earlier, but I wanted to be official on this one:

The \"Chainer\" concept is just one of hundreds of feature and plug requests we are continually evaluating for each UAD-1 OS Upgrade. The Chainer has not been \"rejected\" but it has been deferred for other fast-to-market features and plugs in the 2005 roadmap. The \"chainer\" is also a sophisticated change to UAD-1 software. UA always considers user requests and forum feedback BUT we carefully have to balance these features against available development resources, technical complexity/platform stability/testing, time to market and business revenue while at the same time keeping up with the pace of developments in all host applications and of course evolutions in the Mac & Windows OS. This is a complex equation, but the bottom line is continuing to make consistent releases that are both valuable to our customer base, maintain our consistent quality level and fit into the overall product/business strategy of the company.

 

[Trace]

Fair enough I can understand that. I'm glad that you took the time to explain things from UA's point of view. We can only see things from our perspective of what we want, but having heard the other side of things gives me a different look at the whole process of what gets done according to your company's business schedule.

Thanks for finally commenting on this topic. As you know its been discussed before on the PC Forum and I have a personal desire to see it happen one day soon, so I hope its not far down on the que

TRACE

 

[cowudders]

Thanks for your comment, James!

cheers!
bernd

 

[xist2005]

Maybe if all (or at least many) PCI-X & Uad1 users would sign a sort of online petition, things could change in UA's schedulings...
anyone able to make it?

 

[streetbeats]

Hi guys,
Sorry I hadn't posted earlier, but I wanted to be official on this one:

The "Chainer" concept is just one of hundreds of feature and plug requests we are continually evaluating for each UAD-1 OS Upgrade. The Chainer has not been "rejected" but it has been deferred for other fast-to-market features and plugs in the 2005 roadmap. The "chainer" is also a sophisticated change to UAD-1 software. UA always considers user requests and forum feedback BUT we carefully have to balance these features against available development resources, technical complexity/platform stability/testing, time to market and business revenue while at the same time keeping up with the pace of developments in all host applications and of course evolutions in the Mac & Windows OS. This is a complex equation, but the bottom line is continuing to make consistent releases that are both valuable to our customer base, maintain our consistent quality level and fit into the overall product/business strategy of the company.

Just out of interest James re what you say here......Do you use a defined RM process and support it with a good tool ?

 

[UAJames]

Sorry, I don't think I understand the question...

 

[streetbeats]

Just wondered if you use any formal requirements management for dev there ?

 

[UAJames]

About as formal as can be What I mean by that is we do have a formal development plan and schedule, however, it can be easily knocked a bit off by a feature change in a major host, or change in the OS, computer hardware, or features suggested by users. So for example over the course of the last few months, with the 8131 G5s, major updates to Logic/DP, Tiger, and our normal planned release schedule, resources have been spread out pretty thin. Also, and I'm sure this is true with most software companies, new features and proposals are usually re-evalluated for each release and determined, based on time and resources, if they can be added. So usually at the start of a new release we review all the possible new features and figure out which ones will be able to be added with the least impact on the schedule. At this point, the chainer will impact more than we can afford, so we defer to features that can be implemented without such impact, or features that have been in the works for a while. It's one of those situation where if we did attempt to do a big project like the chainer now, we would fall behind on our normal schedule, and have to spend extra resources just catching up, which could have been spent on adding features along the way.

 

[streetbeats]

Hey James

Sorry I didnt mean for you to have to write a full description of how you do your release management / scoping. My day job is as an RM consultant for a company called Telelogic (http://www.telelogic.com - check out DOORS and Focal Point).
I was more wondering about what level of detail you capture your requirements at, whether you decompose them into lower level reqs, whether you use them as the basis for your testing, whether you have tracability between these different entities, such that when change inevitably happens, impact analysis is more easily facilitated etc.. ?
Dont feel you have to answer these questions on a public board if you dont want to btw, Im just curious as its one of my interests

cheers.