#1670 Inconsistent default behavior for new tracks
Install fresh RG and it opens with 16 MIDI tracks by default, each set as follows with N being the correct track number:
Device: General MIDI Device
Instrument: #N (Acoustic Grand Piano)
Instrument Parameters is populated.
Track Parameters Device drop down contains: Audio, Synth plugin and General MIDI Device.
Open Manage MIDI Devices, click New which creates a New Device (let's call it Custom Device) and for that device click Banks...Click Import and select a device file from the library and Click OK. Give it a MIDI output. Close the Manage MIDI Devices window.
Track Parameters Device drop down now contains: Audio, Synth plugin, General MIDI Device and Custom Device.
To keep things simple, select track 16 and then CTRL-T to create a new MIDI track 17 with by default:
Device: General MIDI Device
Instrument: #1 (Acoustic Grand Piano)
Instrument Parameters is populated.
Choose Custom Device for the new track 17 (assuming it too has a piano)
Device: Custom Device
Instrument: #1 (Acoustic Grand Piano)
Instrument Parameters is populated (Custom Device specific)
You decide that you won't need the General MIDI Device anymore. Select one of the original MIDI tracks connected with the General MIDI Device, although this is just to get immediate feedback...the below happens regardless.
Open Manage MIDI Devices, delete the General MIDI Device and close the window.
Immediately the Instrument Parameters panel is blanked as expected. That's true for all of the original tracks, as expected. But the selected Device in the drop down is bogus...it still says General MIDI Device.
Click and check new track 17...it's fine. It has the correct Custom Device and its Instrument Parameters panel is still populated. Because you just selected track 17, if you go back to the original tracks, they now all claim to be Custom Device, and more importantly, the General MIDI Device in the drop down has finally disappeared.
In fact, if you next select an Audio track and then go back to the original tracks again, they now all claim to be Audio i.e. the display drop down is displaying incorrect information...it's stuck with whatever was last clicked when it should just be blank for all tracks that had the deleted MIDI Device. This can be fixed by actually selecting a Device for the track, in this case Custom Device, and then the Instruments Panel populates and from then on the correct device is displayed for that track. It needs to be repeated for all tracks which had the device deleted.
And another inconsistency for new tracks emerges at this point:
CTRL-T creates a new MIDI track but the default Device is now blank:
Device:
Instrument: #1 (Acoustic Grand Piano)
i.e. tracks no longer get a default Device via CTRL-T, whereas after a fresh install they default to General MIDI Device. Furthermore, using CTRL+SHIFT+T i.e. creating multiple tracks, also allows you to create one track. If you choose one track by this method, the Custom Device is defaulted, although it can be changed.
Conclusion:
1. For tracks, I think CTRL-T should default to a MIDI device whenever there is only one is available. Then the behavior of the single original General MIDI Device and a single Custom Device match up.
2. In addition, if a MIDI Device used by a track is deleted, the drop down should be blanked along with the Instrument Parameters.
3. Also, you might avoid the MIDI Device deletion inconsistency by preventing (or at least warning) if currently used by one or more MIDI tracks.
4. The MIDI Device deletion has no confirmation dialog...click and it's history. So, at least a delete warning would act like a warning that it's being used and that you need to decide on what happens to the tracks or accept the blanking.
Both (3) and (4) might just be a considered new features as opposed to bugs.
Yes. It seems that deleted device are not handled very well. In fact they seem not to be handled at all !
So some random things happen if a device is deleted - certainly a bug.
Actually I rather like the suggestion 3 above - The delete button should not be active if the device is in use. That would mean no problems if an unused device is deleted.
It seems "New Track" (Ctrl-T) only adds midi tracks - Strange behavior if there is no midi device.
So what about this:
1. Ctrl-T adds a midi track - only adds audio if no midi device is available
2. Devices can only be deleted if not in use (I think no warning would be necessary then)
Thoughts .... ?
Adding MIDI by default was fine for me, but having option (1) which you suggested makes perfect sense to anyone who mainly works with Audio.
But the real problem in this case is having CTRL-T add a MIDI track without the MIDI Device defaulted into it ,even though the user has a single custom MIDI Device, just like a new install has a single General MIDI Device. It then has to be added as an extra step. Doesn't seem like much until you try the following:
The result is that all those tracks without a single one having a MIDI Device selected, yet they all default to Instrument #1 on that non-existent device. So, now you have to select the drop down box for each track, one by one.
I am hoping that if only one MIDI device exists, regardless of whether it is RG's original General MIDI device or has been replaced by a user's custom device, then all 16 tracks will have that device selected by default.
And preventing the deletion of a MIDI device in use by tracks is highly desirable and probably the simplest and safest approach. If inadvertently deleted, then it's not just the track's MIDI device drop down that's affected, but every single parameter setting related to that device vanishes e.g. Pan, Volume, Reverb etc. And even if you notice, and immediately add the same MIDI device back, in the same session, the parameters are now set to their defaults. In other words, there is no way to recover all of the tweaked MIDI Device settings on the tracks unless you exit without saving anything.
Only one point on your wording in the previous post "The delete button should not be active". It's only an implementation choice, but it may not be obvious why the button is disabled in that window, because the MIDI tracks are in a different window. From a usability standpoint I'd probably leave the button active and when clicked pop up a dialog indicating why it can't be deleted. Either that or you have to come up with more space the in Manage MIDI window to explain the disabled button.
So it seems Ctrl-T was finding a midi device but not checking that it was an output device - this is an easy fix and then I think Ctrl-T will work as you would expect - finding the custom midi device.
As to the delete button - I prefer buttons that do not work to be inactive rather than letting the user click it and then find out it doesn't work !!!
The tooltip at the moment is:
"Delete the selected playback device. Any tracks using this device will need to be reassigned, and any program or bank changes on those tracks will be lost permanently"
I would change this to something like:
"Delete the selected playback device. This is only possible for unused devices - check for tracks using this device"
Acceptable ? Any other opinions ?
The solution solves both cases:
1. Prevents problems caused by deletion of used MIDI devices and
2. The user knows why they can't delete at that time, bearing in mind that for a fresh install that will mean that the Delete button is always disabled
That would cover it for me at least, although others may have a different opinion.
I've not looked at the code in that area, but it crossed my mind that to determine if tracks are using the device, a variable could possibly have the track number(s) at the point where the tool tip information is displayed. If so, and depending on the complexity, you might consider changing simpler tool tip from:
to a minimal tool tip:
Or ideally:
OK I have made some changes which should fix this.
Note for the case with MusicXML you must used the merge menu to use the existing devices. The import menu will create a new document with the default studio.
Please merge
The use of the term default studio threw me for a while. I think you mean the studio loaded by autoload? Let me know if that is not correct, but it probably will not change the inconsistency claim although I am rewording more carefully now.
I'm not sure why you distinguish the behavior of import and merge in your last post? I'll try to explain here and perhaps you could elaborate.
The Inconsistent behavior mentioned in the title of this bug refers to RG treating the single default General MIDI Device of a fresh install differently from when a user removes that device and replaces it with a single different device from the RG library and for here call it Custom Device.
Default device behavior
You start a fresh RG, import an existing MusicXML and sure RG creates a new document with its default studio, but more importantly, it automatically assigns each MIDI track with both the General MIDI Device as well as an Instrument #1. Please confirm that this happens for you too.
Custom device behavior
In previous posts, I just replaced the device in the current session to keep things simple. But now I want to address your reference to the default studio, assuming autoload is what you mean.
So, I decide that the default studio i.e. autoload is going to have only one device called Custom Device. From a fresh install, I carry out the steps in the previous posts to replace the General MIDI Device with the Custom Device, but this time I save that session as the autoload file i.e. I am making that studio my custom default autoload. And new documents will have my Custom Device from my now custom autoload. And that works just fine.
I now import the same MusicXML file and sure RG creates a new document with the custom studio, because that is the now the default. However, it. does not automatically assign the Custom Device to each MIDI track. It does not assign any device at all. It's blank. It only assigns Instrument #1. Since it did do so in the Default device behavior paragraph above (and hopefully confirmed by you), that is inconsistent.
How about just a device name change
Quite frankly, I am mystified as to how RG even knows that there is a difference. It's almost as though it has the General MIDI Device name hard-coded somewhere :-)
To test that, from a fresh install, I simply exported the General MIDI Device to a file. I deleted the device in the session and imported the device back into the session, and no problem it imports successfully and even has the same name. I then save the session as the autoload. To all intents and purposes, nothing is supposed to be different between the fresh install autoload and this new one...yet there is. Try import. RG no longer defaults the Device like it used to. It's blank :-)
Conclusion
I call that inconsistent. The reason I do so is because to all intents and purposes, it appears to be treating the original device in the distributed autoload as special, while any device loaded from the myriad of devices in the library is not given the same treatment. Neither is even exporting and importing that very same fresh install Device. And, hopefully taking autoload into account indicates that Import MusicXML should also create tracks with the default device.
So, have I missed something along the way?
With the merge the MusicXML tracks are appended to the existing document. This seems to work if the General MIDI Device has been deleted.
But yes import MusicXML is broken if the default studio (autoload) has not got the General MID Device! - I think a similar bug to the Ctrl-T bug.
So - yes you are correct - the behaviour is inconsistent. I will look into the MusicXML import.
I am having second thoughts about my fix for this. With the original functionality it was easy to create a new instrument, delete the General MIDI Device and all the tracks are on the new instrument (or they should be if the track update was working).
So maybe the original way of always allowing delete and then updating the tracks appropriately is better.
Still have to get the instrument switch working correctly !
Maybe wait with that merge !
I'm not sure if the following will be useful for the fix:
We know that the default autoload and population of the Default Device in documents works. So, just preventing deletion would be enough.
Now we also know that if you export the device, delete it and immediately import it again, there is no population of the the device. But preventing deletion would still be enough.
So, you have two autoload files (default studios) which to all intents and purposes should produce identical new documents which behave the same way from then on. But they don't...one populates while the other does not.
If you have the tools to compare the autoloads directly, you would expect them to be identical since we even used the same General MIDI Device name. The only difference might be if there is a property concerning when the device was created i.e. in this case imported (I doubt a deletion would be stored). But everything else should be the same, and not just with regards to the problems we have encountered. ANY differences, should be of concern because code now or later may treat documents differently. Do you agree?
But, let's focus on the one with population of the device. Either try comparing the autoloads directly OR which creating documents from each add a break point in the steps of CTRL-T (or import MusicXML) at the point where the MIDI track gets that device populated and in particular why it does not occur in the custom device case.
I hope that helps.
Thanks for the suggestions.
I have now got a fix which seems to update correctly for Ctrl-T and MusiXML import.
When the Device is showing blank in the track parameters it was due to selecting the input device as a playback device!
Several factors were playing a role here - order of devices, use of invalid instruments etc.
I have now gone back to the original function in the device manager. A device can be deleted even if it is in use. The code now selects an appropriate device and instrument.
Of course there may be more bugs of this sort around .....
For the merge please use the bug-1670-delete-device-update branch
Since the empty Device turned up under so many circumstances, I was hoping that finding the root cause would fix them all...seems like you found it.
If by "gone back to the original function of the device manager" you mean no confirmation or warning dialog for the Delete button, then bear in mind the following. Although the code will, as you say, select an appropriate device and instrument, if that Delete was inadvertent or the user changed their mind immediately, there is no undo for that action. Whether the code selects an appropriate device or the user immediately imports the same one, it will not return the carefully adjusted individual parameters of the MIDI device which were done for every track involved. Depending on the custom library device chosen, that parameter list can be quite a lengthy. I know, because I've been stung once a long time ago. But, on the bright side, after that a warning dialog is not needed any more because it's not something you repeat.
So, your solution is acceptable for this bug and the confirmation /warning Delete dialog, along with perhaps suggesting which MIDI tracks are in use, could become a feature request if you agree that it's necessary.
I take your point about the warning. I have added a warning with notice of tracks being used.
I've reviewed this and I've come up with a number of related test cases that are problematic. We need a regression test plan that covers all the bases.
I'll take a closer look once LV2 is merged.
I've pushed some changes related to this to master [6171ab]. Please test latest git.
I've only just started on this. Lots more to come. Especially in the area of import and merge.
Related
Commit: [6171ab]
I've pushed some more changes to master [d0760d]. Please test latest git...
@musewhirl: Do you have some interesting MusicXML files to test with? Give it a "whirl" (pardon the pun) and let me know how it goes. I'm specifically interested in problems that might arise with channel 10 (drums). Should we skip that channel? It's easy to reassign, so I'm not sure we should worry too much about it.
Now I need to look at all the other imports, then the merges. I have a feeling there are more issues.
Related
Commit: [d0760d]
I've only been reporting against v23.12 because I have to (well...prefer to) use a stable version. In other words I cannot actually switch to git master for ongoing work.
However, I have enough bugs in tracking to risk compiling the master into its own directory and checking them, including this one. Compiling there should be low risk to my environment, so long as I only open disposable copies of sessions. That's because there's generally no guarantee, in any application, that an older version will still be able to open a session altered by a later version.
I'll post the results as I go along.
We try very hard to keep master super-stable. But no guarantees. Some of our professional users do work in master.
Thanks for taking some risk and providing feedback. It's a huge help. I should be back on this Tuesday.
By default, none of the Instrument Parameters' Bank entries are checked. I can see a disabled "General MIDI" in the corresponding drop down. I enabled the Bank dropdown menu on a track which revealed that "General MIDI" is the only entry in the dropdown anyway. I thought it odd that it was not selected, but moved on.
Deletion bug resolved
I created a new track 17 and changed it to the Custom Device. Next I attempted to delete a track using the General MIDI devices. The new dialog appears informing me of why RG cannot carry out the deletion...It lists all of the tracks using the device. Perfect! Same when trying to delete the Custom Device...this time only track 17 mentioned. Now I cannot find a route to the previous inconsistencies which resulted in the opening of this bug. So, it's resolved.
Channel 10
About channel 10. Dealing with defaults is always difficult, but the MIDI tracks fall into two types: percussion and non-percussion:
Percussion tracks
For percussion tracks, the percussion is still in a Bank somewhere, so it feels like a Bank dropdown should be there and defaulted to it. I usually expect to see a default like 127:0 "Standard Kit" (or whatever the MIDI standard dictates). That can all be done via the rgd underlying the device. To check, I exported the default device as an rgd and could not see it implicitly linking the percussion to a Bank. In fact, I could not find a match for it in the RG library directory either...I think the one provided by default in RG itself should also appear there so it can be imported again if deleted. If that rgd had the "Standard Kit" (bank 127:0 with percussion=true), then Bank automatically shows up along with the kit name for Program when percussion is checked.
Besides, an rgd file can contain other percussion banks too along with General MIDI i,e, 127:1 "Rock Kit", 127:2 "Jazz Kit" etc. and when it does, the Bank dropdown does appear for those along with Program containing those Kit names, so they can be distinguished.
Non-percussion tracks
Also for non-percussion tracks, if there is only one Bank in the dropdown (in this case General MIDI), shouldn't that Bank be enabled by default with that entry displayed?
Conclusion
I think that having percussion checked on channel 10 by default is fine, but it should also have Bank showing whatever the "standard" General MIDI Bank is (e.g. 127:0) and Program with the standard General MIDI kit name (again I've often seen "Standard Kit").
Finally, although it would be a different bug, while testing I accidentally deleted the device in the MIDI Recording section of the Manage MIDI Devices. Gone!!! I was so focused on the Delete button, I forgot there were two. Again, no warning and I could not even remember what was there. I wonder if that causes any unexpected issues when recording?
Any thoughts?
I'll report on MusicXMLs imports when I've tested those.
As mentioned above, the deletion of MIDI playback devices is now resolved by the fix for this bug. Import MusicXML was mentioned "along the way", because it caused tracks with no MIdI Device to turn up which led to the same situation as deleting the device.
I think that the additional default numbering fix of the instruments is tricky. First, we already have questions about instrument #10, which never turned up before, since all were defaulted to instrument #1.
Here is another aspect of the problem for Import MusicXML:
Right off the bat, instrument #10 showed up as a percussion track, when none of the tracks were intended to be percussion tracks. I'm not even sure if the MusicXML standard would even have a tag in the MusicXML to alert you to when they are. Seems like there is no way to know. In this case it feels like it should be treated like the other tracks i.e. not a percussion track.
So RG then creates a new document on Import MusicXML and the default studio (autoload) comes with only one device. it still seems appropriate to default all tracks to that device. And that works just fine, like previous versions.
Unlike previous versions, this fix has each track now get its own instrument number, which happens to match the track right up to 16, including the problematic #10...But since I had 20 tracks, the last four default to #1 like the previous versions. Another difference between tracks. The user could be given options during the Import like they get with MergeXML, but that's even more work.
Perhaps just having thee default Device on each track is fine, and like in previous versions, let each track default to instrument #1, since some will have to any way, and the #10 decision goes away?
I'll have to try out the MergeXML next, but perhaps you may reply to this part before then.
I didn't find any issues with Merge MusicXML. I merged starting with both less than and more than ten tracks. The results were the same. All tracks got the default MIDI Device and all tracks were defaulted to instrument #1.
Just pushed some cleanup related to this to master: [002a84]. Please test latest git.
Only broken test case left is deleting all MIDI devices and then merging in a MusicXML file. This gives us the bogus device issue that was originally reported here. I suspect the best approach would be to fix this in the merge process. Make it fall back on the first softsynth in this case. The new
Studio::getFirstMIDIInstrument()should be helpful for this.We should also look at all the other import and merge cases and make sure they work. E.g. ".rg" merge is really important and should benefit from everything we've learned here. Then there's .smf import and merge which is also extremely important. Other file formats are lower priority.
Remaining TODO and test cases:
Studio::getFirstMIDIInstrument()in case the autoload becomes interesting.I'm taking a break from this and switching to release prep. 24.06 is fast approaching. Leaving this one open.
Related
Commit: [002a84]
Merged final changes as [faf2ef]. Please test latest git.
All import and merge cases should provide valid (though maybe not convenient) instrument choices.
Related
Commit: [faf2ef]