I am installing logic as we speak/type. GF
On Jul 1, 2010, at 12:19 PM, Kevin Reeves wrote: > Hey Ginny. If you want a live demo of Pro Tools, come on downtown. Briley and > I can definitely show you the ropes if you want. Hit me back off list, and > we'll make it happen. > On Jun 30, 2010, at 1:13 PM, Ginny Owens wrote: > >> Absolutely. I only meant to point out that some of the most basic features >> in Logic are surprisingly inaccessible. Please, ProTools, come quickly. >> >> >> -----Original Message----- >> From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On Behalf >> Of Bryan Smart >> Sent: Wednesday, June 30, 2010 11:08 AM >> To: ptaccess@googlegroups.com >> Subject: RE: LogicRE: Update Summer 2010 >> >> 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 >>> >> >
