Hello,
My name is Seth and I'm a new user to MPT. As I said in my subject I am blind. I would like your help getting started. The window I am having the most truble with is the pattern editor. Thank you and God bless. And anyone other help or tips you can give me. I'm using NVDA as my screen reader.
Welcome to the OpenMPT forums. I know our "resident blind user" Diamond has helped other people in the past, but I think it was never done publicly. So having a publically viewable list of hints on how to get the maximum out of OpenMPT using screen readers would indeed be great.
Yes I think that would be nice. I really love trackers and working with them and this one I found was the most accessible. As far as I know there is know other tracker that is. Well accept qws but that is a midi editor.
Hello Sethmhur,
Welcome to OpenMPT. OpenMPT can in fact be used with screen readers, but it takes determination and there is a bit of a learning curve. Please read the thread below which should provide some hints. If after reading the thread you still have questions, feel free to ask and I will do my best to answer them.
http://forum.openmpt.org/index.php?topic=5296.msg41251#msg41251
I understand you can copy the pattern and then edit it with notepad but when I did. I couldn't make sence of it.
I've never relied on that feature myself so you'll have to wait for further clarification from someone else.
The clipboard follows a structured format describing each pattern cell.
For a complete entry, this may look like this:
"|C-501v03Q11"
Where the | character is used to separate channels from each other, followed by the note (C-5), instrument (01), volume column effect (v03) and effect column effect (Q11). All of this information is identical as to how it would be displayed in the status bar or Note Properties window. An empty cell is filled with dots (...) and a cell that was not copied (e.g. because a channel was only copied partially) is filled with spaces.
I've recently been thinking that maybe we can change the default description sent to screen readers e.g. for the pattern editor. What kind of information would be the most suitable here? Should it read out the location? If yes, what should it include? Order number, pattern number, row and column? Or just row and column? Should it just read out the cell (e.g. C-5) under the cursor, or the complete entry (e.g. C-5 instrument 1 volume 64...)?
Row number, column name or number, and the data contained in that position. The problem is, I'm not sure it would be possible to have a screen reader speak that information considering the current bitmap implementation of the pattern editor. Screen readers can generally retrieve textual data, but not anything represented as part of graphical objects. Or I should say, many screen readers now do have built-in OCR functionality for retrieving text from graphics, but the results are mixed depending on the source and such functionality is not designed to be used in real-time which makes it useless in this case. Most of this data is of course already displayed in the status bar which screen readers can read, but without scripting not in real-time. The problem is that different screen readers implement scripting in different ways, so this doesn't really offer a universal solution.
QuoteThe problem is, I'm not sure it would be possible to have a screen reader speak that information considering the current bitmap implementation of the pattern editor.
Well, that is exactly what I want to work around? You can give a description of every UI element through Windows' Accessibility API, and currently no such description is given for the pattern bitmap - but it can be added somewhat easily.
I'm all for it. As I said, I think row number, either column name or number, and cell data should be enough. More data such as order number might be useful, but too much data being spoken at once might make it too wordy and would slow down productivity in real-time.
Oh yes, I forgot channel number as well. That would definitely be useful.
Okay, I added an accessible name for the pattern view containing the position in the pattern and the current cell's content. I verified that Windows Narrator can access this information, so hopefully it should also work with other screen readers.
r8677 / OpenMPT 1.27.00.57 should be up on buildbot (https://builds.openmpt.org/builds/) in a few hours.
I have no experience with screen readers, but would they not read the pattern full row instead of by channel, which is how the player plays it?
Unless you only copy a channel instead of a full pattern to notepad, of course.
*sigh* Once again, the pattern editor is a bitmap. A screen reader cannot read bitmaps (unless they support OCR). Hence OpenMPT now provides a description text for the pattern editor, which can contain whatever we want. Which, in this case, is the content of a single cell, because reading out the whole row or even pattern would be rather useless.
The idea here is that the user can read out the current cell's content whenever they like, typically through a special keyboard shortcut in their screen reader.
In Notepad, it would read line by line. This means that for example all first rows of every channel would be read from the first line as you navigate with the Arrow keys. While visually it probably gives you a good overview of the pattern data, with a screen reader it is somewhat tedious. Although it might still be useful in some cases.
Interestingly, the new test build does in fact speak the data when I initially switch to the "Patterns" tab. This is a good start. I tested with both JAWS and NVDA. It would be useful if the data could be spoken as you navigate through the pattern using Arrow keys, Tab, and so on, but I'm not quite sure how to go about it since my guess is that the data is sent through the Windows' Accessibility API and is not actually displayed anywhere on the screen.
That is correct, Windows queries this data from OpenMPT. It might be possible to instruct the screen reader to automatically speak out this information, but as far as I'm aware there should also be a way in most screen readers to force them to re-read the content of the focussed window?
I'll have to think about that. It might be possible using some scripting, but again this will be different for each screen reader. It may be beyond my knowledge of JAWS scripting. I will have to investigate.
Are you sure you need to use scripting for that? In Narrator, you can simply press Ctrl+Shift+Return. It's not as comfortable as automatically reading it out, but it seems usable.
INSERT+TAB for the "Say Window Prompt in Text" command seems to work in JAWS. Perhaps that might allow for some simpler scripting to make it work with navigation keys. I don't use NVDA much so I'm not sure if it has a similar command, but I will try to find out.
Sigh. Looks like I spoke too soon. INSERT+TAB does repeat the information, but it repeats the data initially obtained when the tab gains focus. The buffer JAWS is using to store the data is not refreshed as you navigate through the pattern. My guess is because when the JAWS developers wrote the script that handles this functionality, they were not expecting the data to change while the window still has focus.
So after some experimenting, I discovered that sending a WM_SETFOCUS message to OpenMPT causes JAWS to refresh and speak the data in it's buffer without having to switch focus away from and then back to the "Patterns" tab. Insert+Tab seems to work for reviewing the data in NVDA as well and no additional steps are necessary to refresh the buffer. Although it does seem to unfortunately speak some extraneous data such as all the channel numbers displayed on the screen, but I suspect this is a quirk of NVDA and has nothing to do with OpenMPT.
That sounds good. :)
Yes indeed. Thanks for adding this. It works better than the previous method I was using of reading the data from the status bar.
Do you think the format of the accessibility description should be user-definable (through a hidden setting)? That way, if someone doesn't need the row information, they could omit it, or if someone wants the pattern number, they could include it, etc...
I hadn't actually thought of that, but I can see how it might be useful.
There is now a configurable setting, Pattern Editor.AccessibilityFormat (https://wiki.openmpt.org/Manual:_Hidden_Settings#.5BPattern_Editor.5D) (full description is in the linked wiki article). The column type is now also adjusted for PC events (e.g. "volume" becomes "plugin parameter" instead).
Edit: And as of r8704, there is now also an accessibility description of the currently selected envelope point in the instrument editor!
Diamond: Do you think it would be worthwile to have a wiki page with tips and tricks for visually impaired and blind users? It could also be included in the manual that way.
Whoa, a lot going on here! Have a lot to say but don't have much time at the moment to give this proper attention, as I'll soon be leaving home for the weekend. So forgive me if I don't sound too informed. I'm new to tracking in general so all of this is a lot to take in. But I've been wanting to learn.
Firstly to the OP, I'd also be willing to help you with learning Open MPT and the like. While I can't yet write a piece to save my life, I did mess around with a lot of different things and know how they work (pattern editor, sample/instrument editor, envelope editor, etc.) and could at least describe what the basic keys do.
Primarily, I use NVDA as a screen reader, though I do have Jaws and also am on Windows 10 so I can use Narrator as well. Just tested accessibility features and they work as advertised in the pattern editor, and it tries in the instrument editor as well. Pretty awesome start! As others have said it would be very useful to be able to get info in realtime as you press navigation keys, or to somehow keep track of where your selecting since that is kind of confusing without speech. But I won't complain so long as the implementation makes things easier than they currently are.
I know nothing about programming, but perhaps something that works similar to Osara might help. Osara is an add-on for the popular Reaper DAW which works best with NVDA, and somewhat with Jaws in my experience, not sure about Narrator but I'm pretty sure it works well there too, and I'm almost certain it uses MSAA like this does. It does change the keyboard mapping and adds some custom actions to Reaper, but that's not important here. What's relevant is that it interfaces with Reaper somehow to give feedback on what it's doing. Osara has never failed me, at least not from within NVDA. I'm fairly certain that the devs of Osara would be willing to help with ideas on how to implement such things into Open MPT if you run into roadblocks.
I'm of the opinion that Jaws support is a lot of extra trouble since it doesn't respond as well to MSAA, though it does to some extent. Still, NvDA and Narator seem less clunky about that, especially the former in my opinion, and even when I used Jaws full time I still had NvDA installed and would switch out for cases exactly like this. So if Jaws support ends up being a little finicky, it's probably not a huge deal to most people as they can use one of the other screen readers.
One thing not yet mentioned: the sample mapping dialog is really difficult with a screen reader. I've sort of figured it out but it isn't possible to do things with the keyboard directly, so I have to use the mouse simulation functions of my screen reader to click on things. I get scared every time I try to go in there to make multisampled instruments, and I'm probably not even doing it the way it's intended to be done. I can't really suggest how to make it more accessible at this point but would be willing to test and try things. After tomorrow night I should be more free.
Last but not least... maybe this'll help devs of Famitracker and other trackers which have extensive keyboard navigation already to implement screen reader support? Just throwing stuff around at this point but couldn't resist. most of you guys are more active in this community so may have connections and be able to make it more likely to happen :)
Edit: actually tested and removed some questions I had before testing
There are plans to add a scripting API to OpenMPT (if all goes will, a first version of the scripting API will be present in OpenMPT 1.28), which would help with extending OpenMPT in many ways, also for screen readers. I think this way blind users could potentially have more control over what kind of information they want to get from their screen reader. Something similar to Osara could probably be built then.
I'm not a huge fan of "look at this other piece of software and how it does things", but if you can name some specific things that you think would be great to have in OpenMPT as well, please mention them.
QuoteOne thing not yet mentioned: the sample mapping dialog is really difficult with a screen reader.
There has also been criticism from sighted users, so there are plans to redo the dialog at some point. When doing so, I will keep accessibility in mind.
OpenMPT's current test builds (version 1.27) add support for the SFZ instrument format, which is entirely text-driven, so maybe this would help you with defining instruments and then later refining them in OpenMPT.
Yeah, I can see why you wouldn't like to take the "hey let's see how it works and do it that way" approach. Was just thinking that if you had no clue where to go to improve screen reader support, something like Osarra would be the best example of integrating such support and you could get a better concept of how it might be accomplished from a developer standpoint. It sounds like you already do have that though, so I really have high hopes.
And I saw somewhere about SFZ support but didn't have time to look into it. It's a format I use on a regular basis so this is good news! I'm assuming only root key, lokey and hikey and perhaps loop definition are actually supported? If so this is enough, I don't see how you could add much else given the nature of lfos and envelopes in midi vs Open MPT. I'll try this when I get home, as well as taking another look at envelopes now that they speak.
You can find a full list of supported opcodes at https://wiki.openmpt.org/Manual:_SFZ_Implementation - it's by far not complete but certainly a bit more than just key information.
How do I send a om focus update and how do I get the latest verson to test out this new property found in the wiki?
The link to the latest test version has been provided on page 1 of this thread: It's https://builds.openmpt.org/
For how to send focus messages to an application, you will either have to consult the manual of your screen reader or wait for the other users to help you out.
Quote from: Saga Musix on August 03, 2017, 13:29:44
Diamond: Do you think it would be worthwile to have a wiki page with tips and tricks for visually impaired and blind users? It could also be included in the manual that way.
Indeed that would definitely be useful. I'll contribute as time allows. I've been a bit under the weather and I may have to return to the hospital for a possibly recurring blood infection.
I did play around with the "AccessibilityFormat" item you added in "Advanced" settings. The format for the string was not difficult to figure out. Very useful. Thanks again for adding this.
Quote from: musicalman on August 05, 2017, 14:39:01
I'm of the opinion that Jaws support is a lot of extra trouble since it doesn't respond as well to MSAA, though it does to some extent.
Unfortunately, I have to disagree with this opinion. Despite any issues JAWS may have with MSAA which I cannot personally verify, it is still likely the most widely used screen reader so support for it should not be casually dismissed. I respect NVDA's capabilities and I'm sure it is quickly becoming a close second, but there are many users including myself who still prefer JAWS.
Quote from: musicalman on August 05, 2017, 14:39:01
One thing not yet mentioned: the sample mapping dialog is really difficult with a screen reader. I've sort of figured it out but it isn't possible to do things with the keyboard directly, so I have to use the mouse simulation functions of my screen reader to click on things.
Placing focus in the sample mapping section requires virtual cursor/mouse functionality of your screen reader, but once it does have focus, you can assign starting note with the keyboard and sample assignment with the numeric keypad.
Quote from: musicalman on August 05, 2017, 14:39:01
Last but not least... maybe this'll help devs of Famitracker and other trackers which have extensive keyboard navigation already to implement screen reader support?
Part of the problem is that unlike OpenMPT, most other trackers do not use standard Windows controls. This makes accessibility more difficult to implement and probably means developers will have less incentive to even try.
Quote from: sethmhur on August 07, 2017, 03:22:41
How do I send a om focus update?
Unfortunately, this requires a bit of scripting knowledge. With JAWS for example, you could create a script for OpenMPT and assign it the shortcuts Insert+Tab and CapsLock+Tab for the laptop keyboard layout to override the standard behavior of the "Say Window Prompt in Text" command. The script would look like the following:
Script SpeakPosition ()
If GetMenuMode () == inactive Then
SendMessage (GetForegroundWindow(), 0x07, 0, 0)
EndIf
EndScript
It doesn't work perfectly, but it at least updates the buffer which JAWS will not do in OpenMPT for some reason. I personally use a combination of JAWS scripting and AutoHotkey that works well enough for me, but which I won't share because it isn't completely reliable.
With NVDA, I suspect you would have to create a custom add-on to use SendMessage functionality assuming it is supported. NVDA add-ons are written in Python so I suspect the functionality is probably there.
Interesting, I just tested with NVDA and it doesn't speak notes and sample numbers while navigating the sample map. Yet another reason not to so casually dismiss JAWS. Each screen reader has it's strengths and weaknesses so it's good to have more than one installed, but JAWS definitely still has some advanced functionality that NVDA does not.
Quote from: Diamond on August 07, 2017, 14:14:54
Despite any issues JAWS may have with MSAA which I cannot personally verify, it is still likely the most widely used screen reader so support for it should not be casually dismissed.
*sigh* I dont' want to turn this into a screen reader debate. But I really do have to stand my point. Firstly I won't say you're wrong, because you're not; Jaws is still the most popular and dismissing it would indeed be an inconvenience to many people. But the reason I said what I said is severalfold. Because Jaws is changing, some programs that used to support it no longer do. One example is the popular Blastbay Game Toolkit, I know it's completely unrelated to this topic, but nonetheless a popular tool. Jaws support has been dead for years (see below for why). Osara, while it works with Jaws, is clunky (just tested). It feels like both are competing for who gets keystrokes because Jaws will say blank often before doing anything, and has a very irritating lag any time you press an Osara command. NVDA and Narator do not do this, and as a result your productivity increases. You mentioning how Jaws does not update the window focus with insert tab and having to implement workarounds is another example. While there are valid reasons for why it behaves that way, I don't have the patience to work around it when I can just fire up another screen reader which will be faster with this task. However, Jaws might work better in the sample mapping dialog, which I was going to ask you about since I'm not sure how to use it with the keyboard. So maybe that will persuade me to persevere the Jaws root or learn how to do it with NvDA once I've learned what Jaws is doing. Or, I may just use the oncoming sFZ support for that purpose. It really all depends on what you have more patience for I suppose, but my point wasn't to casually dismiss Jaws. It was simply to point out that fluid Jaws support takes extra work it seems for various reasons. Developers aren't always willing or able to do that extra work, considering Jaws's complexity and price tag, especially when other free screen readers exist that really are good alternatives and are easier to cooperate with. Again I am not trying to say Jaws support isn't worth the cause, but only to point out the reasons why other screen readers are easier to work with in this regard so Jaws often gets set to the side in those cases.
Quote from: musicalman on August 07, 2017, 17:36:27
*sigh* I dont' want to turn this into a screen reader debate. But I really do have to stand my point.
Sigh indeed. My intention was never to turn this into a screen reader debate. In fact, I specifically stated that each screen reader has it's strengths and weaknesses. Although I don't believe JAWS not updating it's buffer in the "Patterns" tab is any kind of example of deficiency on behalf of JAWS considering that it is far from a control designed for accessibility. The pattern control is bitmapped and even NVDA speaks extraneous information when using it's equivalent of the "Say Window Prompt in Text" command.
Well, if we agree not to debate, it's settled. :) Was just trying to be helpful based on my own experiences with the applications I mentioned above.
Agreed. Although it is worth keeping in mind that personal experiences can vary widely depending on the software being used. I could never use Virtual DJ with NVDA due to it's lack of support for custom highlights. I could never use WinBuilder with NVDA due to it's lack of support for application graphics. And so on, and so on.
I'm still very interested to know how you use the sample mapping dialog with Jaws, but I don't think I've explored it properly either. What I remember doing back when I was trying it was selecting the sample from the list that I wanted to assign to keys, and then mousing around on the onscreen keyboard and clicking on the keys I wanted that sample assigned to. It wasn't very nice to be sure. I did actually use Jaws to do it at first, though I think I figured out how to do it with NVDA and screen review. I never really figured out what Jaws and NVDA did and didn't read. I didn't even know the numpad was useful in that dialog since I was using the numpad for screen reader keystrokes.Sorry if I sound vague or inaccurate, this was last year some time and my memory of this is fuzzy.
This is somewhat difficult to explain and there may be some points I'm missing from a visual prospective, but I will do my best. By default, an instrument has all notes assigned to it's equivalent sample number. Instrument 1 has all notes assigned to sample 1, instrument 2 has all notes assigned to sample 2, and so on. When the sample map has focus, there are 3 columns. The original note, the currently assigned note, and the currently assigned sample. Again by default all assigned notes are the same as the original note. JAWS only reads the last 2 and unfortunately it speaks them both as a single unit, no matter which column is selected. So for example, JAWS might say,
"C-5, 2"
C-5 being the currently assigned note and 2 being the currently assigned sample. The Left/Right Arrow keys switch focus between the assigned note and assigned sample columns. The Up/Down Arrow keys switch to the next/previous note/sample pair in the map. Although when the assigned note or assigned sample columns have focus, the Left/Right Arrow keys will just advance to the next/previous note/sample pair in the map as well. When the assigned note column has focus, you can press a note on the keyboard to change it. When the assigned sample column has focus, you can type a sample number on the numeric keypad to change it. For example, 03, 09, 17, etcetera. Typing 00 will assign the selected note to no sample. Of course, NumLock has to be on for this to work. Hopefully this will help, but I don't think I can explain it any better. If you think they might be useful to study, I can upload a couple of drum sample maps I have personally created.
I'm not sure if you both talk about the same thing - musicalman mentioned the sample mapping
dialog, which is separate from the sample map the instrument view. I think the sample mapping dialog is completely unusable without the mouse (even setting sample assocations requires the mouse there), but the sample mapping table that is found directly on the instrument tab definitely should be more accessible, since it is keyboard-driven, as Diamond explained. Its downside is that you need to memorize which sample is which, because (even for sighted users) there is no way to see which sample number belongs to which sample name.
By the way, I don't think it's bad to have a little debate here - in particular since the results of it could be part of the wiki article on accessibility.
Quote from: Diamond on August 07, 2017, 13:46:43
Indeed that would definitely be useful. I'll contribute as time allows. I've been a bit under the weather and I may have to return to the hospital for a possibly recurring blood infection.
Ah, sorry to hear that. I don't want to start a page when I personally have not much to contribute, but if you want to write something up, I suggest to put it on this currently empty page: https://wiki.openmpt.org/Manual:_Accessibility
Quote from: Diamond on August 07, 2017, 17:54:40Although I don't believe JAWS not updating it's buffer in the "Patterns" tab is any kind of example of deficiency on behalf of JAWS considering that it is far from a control designed for accessibility.
I cannot be sure about this but it
does sound like a bug to me (or rather overzealous optimization) that Jaws caches the old text, so it might be worth reporting a bug to the developers.
Quote from: Saga Musix on August 07, 2017, 23:12:20
I'm not sure if you both talk about the same thing - musicalman mentioned the sample mapping dialog, which is separate from the sample map the instrument view.
Ah yes, I vaguely remember that dialog. I didn't think of it initially because I also remember it being mostly keyboard inaccessible so I never use it. So, does the sample mapping dialog do the same thing as the sample map on the "Instruments" tab or do they serve different purposes?
Quote from: Saga Musix on August 07, 2017, 23:12:20
I cannot be sure about this but it does sound like a bug to me (or rather overzealous optimization) that Jaws caches the old text, so it might be worth reporting a bug to the developers.
Perhaps, but I still think it is more likely that JAWS is simply having problems accounting for a control/element to which it is not accustomed since the command works correctly in other applications. Also, reporting it as a bug probably wouldn't do much good since most screen reader developers will only spend time and effort investigating issues which affect popular/commonly used applications.
Quote from: Saga Musix on August 07, 2017, 23:12:20
Its downside is that you need to memorize which sample is which, because (even for sighted users) there is no way to see which sample number belongs to which sample name.
Interestingly, I have never found this to be much of a problem since typing the sample number to assign it previews the sample as well.
I really don't know how to describe this on nice easy-to-explain terms but I will do my best. The sample map editor I am talking about is in a separate dialog. I go to instruments with alt n, then use the mouse to find the spin box with the instrument number and bring that to focus. Once that's done, I can tab around and adjust things, and eventually I will find an unlabeled graphic. IIRC Jaws did see a sample map editor label, but can't remember now. If I double-clicked that, I would be brought into a dialog with a title of "sample map" which had a list box of samples, a slider, and a checkbox labeled show all samples, with an OK and cancel button. If you moved the mouse around, There were also numbers which I think were the annotations indicating which samples were used on the keys of the mapping keyboard. The slider IIRC scrolled the keyboard. So I'd go in the sample list, focus on the sample I wanted to apply, and then mouse around the keyboard, clicking on the keys I wanted assigned to that sample. So for example if all keys were mapped to sample 1 and I wanted some keys to use 2, I'd focus sample 2 in the list, then click on the keys I wanted 2 assigned to. Go ahead and cringe. I sure do when I think about it. I have a lot to learn.
Based on what I read I presume this is not the dialog recommended for me to go into. If this is the case then any tips for going into the other one?
Well, you're at least halfway there. On the "Instruments" tab, put focus in the instrument number spin box as you are already doing and Shift Tab once. The sample map I am referring to will now have focus. The problem is that as I said, I discovered with NVDA it unfortunately just sees the control as a graphic, but if you try it with JAWS it should speak note/sample number when navigating with the Arrow keys as I described. For the record, I'm not sure I understand how or why even JAWS is reading anything from this section since according to Saga Musix, it is a bitmapped control similar to the pattern view.
Oh yes, and Make sure that the main window and document window are both maximized. I vaguely remember that JAWS might not speak anything in the sample map otherwise.
Yeah, that's a side effect of drawing optimizations - bitmapped areas that are not visible are also not updated, so JAWS cannot see any of the strings that would end up on that bitmap.
Wow, just tried this with Jaws and it does read things. Didn't try adjusting the sample map yet but the unlabeled graphic NVDA sees speaks a lot of information with Jaws, which I don't remember it ever doing last year when I tried it. I'll play with it more in a bit.
It may not have worked when you tried it last year if the window wasn't maximized. I discovered this after I wasted time filing a bug report. It has worked for me since I first tried OpenMPT many many years ago. Although back then it was still just called ModPlug Tracker before it went open source.
So, I've thought of something else a few weeks ago and wasn't sure how practical/useful it would be, but am throwing it out nevertheless.
In the pattern editor, you can press control enter to play the current row. When you do this though, your cursor jumps to the next row. The advantage to this is that you can keep hitting control enter until you find a row of interest, but the disadvantage is that once you hear the row you're looking for, you have to hit up arrow once to go back to that row. For me at least, this makes things tedious and sometimes disorienting if I'm dealing with dense patterns.
I wonder if it would be easier from a blindness perspective to have a play mode where rows would be played as your cursor moves to them, so that by simply pressing the up and down arrows you could hear the row you were focused on, and once you hit a row of interest, you could immediately check something or make changes. The midi sequencer I use has a note editor which works this way. The editor is a note grid, with adjustable snap similar to the speed effect. Because it's midi you don't have to line stuff up with the grid snap values, but that's beside the point. What's relevant is that when your cursor bumps into a note, whether by moving by grid snap value or by jumping directly between notes, the note under the cursor is played, and from there you can modify its properties. I like this because I can hear in realtime where I'm at with no need to update the feedback manually, and if I miss my stop first time, I can just go back and quickly find the correct note and do what I have to do. Maybe there's already a way to get spontaneous feedback in the pattern editor in Open MPT that I'm just not aware of? If not, I'd be interested to know how useful such a feature might be. It certainly sounds really nice to me in my head, but it sounds like a really simple thing and a little voice in my head is telling me I'm not the only one who's thought of it so it must have been accounted for in one way or another. Lol
It should be doable to add it has a hidden setting, there are just some things to consider. For example, should this be a setting that's always enabled or does it need to be toggle-able? I don't know if it would be annoying if it was always enabled. Another thought is if it should always play the whole row (easy) or just the current channel (tricky if it's also supposed to handle effects and stuff).
I definitely think it should be toggle-able. And at least in my opinion, it should play just the row, not the entire channel since from a blind person's prospective, the whole point is to preview what is under the cursor as you navigate with Arrow keys and so on. Or perhaps two different settings could be added. One for playing just the row and one for playing the entire channel?
The way I imagine it, it would behave like control enter. So all unmuted channels plus all their effects. Having some easy way to toggle it is definitely not a bad idea as Diamond said.
Quote from: Diamond on September 10, 2017, 00:07:51
It should play just the row, not the entire channel since from a blind person's prospective, the whole point is to preview what is under the cursor as you navigate with Arrow keys and so on.
I think there may be a misinterpretation. What I think Saga musix was saying was that you would always here what's under the cursor, it's just a question of whether it plays the channel you're on, or all channels mixed. If I am indeed understanding this right, then I say go the easy route and not bother with isolating the channel you're on. I could see myself wanting to hear what I'm doing in the context of the mix. If I want to hear just the active channel, I could solo it with control f10.
Quote from: musicalman on September 10, 2017, 01:02:58
I think there may be a misinterpretation. What I think Saga musix was saying was that you would always here what's under the cursor, it's just a question of whether it plays the channel you're on, or all channels mixed. If I am indeed understanding this right, then I say go the easy route and not bother with isolating the channel you're on. I could see myself wanting to hear what I'm doing in the context of the mix. If I want to hear just the active channel, I could solo it with control f10.
No misinterpretation, but this is why I said two individual settings might be an option since I would personally prefer only to hear the active channel. Although just soloing the active channel might be a satisfactory solution.
I probably won't have time to look into this before the 1.27 release, so in order for it to not be forgotten, can you please sum up the results of the latest discussion here as a feature request on the issue tracker?
Just looked at the issue tracker and because I'm not really familiar with such things and don't have a lot of time today, I wasn't able to figure out exactly how to fill out the submission form for a feature request instead of an issue. If someone else can put it there, go ahead and do it, or else I will try more thoroughly later.
Sorry, I was actually more thinking of Diamond as he's already familiar with with the issue tracker. :)
Reporting an issue is the same as reporting a feature request, it's just a matter of selecting the correct severity level, "feature". And even if it's not reported in the correct category, we can always fix it manually. But I prefer people to submit their ideas by themselves since they know best what they need.
It is done.
http://bugs.openmpt.org/view.php?id=1026
Hi, One more blind dude here. I didn't want to start a new topic just to show myself. I recently revived my old MPT use - last track with it was made in 2010, as I switched almost completely to hardware these days, but decided to keep the old alternative actually alive. Fortunately managed to find an old keymap created by yet another blind friend for both of us to use and it still works fine. I use both jaws and nvda, but the jaws version is pretty old, 5.10, as I decided not to invest in software any more and didn't upgrade anywhere. As a proof of tracking, here is a link to one of my older tracks to listen. Here MPT is used actually more as a vst host type daw and not that much as a typical samplebased tracker. Later the trackwas edited with Adobe Audition 1.5 which is still used as a main audio editor although it's definitely not the freshest version of the product, but is still probably the most accessible version and it's a purchased one after all - yep, I don't like cracking. So please injoy and give feedback!
https://soundcloud.com/drxid/watch-out