#1686 Minor window focus when creating MIDI Devices
Steps to reproduce:
1. Open "Manage MIDI Devices" window
2. Click New, then "Banks..." which opens "Manage MIDI Banks and Programs"
3. Click Import, select an rgd file from the file manager
4. On opening the rgd file, the "Import from Device..." window appears
5. But "Manage MIDI Devices" window disappears, in my case, out of view behind the main RG window
6. Top window is now "Import from Device..." behind it "Manage MIDI Banks and Programs" and behind that the main RG window
7. When "Manage MIDI Devices" is behind main RG window, it's easy to forget to select a port for the new device to complete the workflow
8. Workaround is easy...don't forget
Might as well mention another bug discovered during this test. If it's clearer to make it a separate bug, then feel free.
Generally, if there are multiple tracks with the same instrument, changing the instrument on one of those tracks is conveniently propagated to all the other tracks. The same is true for volume, pan etc i.e. it's not the track number that's important, but the instrument on it. However, when there are two MIDI Devices present, changing the device on one track does not propagate to the device on the other tracks that were sharing . But the instrument automatically defaults to #1 when the Device is changed on the first of them. At one point I think I heard the default instrument #1 playing when I didn't expect it. I was only swapping rgd files (hence devices), so I didn't investigate further. It might be worth checking the scenario though.
It is fairly straightforward to raise (or reopen) the device manager dialog on closing the bank editor - this makes sense - see merge request.
On the second point:
The selected program pan chorus etc. are instrument parameters. If two tracks use the same instrument these parameters MUST be identical.
On the other hand if I select a new device for a track I am selecting a new instrument for that track.
I think this should not affect other tracks !
So I think the behaviour when selecting a new device is OK the way it is.
See merge request
I agree that none of the above need change, and I've seen the instrument parameter change behavior from the beginning. Change Devices is relatively new, to me at least, and while reproducing steps for Device deletion in a different bug, I saw (or should say heard) something unexpected from the external MIDI.
Confirming that the two types of change are behaving correctly, helps when it comes to trying to reproduce that odd moment, which I could not investigate at the time. I will prepare those steps next and rather than create a new bug (which it may not be), I will post it here for comment.
Before I could begin this scenario, I was tripped up by something I did mention in passing in another bug. The problem is caused by [d0760d] having the "Start JACK automatically" flag set to true by default. As far as I am aware, stable versions never had the "Start JACK automatically" box checked?
So, RG does its normal search for any MIDI to attach its default Device to (that's an issue for another time) AND starts JACK if one is not started.
For this scenario, I need RG to not contact my external keyboard until I am ready for it do so. I made sure the USB audio interface was not available (unplugged). Alas, RG started its own JACK, using parameters that I don't even use and on an interface that I would not have chosen.
jackd -T -ndefault -t 200 -p 2048 -R -T -d alsa -n 2 -r 44100 -p 256 -d hw:PCH,0 -X rawAnd since I've read that for technical reasons, JACK does not support multiple interfaces, plugging in my USB interface after the fact presents a problem...or to be exact, it's not going to work in my set up.
Of course, I get can around this by first starting RG, then configuring it not to start JACK, saving that as the new autoload, and restarting my original scenario. But that would not be a fresh install and some cases even a minor difference can cause bugs to be missed.
Question:
1. Going forward, is RG going to have "Start JACK automatically" checked by default in stable versions OR
2. Is that box checked for some other reason e.g. because I am using [d0760d]?
In the mean time, I have to take the alternate "custom autoload" route (unless you have your own alternative to suggest). I'll resume the scenario when I have a bit more time.
Related
Commit: [d0760d]
There seem to be multiple issues here.
First some clarification:
The Jack autostart flag is a configuration setting and has nothing to do with the autoload (default studio).
On may system the configuration settings are stored in
~/.config/rosegardenmusic/Rosegarden.conf. The default studio is in~/.local/share/rosegarden/autoload/autoload.rgThe auto start setting for jack has (and always has had) true as the default. If you remove the Rosegarden.conf file and restart rosegarden the autostart will be set.
Note that rosegarden will only start jack if it is not already running - I start jack on login so I always have jack running when I start rosegarden - the autostart flag is then irrelevant.
Although jack does not support multiple interfaces directly the alsa_in and alsa_out programs allow use of multiple interfaces - see the jack documentation.
To your questions:
1. The jack autostart defaults to true but if you set it to false it will stay that way unless you delete the Rosegarden.conf file.
2. This has nothing to do with the rosegarden version.
It seems to me you need to first connect your usb audio device then start jack then start rosegarden.
I hope this helps
Device manager focus fix merged as [b741a3]. Please test latest git.
Switching this to feedback status. Let us know if there is something else that needs addressing.
Related
Commit: [b741a3]
Oh...so that explains it. To reproduce the bug, I wanted to use a fresh install in case using my configuration was causing the issue. Hence, no ~/.config/rosegardenmusic or ~/.local/share/rosegarden .
As for first connecting my keyboard USB audio interface, RG on start up immediately contacts my keyboard which is what I don't really want in general...and not for this particular test...it's in fact possibly part of the problem I wanted to describe.
I also think you're saying that when JACK is installed there never has been a way to stop it being started on first launch. Is that correct? Although I only needed it for a test, would a feature request for a --start-jack flag be appropriate for some future version, although I'm not sure how it would work the value in Rosegarden.conf after RG actually creates one?
I hope after all of this I can still at least give you a clear picture of why I'm going through all this trouble. In the mean time, I can proceed by ensuring that I first configure the installation to not start JACK and I'll add that to the steps to reproduce.
That is correct. The reason it does that is to help out new users who are not familiar with rosegarden and how to get sound in Linux. This is a huge issue and this is how we've decided to deal with it. If you want JACK started a certain way, start it before starting rg. If the JACK auto launch bothers you (drives me crazy), disable it via the preferences.
Maybe a --do-not-start-jack flag. But I'm not sure it would be worth much. I wouldn't worry about it. I don't see us ever implementing that.
So, JACK starting automatically is normal. So, I took that into account and got further, but a new seemingly inconsistent behavior appeared...it's actually closer to where I'm ultimately going, but I need to know if it too is normal.
You will need an external MIDI device to match my case so you can tell if MIDI messages are sent to it. Or if not find some means of knowing whether RG has sent such messages and hope it doesn't change the results...for now what messages is probably unimportant, but will be when I get to the main issue.
Steps to reproduce:
1. After a fresh install:
2. Stop JACK if it's installed
3. Start RG
4. JACK will be started by RG automatically (no choice)
5. Edit/Preferences/Audio: Uncheck "Start JACK automatically"
6. Shutdown RG
7. RG's JACK is stopped when it closes
8. Ensure NO MIDI ports available on the computer...not always easy, but I want RG to start with "No port" for both inputs and outputs for this test
9. Start RG
10. JACK is now no longer started by RG...do not start JACK manually
11. Open Manage MIDI Devices
12. RG provides a convenient General MIDI Device with No port set for MIDI outputs and inputs
13. Close Manage MIDI Devices
14. Connect an external MIDI device to the computer e.g. a USB MIDI keyboard
15. Open Manage MIDI Devices
16. The external MIDI ports now show up, but No port is still set for both outputs and inputs, as expected.
17. Select a port only for MIDI output
18. No MIDI messages are sent
19. Select No port again...it takes some time before the port selection becomes not bold i.e. not selected. Not sure if that's an issue or not (see below). Leave set at No port when it settles
20. Now set only the MIDI input port
21. Immediately MIDI messages are sent to the keyboard. Why for that one? Is that supposed to happen at that point?
22. On setting back to No port, no messages are sent and that set to No port is immediate
23. Now selecting the MIDI input port again, this time no messages are sent. Unless there is caching going on, why?
24. Set it back to No port again
25. Go back to MIDI outputs and set a port, still no messages. Leave it set.
26. Now set the MIDI input port i.e. both inputs and outputs are set....Now the MIDI messages do go out again
27. When MIDI outputs is set to No Port, it is now immediate unlike before. Probably irrelevant for this scenario, but why?
As far as I can tell, the focus should be on MIDI inputs. On its own, it will sometimes cause MIDI messages to be sent, but not always. And for that, it doesn't matter whether MIDI output is set or not, the MIDI input has this sometimes, not not always behavior.
Maybe a hint of the overall problem now would be helpful, although the questions above in the steps to reproduce are what I need for now. When I start RG, a bunch of Control messages, including Program Changes hit the external MIDI. Most of the time I have no intention of working in that particular startup session...unless I'm creating a new one. I mostly open the session I want after that. And strangely enough, no messages are sent for opening the session I intend to actually use. I want to say never sent, but can't if there is inconsistency going on. But I think I can say that on starting RG, it always sends messages..and I think it may have something to do with the above i.e. when ports are set, although I could be wrong.
At the end of the day, the unexpected instrument I originally mentioned at the top of this thread, might have been caused by what's going on here...but I have to wait until I can actually get to that scenario with a path that you confirm is normal and is reproducible.
This does sound odd given that the General MIDI device is no longer connected to the MIDI output going to the keyboard.
What kind of messages go out? How can you tell messages are going out?
There is buffering that ALSA does on MIDI input. If nothing is connected to an input and MIDI messages come across, they will wait for someone to connect to that input. E.g. disconnect the MIDI input in the Manage MIDI Devices dialog. Play some notes on your keyboard. Reconnect the input to the keyboard in the Manage MIDI Devices dialog. The notes you played will all come in at once. Maybe this is what you are seeing?
There's probably an update timer in that dialog. I would have to read the code to be sure. There are lots of UI update issues throughout rg. It doesn't surprise me.
That's working as designed. We assume in the autoload that you are using a General MIDI device. At startup we try to connect to it and we configure each channel based on what is on the tracks. That's piano and default volume, pan, etc... Again, this is for new users to help them get up and running quickly.
Most synths either support GM or will gracefully ignore this initial config. Just set up your document with the correct devices and ports and go to work. Next time you load it, it should configure everything the way you like it.
You can change the autoload to match your setup if that is problematic. Put together an empty document with the appropriate devices and port configurations and save it. Then copy it over top of autoload.rg in your .local/share/rosegarden/autoload. Then each time you start rg you will get exactly what you want in terms of messages going out.
I agree that the ease of use defaults should remain. Also we can disregard the --do-not-start-jack flag...in fact, removing JACK was to simplify this analysis i.e. have RG only connect up minimally on startup to see what's going on. JACK is not part of the problem. Also, the defaults only get in the way when something odd may be happening during startup, otherwise I wouldn't have mentioned them.
I'll leave that one for you to think about or duplicate in detail, but you can also wait until I've got further with this bug. Now I smiled when you asked the following, since I asked myself that same question before posting:
I figured you would have to set debug points in the code because RG is starting and it is the one creating and using its ports as it goes along. By the time it's up and running, it's not sending messages any more. Fortunately, I can see that my keyboard received both Bank and Program Changes because it configured itself for them when RG started...the expected ones i.e. Program change for Acoustic Grand Piano on all tracks.
BUT I stumbled on a way which might answer your question. It's still related to the automatic defaults for RG. Perhaps you can use this method too. Previously, I used the linux aseqdump tool to monitor RG's ports after start up for a different problem. When you list the ports, you see "RG out" once it's up and running. On one occasion, I minimized that window and forgot about it. I then prepared for a fresh install of RG to reproduce some other steps..but my keyboard got no messages...Checking Manage MIDI Devices revealed that as far as RG was concerned, aseqdump's MIDI was the first receiver it saw, and dumped my its messages there. Hence my earlier comments about keeping things simple and ways to avoid defaults for testing.
You may be able to use aseqdump to answer your own question.
1. Start RG first, preferably fresh install and no MIDI interfaces around
2. aseqdump -l reveals RG's out port
3. aseqdump -p port-number
4. Stop RG
5. Nothing should show up in aseqdump
6. Start RG again and you should then see the messages
7. As an aside, sending GM messages on startup is actually fine (for new users at least). At that point, a new session has been created by RG, on behalf of the user, and it sends that configuration.
And if you wish to go a bit further and open a previous session that uses an external keyboard, note the last message in the aseqdump window, or hit enter a few times to create a space at the end of the messages.
Either:
1. Stop RG
2. Add an external MIDI keyboard
3. Restart RG
4. Check messages in aseqdump window
5. Check the Manage MIDI Intefaces window
6. Open a previous session that uses that external keyboard
7. Check messages in aseqdump window.
8. Do you get new messages for that previous session on opening?
9. If not, do you think there should some, just like when RG started and opened its default session?
10. As an aside, if messages were sent, it's possible that I might not even have found a path to the bug I'm actually trying to reproduce.
Alternatively:
1. Just Leave RG running and repeat 2-10 for adding an external MIDI keybaord (you might want to check both paths)
During all of this, you will note that on a restart of RG, even a fresh install, it will jump on aseqdump MIDI receiver, if it's the only MIDI port. Unfortunately, I think RG may still grab that port even if the real keyboard ports are there beforehand. How would it know it was different? Introducing aseqdump to reveal messages is not the normal RG setup though, but hopefully allows you to see the messages and the behavior I saw.
As for the ALSA buffering, it's possible. I don't think I touched the keyboard, but I did undo the unwanted Program changes RG sent on starting the default session. And each time it sent those messages, as I used the Manage MIDI Devices in this thread, I had to undo them again otherwise nothing would change on the keyboard display since all Program changes were identical to the last time.
This probably supersedes my last post. I think I'm finally in a position to explain why I opened this bug, and what is causing the odd behavior I hinted at. I was reluctant to detail it because I could not figure out where to start.
Main problem: Unwanted Program changes/controls being sent to my external keyboard causing it to be reconfigured in ways I didn't want. But not in every scenario, and that was the difficult part.
Worse still, I could not find out what the messages were because of the way RG started and automagically set everything up. I knew some were program/bank changes though.
Some of the clues came in when I actually looked at the details of the MIDI messages being sent, just as I mentioned in the previous posts i.e. using aseqdump set up in two steps as described earlier in this thread.
In master, using just one track as an example the following is sent every time on startup:
However, when all were sent I didn't get Acoustic Grand Piano (program zero), but other instruments?
In my own configuration still using stable RG v23.12, I didn't have this issue for the same keyboard, which is odd. However, I started a fresh install of v23.12, and sure enough the same problem started occurring. In fact, the messages above were the same.
The only real difference left was when not using a fresh install i.e. I was using my own Custom Device from ages ago...I think v18.12, so I suspected something had changed since then. When I start and get the correct instruments, the following is sent:
Notice that controller 0/32 (MSB/LSB) are both sent with zero which normally implies a General MIDI Bank selection. I believe I based my Custom Device on one of those in the RG library years ago, but focused on setting up the various Banks...not controllers.
I exported sourceforge master's rgd from the Device. I mentioned in a post in some other bug that I could not find that one in the library, so I will ask here:
I compared the relevant sections:
On master:
My Custom Device which works for me:
Look at the <bank> tags. The master rgd has send=false, and we can see bank selection does not appear in the master MIDI messages. But my configuration has send=true, and correspondingly, the Bank selects are sent.
Depending on the keyboard, if no Bank is chosen, you might end up with a default Bank which is not General MIDI. I may have had send=true from practically day one, but doing the fresh installs to report bugs (using the default Device) is when I first noticed this issue.
Sure I can reconfigure it away on the keyboard after RG starts, but RG will reconfigure again even if you just close a session. On the positive side, when you actually change an instrument on the track, the bank is sent and when you play the track that works fine too. So, all of this is in the RG start up.
In any case, as a user, I do have control over what control messages are sent on start up and can ensure that they are the ones that match my keyboard...it' just a bit obscure.
Also, unless it causes other issues, if bank send=false is the default, why not also default program send=false ? Then there would be no observable keyboard program or bank change on start up?
And controllers appear in the Manage MIDI Devices window but whether to send bank/program by default and which values is not. Is that worth a feature request rather than manually editing rgd files?
Any comment?
I just tested the window portion of this bug again in [bdc5ef] as defined by the bug title. It has been fixed. When the "Manage MIDI Banks and Programs" is closed, the "Manage MIDI Devices" is given focus again, making it visible, and allowing the user to either change the port setting of the newly created device or just close it.
The intervening additional post about behavior seen while checking this, seems like it should be handled in a different bug, assuming it's a bug at all. That problem still exists, and I don't myself have a solution to suggest for it. I currently just use a workaround.
Should this bug just be marked as fixed?
Related
Commit: [bdc5ef]
Oh yeah. I wanted to post something about that. People seem to use rg in two different ways. Either using device definition files or setting up their synths manually and connecting rg to them without using device files. rg supports both. It's a little clunky, though. You'll need to swap out the autoload.rg with your own. You can create an autoload with your setup in it so that everything is as you want it on startup. You can also turn off all the bank/program changes by unchecking those for each instrument. You can also turn off the CC reset in the preferences. I think one way or another you can set rg up to do exactly what you want via autoload, instrument settings, and the preferences.
The default GM-oriented autoload is intended to get new users up and making sounds quickly. It's not really intended for advanced users with their own non-GM setups.
I totally agree with your post with regard to new users. As for me. I do have my own autoload and can manage my setup using that. I'm not saying you should change anything, but consider the following:
If RG is supposed to use a default GM oriented autoload for new users, then it seems like it should send bank MSB=0/LSB=0 which is GM. Currently, the default autoload sends no Bank information at all (send=false)...it only sends the Program change and presumably relies on the users having a keyboard or MIDI input which defaults to a GM bank when no Bank is sent. I had one keyboard which does, and I have a newer one that does not. It's the latter one which caused the really long post...I could not figure out what was happening to the keyboard settings when a fresh install of RG started up (i.e. the default autoload I was using for testing master). I got a Program in a completely different Bank...totally different instrument.
Perhaps it's not a common issue though, but I thought I would mention it.
I suspect that I may have turned off bank selects for the Yamaha DX7. It crashes if you send it a bank select. Since that's such a rare use case and GM is such a common one, turning the bank selects back on in the autoload is probably the right thing to do. I was waiting for feedback like this.
In some sessions, where Bank/Program sends are not wanted, I manually turn off Bank/Select receive in the keyboard itself to avoid this issue, so I have a way around it. In other sessions, I do want Bank sends. But note that when RG starts, the session I intend to work on is not the first on the scene...the autoload session starts and sends its defaults. That might reconfigure the keyboard (or as you point out crash a DX7) before the actual session to be worked on can be opened.
Depending on the work involved, perhaps exposing the Bank send boolean in the GUI might cover all situations, just like the Banks and Controls themselves are easily configurable. If you want to go further, the same would be true for whether an instrument on a track sends a Bank/Program Change overriding that of the session.
I still think this particular "minor window focus" bug should be closed because it has been completely fixed.
If you do decide to create a new "bug" or what's looking like a new feature, post its tracking number here so it's easy switch to it.
While on the subject, what is the significance of the Bank/Program sends in the the record <device> shown in the rg files?
The checkbox between Bank and the bank droplist on the Instrument Parameters panel turns bank selects on and off. Same with the checkbox for Program.
That looks like a bug. I'm guessing we don't differentiate between record and play devices when writing out the file. We've had that problem elsewhere.