This is probably a thread for VIMac-Audio or MIDI-Mag, but, in short, those settings aren't in preferences. I'll have to go back to look, but they're either in the main or mix windows, similar to GB.
Bryan -----Original Message----- From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On Behalf Of Ginny Owens Sent: Wednesday, June 30, 2010 11:23 AM To: ptaccess@googlegroups.com Subject: LogicRE: Update Summer 2010 Bryan, Speaking of "small parts" of programs where lack of accessibility is maddening, have you by any chance found a way to turn off the click during recording in Logic and to manually set the overall tempo? I'm using a control surface to overdub multiple tracks of audio, which is working fine. But I can only seem to shut the click up during playback, and since I can't set the tempo, well...it's maddening. Lol. I'm going to try searching through recording settings again, but any thoughts would be welcome. -----Original Message----- From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On Behalf Of Bryan Smart Sent: Wednesday, June 30, 2010 10:08 AM To: ptaccess@googlegroups.com Subject: RE: Update Summer 2010 Slau already wrote you a great reply. However, I'd like to remind you, when it comes to Logic, that Apple purchased that program from EMagic. They didn't write it in-house. Beyond that, Logic has been around since well before Cocoa. It was a Carbon app first, and ran on the classic Mac OS before that. Such programs are bears to reorganize without breaking everything. And, in the case of Logic, on the whole, it is actually extremely accessible. So is GarageBand, for that matter. The infuriating thing about those apps is that the tiny parts that aren't accessible are profoundly crucial. For example, I can work almost everything in GB, all the way down to editing effect and synth presets in their native user interfaces. However, I can't select any recorded data, so can't edit. No editing pretty much rules out GB for anything serious. In Logic, I have a similarly high level of access, but can't access the part of the interface where the mixing console is displayed. Cocoa does mostly work out of the box. When problems appear, it is usually that controls aren't labeled, but VoiceOver can see them, at least. If you figure out the purpose of a control, either through trial and error, or if a sighted person tells you, it is possible to label the control with a VO hotkey. In the inaccessible places of programs, like Logic, those aren't even using Cocoa controls. There aren't as many situations on the Mac where developers avoid using a standardized toolkit like Cocoa for appearance considerations, as is common on Windows. Cocoa applications can replace the look and feel of a standard Cocoa control (like a button), while retaining all of the built-in functionality. On Windows, if you want a button that has custom 3D effects when you press it, so to make your software synthesizer look like a real synth, your only choice is to reinvent the wheel. With Cocoa, you can replace just the part of the button that handles how it is drawn. No developer wants to reinvent the wheel if it isn't necessary, so most of them use Cocoa, and tweak it for their needs. A developer making their own custom button, like above, might draw the label on the button. In that case, they might skip setting the title attribute on the button, so VO wouldn't be able to tell you the name of the button. It still could, however, tell you that there is a button, and it can press it. No problem, though. You can set a custom label for that button, or, if someone has already set such a label, they can share it with you. Bryan -----Original Message----- From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On Behalf Of Scott Chesworth Sent: Wednesday, June 30, 2010 9:41 AM To: ptaccess@googlegroups.com Subject: Re: Update Summer 2010 Hey Brian, Sure, I know enough to understand why the accessibility wasn't present in OS X for so long, and can certainly appreciate that with an app as vast as PT with the client base it has, an interface rewrite is a huge undertaking that would have to roll out gradually. I suppose the concern stems from hearing that the guy Avid hired initially worked on accessibility specifically for a period. What that makes me wonder is, was he manually exposing areas of the UI that were still Carbon-based for us so that we'd have the key components of the app available, or was he going through and playing catch up with the parts of the UI that other coders had already rewritten in Cocoa. If it's the former then I'm likely worrying over nothing, but if it's the latter, and this chap who was a temp at Avid was the only person who had a firm grasp of Apple's accessibility documentation, then surely the process would need to be repeated and accessibility will appear in chunks at that point rather than happening automagically as Avid update their UI. I'm not a developer by any stretch of the imagination, so I don't know how accurate Apple's whole "Cocoa just works with VO out of the box" line really is, but I'd feel a lot more confident about the future if every Cocoa-based app I'd ever downloaded worked like a charm (which it hasn't), or even if Apple's own product line was playing ball by now (which it isn't). I dunno, perhaps I'm hypersensitive and overanalysing because I had some momentum and something that appeared to be a career developing last time around. It gradually had to grind to a halt because lugging around my own outdated gear and dumping it in the midst of every session wasn't always an option. I don't want to be in that situation all over again man. Scott On 6/30/10, Bryan Smart <bryansm...@bryansmart.com> wrote: > I don't think that you need to worry. > > I'm not sure how much of all the future plans and such are supposed to > be discussed on this list, but Avid is involved in a long term plan to > update their user interface. Part of the accessibility problem was > that the interface was created using Carbon, and was originally > created early on in OS X days, before there even were the > accessibility features for Carbon, and certainly way before Cocoa was > available. They're updating their interface for lots of reasons that > don't even have to do with accessibility. As the interface is > modernized, VO users naturally receive many benefits. As they go > forward, there will be less and less of a need for them to do anything special for VO users. > > Bryan > > -----Original Message----- > From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On > Behalf Of Scott Chesworth > Sent: Wednesday, June 30, 2010 4:20 AM > To: ptaccess@googlegroups.com > Subject: Re: Update Summer 2010 > > The word "feature" and "accessibility" in the same sentence always > makes me uneasy. No, I wouldn't expect Avid to have a VO guru on hand > to figure out the most efficient workflow for me to get something > done, just like I don't expect every support techie to have the > knowledge to instantly switch off the "drag and drop" terminology in > his script every time I call Apple, but if a task isn't achievable via > the keyboard or isn't achievable with VO due to elements not being > exposed or being incorrectly defined etc, surely it's not unreasonable > to expect acknowledgement and response to that. In most cases it would > after all, be an issue that could be fixed with no specialist > knowledge of anything more than Apple's developer guidelines. I > suppose what I'm getting at is this. VO support not being publicly > stated (even the current partial VO support puts them ahead of the > game compared to Apple > themselves) makes me uneasy that we're not going to be publicly > acknowledged as a userbase either. So, if that's the case, what > happens about new features or interface tweaks from here on in? As I > said, I totally agree that Avid implementing Apple's accessibility > guidelines is the most that we could expect from them, and I am > grateful for what's been implemented so far, but consistency is key to > this being a viable product for VO users to be able to rely upon it > professionally. I have to wonder whether implementing those guidelines > and ensuring that new features aren't going to be totally beyond users > of accessibility will be considered as part of the development cycle, > or whether the best we can expect is playing catch up every few years. > > I'm not intending to knock Avid. It's just this whole notion of > accessibility as a feature really, really bugs me. > > On 6/30/10, Slau Halatyn <slauhala...@gmail.com> wrote: >> I'm preparing an update for the web site at ProToolsPetition.org. For >> what it's worth, I'll post it here first because it probably won't >> post to the web site for another day or two. >> >> Update Summer 2010 >> >> It seems that the fruits of many people's labor are finally beginning >> to show. After years of interfacing with Digidesign, now known as >> Avid Technologies, we're seeing the results of our efforts to gain >> access to Pro Tools. Changes to the code base of Pro Tools that make >> it easier to navigate the user interface with VoiceOver in OS X were >> implemented in version 8.0.4. >> In early June, the HD version was released with the LE and M-Powered >> versions to follow soon. >> >> While there was a great amount of work done to help make Pro Tools >> useable with VoiceOver, it is by no means a completed project but >> rather a work in progress. While major aspects of the application are >> accessible, there remains some areas that will need to be addressed >> in future versions. We always knew that the issue of accessibility to >> Pro Tools would need a long-term solution. We hope to see >> improvements to be rolled out over several releases in the coming years. >> >> Although Avid Technologies has made changes to Pro Tools to >> specifically work better with VoiceOver, it has no plans to announce >> it as an official feature, per se. Regarding it as a feature would >> imply thorough testing and full customer support from the perspective >> of usability with VoiceOver. >> Naturally, one wouldn't expect Avid to troubleshoot issues regarding >> accessibility and the use of a screen reader. Essentially, what Avid >> has done is they've begun to label UI elements according to Apple's >> programming guidelines. The rest of the user experience has more to >> do with how VoiceOver works and best practices as blind users of the >> operating system and application software. >> >> Again, since this project is still a work in progress, it's still >> somewhat experimental as we discover what works and what doesn't. >> Although Pro Tools is not yet 100% accessible in all of it's areas, >> I'm glad that the work done thus far was included in the 8.0.4 >> release. It will allow blind users to begin learning the Pro Tools >> environment and workflow with plenty of features to explore and >> master. In the mean time, Avid is aware of the PTAccess email list at >> GoogleGroups.com and will direct any inquiries from blind users to >> the growing community of users in the group. Any issues of >> accessibility can be discussed there and any bugs or feature requests >> will be aggregated for future submission to Avid. >> >> I'll continue to post any major updates here but for the latest >> information go to http://www.googlegroups.com/group/ptaccess >> >> Slau Halatyn >
