Pt9 Input limitation request.. NOT increase.. Just change how it works

[Shonk Studios]

I'm fine with having a 32 channel I/O limit...


BUT

it would be really useful for those of us with more I/O hardware available than the 32 limit, if the mechanism of limits was changed to be a limit on the number of input and output paths available...

rather than apparently simply counting across the first 32 hardware inputs presented by the interface driver.

currently I have 48 I/O , I only want to use 32 of them, things like Loop backs and SPDIFs and a spare set of ADAT ports being redundant, however, because some are presented in the hardware driver before the ones i actually want to use, they get counted in the limit total, despite having no paths assigned to them


if the mechanism was changed, to allow 16 stereo paths, with functional mono sub paths, I could assign my analogue I/O and ADAT I/O accordingly, and make use of all 32 inputs....

currently i can only use 26. ( although we might only be using 16-24 mics, we also need to track multiple synths, and stuff on occasions, and use inserts for hardware , and other such I/O eating techniques)


irritating../..

the above method would still protect the HD version, by keeping the current limits, but enable those of us with more complex studios, to configure our Protools sessions with I/O assignments that reflect what each session is required to do.


COME ON AVID, sort it out....


(currently, i have to track in Logic, which is entirely capable of everything i need to do in larger sessions.... but we WANT to use protools , it's what we prefer.... )



Max

Shonk Studios, Oxford UK


(obviously i'm submitting feature requests by other channels, i just thought the subject being raised and the idea being propesed might be of interest to others. )

[The Elf]

I have the exact same gripe using an RME Fireface 800 and a pair of Behringer ADA8000s. This is a serious limitation.

[Shonk Studios]

The Ideascale thread has now gone Live....

if the issue outlined above bothers you as well, please get in there and vote.... !!

http://protools.ideascale.com/a/dtd/...mit/81527-3779

[Top Jimmy]

Why don't you complain to the interface manufacturer. MOTU for years has had routing enable/disable in their PCI interface drivers. Use a MOTU PCI interface and you can disable all the inputs that you don't want to show up in your DAW software.

[Shonk Studios]

Already submitted feature requests to Focusrite.... but look at it like this.... The suggested change deals with ALL interfaces from EVERY manufacturer... in one go..... a more efficient use of development man hours overall than every single multi channel interface driver that lacks the MOTU's ability (AFAIK, it's only the PCI424 units that have this.... ??? could be wrong though) having to rewrite their drivers to implement it....


obviously my preferred option is for everyone to fix it at both ends, and then we have the best of all worlds.... and all sorts of options,...

for example, lets say that you might not want to use the SPDIF and loopback and ADAT2 on your Saffire 56, with Protools, but you might want to do so with Logic, or stand-alone softsynths, BFD, or whatever.... bit of a pain if you want to run them at the same time as PT... having had the I/O you wanted to use turned off so you could use PT....


if the fix is implemented in PT, then the hardware remains available for other applications... or , monitoring thru the interface's zero latency mode, or a whole host of other possible uses.


it's not like i haven't thought it through

[DigiTechSupt]

Already submitted feature requests to Focusrite.... but look at it like this.... The suggested change deals with ALL interfaces from EVERY manufacturer... in one go.....

Not exactly - due to driver differences between interfaces and how it's implemented it's not as easy as it sounds to just have Avid do it. The test grid would become even more enormous if we had to implement the code and try to test it on every interface out there. As you can see by perusing the DUC there are quite a few reports of various anomalies with certain interfaces - indicating the driver quality can vary significantly. By having the manufacturer develop the solution, they have to test only with their interfaces - and, as long as the driver is providing the correct info to Pro Tools about available I/O, it should 'just work'.

That's NOT to say we can't or won't do something - I was just pointing out that it's not as simple as it looks.

[Shonk Studios]

Thanks for the input. Much appreciated...

My reading of the way it currently works, implies that PT9 simply counts across the first 32 available inputs and outputs, as reported to it by the hardware drivers. and then stops accepting them as valid .


the suggestion being, that instead of what appears to be a simple, 32 then off, structure to the limitation.... remove THAT limitation, and replace it with an application specific coded limit on the number of input and output paths that can be created in the I/O set up grid.

as i understand it (from my admittedly rather neolithic days as a programmer) the interfacing between PT and third party devices doesn't then change other than having the limit removed from the I/O stream (which already exists in the HD version) . all the limitation is internal to PT and the facility to create I/O paths.



(mind you it's been a while since i wielded a keyboard to write code for anything.... and even then i wrote payroll applications for government departments.... not audio DAW's )


I am irritatingly curious though.... as a purely academic exercise, with no plans to retrain as an audio DAW coder... i'd be geekily interested in what might make it more difficult than i have presumed...


just as it is.... I'd dearly like to see this dealt with....


(but acknowledge that by the time it is, i may have lost patience, given up and bought an HD Native system)

[klira66]

Hi there.

I have only just discovered this extremely annoying PT9 I/O limitation. After swinging between PT9 and Cubebase for my new studio, I went with PT9 thinking 32 I/O would be more than enough, as the heart of the studio is a beautiful old 24 track 2" tape machine.

How WRONG I was! 32 I/O shrinks to 20 analog I/O at 96K. The only way around it is to record at 44.1k which completely defeats the purpose of getting Protools in the first place!

They HAVE to change this - as I sure as hell don't feel like going out and buying Cubebase after blowing $600 bucks on PT9 for such a seemingly futile limitation. May the revolution begin!

[Shonk Studios]

Hi, how is your i/o shrinking to 20 at high sample rates?? (not yet tried this, as one of my interfaces is an old apogee AD8000 which tops out at 48K ,)

isn't this your interface and maybe ADAT SMUX mode causing it?? rather than PT9's I/O limitation..... or is there a PT9 issue i'm unaware of??


(note to self, go play with 96K sample rate this weekend./.. )

[Dism]

Originally Posted by klira66

Hi there.

I have only just discovered this extremely annoying PT9 I/O limitation. After swinging between PT9 and Cubebase for my new studio, I went with PT9 thinking 32 I/O would be more than enough, as the heart of the studio is a beautiful old 24 track 2" tape machine.

How WRONG I was! 32 I/O shrinks to 20 analog I/O at 96K. The only way around it is to record at 44.1k which completely defeats the purpose of getting Protools in the first place!

They HAVE to change this - as I sure as hell don't feel like going out and buying Cubebase after blowing $600 bucks on PT9 for such a seemingly futile limitation. May the revolution begin!

It's definitely a limitation of the interface and NOT Pro Tools.

Pro Tools doesn't care what interface you are using, provided it doesn't exceed 32 I/O.

If you increase the samplerate on any ADAT interface higher than 48k, the available channels are ALWAYS halved and revert to SMUX (provided it has SMUX capabilities) to handle the higher samplerates.

Please read the documentation that comes with your interface before blaming the software.