Activity for musewhirl
-
musewhirl posted a comment on ticket #1693
I hesitate to add another post when you've probably got enough information, but the direction I am guessing in is the following: When RG specifically tells JACK that the transport has started and is rolling, and fails to notify JACK that it has stopped simply because it is the end of a composition, then on some occasions when a new session is started, JACK broadcasts that the transport is still rolling, RG picks that up when the the new session opens and immediately does what it should do i.e. plays...
-
I understand the logging limitations on your part, but your logging provides all of the necessary information based on my last post. If you have a reason for not letting JACK know of the composition end stop, then obviously nothing can be done about it. I must point out that my guess...a total guess...is that when JACK is not told of the transport stop at the end of composition, the SyncTimeout, fSyncTimeout, etc might be affected i.e. at some point the timeout will occur and perhaps that causes...
-
A long post, but can't be helped. Based on observation, I am guessing that this problem occurs when RG is allowed to play a composition to its end without user intervention. After that, no matter what session is opened, that RG instance's log entries are different from then on until it is restarted. In addition, I think it is also responsible for RG randomly starting or stopping by itself for any session after that point because the RG/JACK interaction is different. For this post: Normal means that...
-
So, finally RG can apparently start by itself after all, although the actual cause is still not clear. As mentioned earlier in this post, normally the "button pressed on the UI" message turns up when I hit the Enter key to start play: [RosegardenMainWindow] slotPlay(): bug1693 Starting or stopping playback [RosegardenMainWindow] bug1693 Play button pressed on the UI. [SoundDriver] SoundDriver::initialiseAudioQueue -- new queue has 0 files [AudioPlayQueue] dtor... [AudioPlayQueue] This tends to be...
-
Lengthen segments using "Allow editing during playback" feature
-
I thought RG stopped by itself immediately after I had hit the Enter key to play, but I could not be certain...NB the playback cursor was still at the start when I looked. I checked the logs and noticed that the logs did not mention anything about my stopping via the UI: [RosegardenMainWindow] slotPlay(): bug1693 Starting or stopping playback [RosegardenMainWindow] bug1693 Play button pressed on the UI. [SoundDriver] SoundDriver::initialiseAudioQueue -- new queue has 0 files [AudioPlayQueue] dtor......
-
I've not seen a single start/stop glitch since I moved first to the [bug1693] branch to look for the problem, and then back to [2f2c01]. It might have been related to a master branch I was using at that time. As a matter of fact, I should have added the problem master ID when I opened this bug...at least I could have gone back to it to check. I will work with the re-based bug1693. The logging alone did not cause any xruns as far I know. I only get those when I am actively opening and closing windows...
-
Something I forgot to mention, but doesn't change the fact this isn't a bug. Most of the time, my file manager is sorted by modification date with most recent being first. So, in a directory containing RG directories, the ones I am currently working on are at the top. Occasionally, I go back to a really old session just to look at something, and from then on that old session is among the top directories because it was modified by that lock file, although no other RG file in that director was modified....
-
I forgot to take the lock file into account. The steps to reproduce just happen to cause it to disappear by the time I looked, even though I've seen it in the past :-) So, the directory was indeed modified, just no evidence left to show it. Yes, you can close this ticket...it's not a bug at all.
-
Directory modification date changes when nothing is modified
-
Tested and working perfectly
-
Tested and working perfectly
-
Tested and working perfectly.
-
Tailing the log has revealed some more bizarre behavior, although there is no way to tell if it's just the debug statement implementation. And on this occasion I did not get the thousands of lines mentioned in the last post. NB: the following option should be true: Edit/Preferences/General/Use JACK transport First, a normal sequence after opening a session: [FileDialog] FileDialog::FileDialog(...) [AlsaDriver] renameDevice(): WARNING: Cannot find device 0 in port map [Composition] dtor: WARNING:...
-
I've been waiting unsuccessfully for RG to unexpectedly start or stop play on its own since the new debug statements were added. I don't normally watch RG logs. The plan was to see the issue and then check the log. I was about to abandon the logging branch to move on to test sourceforge master, when I noticed a JACK error (I rarely get them): jack server listening JackEngine::XRun: client = rosegarden was not finished, state = Running JackAudioDriver::ProcessGraphAsyncMaster: Process error JackEngine::XRun:...
-
I know this will sound like flogging a dead horse, but I agree with Ted Felix in that there's also a consistency problem with the original implementation: Open Matrix editor on a segment CTRL-C i.e. make a normal copy of the segment Select a different track CTRL-V to paste the intended copy there Split the pasted copy The Matrix Editor on the original segment remains open In other words, CTRL-V presumably leaves the original segment where it is, while CTRL-click and drag does not.
-
Wrong Matrix Editor window closed during segment split
-
I decided to build [60afb3] again using the dependencies I have used in the past i.e. without libgtk2.0-dev or liblilv-dev, and the problem persists. I would say that something has been introduced to master between [9081ce] and [60afb3] which is causing this issue.
-
Notation Editor notes and text illegible in repeating segments
-
Sounding Matrix Editor notes across different segments
-
Turn repeats into copies misses last segment
-
It's probably a good idea to keep an eye on the original solution to use qt5-styleplugins in bug #1674. If that strange issue bug has turned up here in another form, then perhaps the previous faulty behavior is also a bug? To quote Ted Felix: Ok, then this has me wondering a few things... Shouldn't this just always work? Is this a Qt bug that we are stuck with? Would it be possible for us to fix this for our non-native file dialogs? Is there code we can write to save/restore the bookmarks? Is this...
-
No scroll bar on Instrument Parameters Bank dropdown
-
No sign of this issue as yet. I even turned on "Accept Transport CCs" again since that was originally on when the bug occurred. Yet nothing with the same sessions doing the same thing for a week. There's an outside chance that something else changed in master (as a side effect) hence fixing the bug, but there is no way to be certain. I'll keep this version for another week at least, since it's the only one with the debugging.
-
The edited indicator appears when a track selection changes
-
The downloaded code with start/stop logging works perfectly. It's now just a matter of waiting for the bug to reappear. Today, I went through the same, usual steps I carried when I opened this bug...and nothing. It bowed out with its randomness at turning up. The old adage "Bugs know when they are being hunted" sprang to mind. However, now it's caught between its pleasure of tripping me up and its extinction.
-
So it is intentional that after undo the cursor is reset to where it was before the action was initiated. That one part of your post clarified everything for me. I only ever noticed the automated cursor move when I was recording, and so thought it was related to that. Other cases obviously didn't bother me as much. I just tried a scenario and it did exactly what was intended. I'll give just one example where this doesn't quite work out: Place two segments on different tracks at measure 1, each four...
-
This is probably the wrong ticket to mention this, but I do find myself fighting the cursor in another situation. The problem did not occur in v18.12, so I guess it's new functionality, and not a bug. More often that not, when I use the undo command after a capture, the cursor automatically moves to a location that I didn't expect. There are occasions where this does work, but in my case it often fails to do the right thing i.e. it does not feel like something that can be generally true. A situation...
-
Does anyone need the limiting of the cursor to the current staff ? From the perspective of this bug, it depends on the following scenario: The user is looking at multiple segments of varying lengths scrolling by in the Notation Editor Some segments are long i.e their start and stop are off screen for the given zoom setting The cursor happens to be located at the start or end of a long segment when play is started...in other words, the current staff On stop, does the view shift to the start (or end)...
-
Your guess was spot on. I had originally misinterpreted "manually" to be changing with the rg- file again. But what you meant was for the user to use the GUI to tell RG that a change in port is desired. When you do that, RG's "saved required" indicator comes on and after saving the supposedly misbehaving record connection name was updated correctly. And we know its preserved otherwise because that behavior was previously reported. As for fixing the past stale data, as far as I can tell RG always...
-
I'm not sure if this is what you mean, but for master I visit the following URL with the various branches, including master which I have used exclusively so far: https://sourceforge.net/p/rosegarden/git/ci/master/tree/ I see a number of branches there e.g. fr462-ted (and I wonder who that could be? :-)). If you are planning to have bug1693 show up at some level in that left navigation bar along with is associated "Download Snapshot" link then for me it will be no different than getting master...I...
-
I got lucky, or unlucky, depending on one's point of view, and two occurrences of this issue occurred in close proximity today, one of which I've not seen before. Description: 1. RG was playing MIDI and suddenly stopped, which is why I opened this bug. It actually moves the transport back as far as it would go i.e. the start of the composition in this case 2. I decided to check whether the flags had been set according to my last post, and while the preferences window was open, RG started by itself...
-
So rg is not saving the record device connection? Correct. Is this happening only when it has to find a new one? Can you rephrase that question? Or is it also happening if you manually change the record device connection? The old sessions rg files were never manually changed, but were created using previous versions of RG. Those version and those sessions were in use when I changed keyboards. In those cases, I recognize the old record connection name as an old keyboard, but that can't matter to RG...it's...
-
The following was on: MIDI > General > Accept Transport CCs (116-118): on I don't need the keyboard to send any changes to RG most of the time, so I have now turned that off and can leave it that way. I wasn't touching the keyboard or my computer when the transport stops occurred...RG was simply sending MIDI to the keyboard. I was definitely opening a session when the transport immediately started though. Both seem to imply it has nothing to do with the keyboard. The other settings were off except...
-
The transport starts or stops by itself
-
The bug, as reported, is fixed. When the play and record devices have the same connection name, there is no conflict or change to use another port. But I did notice something which would not have been observed if I had not been involved in analyzing the bug. The autoload.rg for a fresh install starts out with no connection name for either device which is fine: On saving a new session, the playback and record devices currently displayed in the MIDI Manage Devices window are stored in the connection...
-
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...
-
You mentioned that you might not have the right hardware to see this problem. With my previous keyboard, I didn't see this problem either. My guess is because that keyboard only had one MIDI port e.g. 20:0. The only other port showing up in the "Manage MIDI Devices" was 14:0 Midi Through Port and RG never picked that. A newer keyboard started showing this issue. It had ports e.g. 20:0, 20:1 etc and I thought that this problem started because RG had an issue with the subports of port 20. However,...
-
Tested in [5d1980] and works perfectly. The file name column now expands when the window is expanded so its always readable, and in addition the window remembers its size across sessions. Looks closable to me.
-
Excellent. Obviously the defaults have worked in my favor all this time, so I never ran into any issues. I was trying something new when I saw the track selection behavior. I knew it related to Local On/Off and Direct Monitoring on the synth itself. I just didn't know RG's configuration role in it. The THRU Events in the Modifiy MIDI Filters worked immediately, since I wasn't actually working on a track by track basis. RG was already driving the synth using track information and I just happened to...
-
I was going to mention this in one of the MusicXML bugs, but since I"m not familiar with RG regression tests I let it go. In some distant past, when I've had to deal with import/exports like this, I tie the round-trip into the test itself using test XMLs (which can just be strings in the code of course) e.g. Import original.xml Export original.xml -> format function -> rg-export-1.xml Import rg-export-1.xml Export rg-export-1.xml -> format function-> rg-export-2.xml During (1) any unsupported tags/attributes...
-
Just to close this bug off as resolved, that sounds fine with me
-
MIDI notes reflected back to keyboard on unexpected channel
-
I don't know anything about the portInUse function, but see the essentials of the audit logs below. NB: The bug occurs when the connection attribute of the <device> tag in the rg file are identical for both play and record The record device order in the rg file plays a role As observed just today, the audit log does not appear to match what's seen in the "Manage MIDI Devices" window RG fresh install start up This is where RG starts, generates its own autoload and discovers MIDI ports. Since there...
-
You are definitely on the right track :-) It's more that a little annoying though. Imagine you have multiple segments on multiple tracks displayed in a maximized notation editor, and you're following the composition along listening intently. All of a sudden you hear some ugly note clash. You hit stop to investigate and the notes responsible are whisked off screen! Fortunately, although the notation editor cursor has taken you off some place to the last active segment, the transport cursor in the...
-
Originally, I tried using "direction" in the text tool as an alternative since that text appears above the staff when added in RG. However the following problem occurred: Select the text tool Click above the staff Add some text Export as MusicXML Check the musicxml file and it does contain a direction with correct placement above: <direction placement="above"> <direction-type> <words font-size="7.9">Text Above</words> </direction-type> </direction> 6. Now import the same MusicXML into RG and the...
-
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...
-
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...
-
Tested and completely fixed.
-
Works perfectly. And in my case the instrument choices were both valid and convenient. I tested it for both the default install, as well as a completely swapped out Custom Device i.e. with the default General MIDI Device deleted. And I only just noticed your previous comment about master being stable. You're right...the master has been stable enough that I myself am now using it as I go along :-) Certainly beats a lot of so-called stable masters that I've experienced in other projects.
-
Addendum: When the bug is fixed, what happens if the part name is very long? For a track name, it just gets cut off...a segment can be as long as a track. Is the text just going to look like an essay along the segment covering up the note flow? :-) I create my MusicXML files and so can control the part name length. What of other folks who cannot easily change the part name of the MusicXMLs that they have access to? I suppose they could opt for no segment labels, but then again, that preference is...
-
Addendum: All track are also reset when changing the name of a MIDI Bank. I didn't test deletion, but it may need the same handling as deleting a Device i.e. warning when the Bank is in use on a track
-
Updating a MIDI Device with a new Bank resets all track instruments
-
I can't suggest anything yet because not enough information is available. But first I'll make sure you noticed the following which is also going on. Check the contents of the rg file itself at each point a Device is added, port changed and saved. I saw device ids and the name attribute of devices come and go, but the connection attribute is not updated in the file, even though the Manage MIDI Devices window ports are different. I still have connections from an old audio interface that I don't even...
-
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...
-
Works perfectly now on the same old session that had this issue. I open that session with [d0760d] I get four submasters. Stopped that RG, and restarted with [b741a3] and I get eight submasters as per the fix.
-
RG will not start session with previously saved MIDI interface
-
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. This does sound odd given that the General MIDI device is no longer connected to the MIDI output going...
-
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...
-
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...
-
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...
-
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...
-
I should have added in my steps that when I changed to 4 submasters, I increased the number of inputs to 4. I probably would not have seen anything back then. But later I increased the submasters to 8 and that triggered the bug, although I only saw it by chance recently when looking at ports for different reasons. I'll have to be more thorough in my steps to reproduce. Well, I'm glad you can reproduce it now.
-
Minor window focus when creating MIDI Devices
-
I too thought that perhaps there was something wrong with the rg file. Anyway, here is the attached rg along with the steps: I'm using sourceforge master: [d0760d] Start with a fresh install i.e. no autoload, no rosegardenmusic directories Start JACK audio Start RG Hit OK on the welcome splash screen Edit/Preferences/Audio I noticed that Start JACK automatically is checked. I never noticed that before. I thought the default was not to start JACK? Well it doesn't affect the test I unchecked that box...
-
The test MusicXML file.
-
Interesting. I'll detail the steps again as I go along in case I missed something, but I can reproduce it consistently. It does not feel like something that would occur only in my environment. I'm using sourceforge master: d0760d I start with a fresh install i.e. no autoload, no rosegardenmusic directories I hit OK on the welcome splash screen Select Edit/Preferences and check: "Use trackname for segments" Click Apply, then OK Select File/Merge/Merge MusicXML File(s)... Select the attached merge-musicxml-test.xml...
-
I tested this in [d0760d], and it's fixed...a nice bug to see squashed :-)
-
In master [d0760d], I see an issue. I didn't provide any steps in this thread so: Steps to reproduce: 1. Ensure "Use track for new segments" is set in preferences 2. Open an existing MusicXML file: tracks are labeled based on part-name, but segments still have "MusicXML, id=1/" 3. Merge in the same MusicXML (or another): new tracks are labeled but segments have no label at all Since the new tracks created with the merge have track names based on part-name, I would expect those names to appear on...
-
I tested this in master [d0760d], and it works fine now.
-
Number of submaster outs do not match number of JACK audio ports
-
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.
-
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...
-
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...
-
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...
-
This bug shows up in another way, without even using Audacity as described above: Steps to reproduce: Simply rename an audio file in the RG folder Open RG, and the error dialog indicating a missing file appears as expected Select "Locate Missing File" file and select the renamed file The error dialog reappears immediately claiming the file is not in the folder...it is referring to the original filename i.e. not the one selected by the user. The expected behavior was in RG v18.12 i.e. for RG to accept...
-
Although v18.12 worked flawlessly with respect to this bug, there one was thing which I thought harmless at the time and which could be connected to what's happening now. Especially in light of my comment about the loud noise when RG blew well above 0 dbFS when playing the file saved from Audacity. In v18.12, although playing fine, I did notice it took some time for the peaks seen in the segment to appear. Only from memory I recall that even though audio was there, the audio segment was totally empty,...
-
Audacity editing from RG appears broken
-
MIDI audio recording delay from wave file start
-
Undo command unexpectedly moves playback position
-
Since one could consider this an dependency for gnome, you could leverage the "Get Dependencies" page located at: https://rosegardenmusic.com/wiki/dev:get_dependencies There the various flavors of Linux are mentioned, including Debian, and it also contains packages to be installed, in this case the optional qt5-style-plugins. You'll just need to add information about the environment variable. Also, one could say it's more related to GTK+ than gnome since for one I use Debian, but not that particular...
-
Success! I'm glad you raised the question again. Originally, I had set the environment variable, and forgot to install the plugins. I immediately realized and looked at the long list of dependencies. I thought that I might end up with more Qt style config files than I bargained for. So, since this was an experiment, I switched to a different box and installed the plugins there...but then I forgot the environment variable over there, because in my mind I had already placed the environment variable...
-
One more question. Since the last post, I decided to take a quick look at the code. In FileDialog.cpp, I see where the urls for home, examples and templates are set using setSidebarUrls(). However, I see no place where the current urls in the QtProject.conf file are actually read. I would expect there to be a merge/append with these, unless the function always does that automatically or the instantiation of the FileDialog handles it? Have I missed something? FileDialog::FileDialog(QWidget *parent,...
-
Just for other readers, I'll add the missing typo for the package qt5-style-plugins It didn't work for me, probably because although I use Debian on that particular box, I do not use a desktop environment. I just use Openbox as a window manager to conserve resources. The fact that RG dependencies include Qt libraries, whereas Audacity and Audacious both rely on GTK+ doesn't bother me, since GUI themes do not make music sound any better. However, the overwriting of the QtProject.conf file presents...
-
If this does turn out to be something to fix in RG, I should have mentioned that in my case, both Audacity and Audacious store their bookmarks in: ~/.config/gtk-3.0/bookmarks I didn't knowing configure them to do that any more than I did for RG to use QtProject.conf. I assume this is all default behavior, along with the GTK+ vs Qt frameworks. So, if there is some way to configure RG to use GTK3's bookmarks, let me know, because in my mind, I align RG more with Audacity and Audacious than I do with...
-
I totally agree. Besides, RG preferences says "Use track name for new segments", and it was a good idea to use just the MusicXML's part -name for the track name. And now since the track name does not currently have any trailing id=x/y, the segment labels shouldn't either, just as if the track was created and manually named by a user, followed by adding segments.
-
I'm using the latest Debian. On my system, bookmarks are stored under the shortcuts entry in ~/.config/QtProject.conf RG is using that file for its dialog. I identified another application which does work correctly i.e. qpdfview, which also uses that entry in the same file. In qpdfview, when the bookmark is added to the left panel, on closing the dialog (either after usage or just Cancel), the shortcuts entry is updated in the file. It remembers the bookmark when opened again, even if the application...
-
Looks like a local issue then. I know I've seen bookmarks in dialogs but haven't noted exactly when. Some could have been Open dialogs because that is often when a bookmark comes in even more handy. I will keep this ticket open a while longer to see if I can find a pattern. Thanks for letting me know that it works for you since that narrows things down a bit.
-
"Save as.." dialog navigation panel bookmarks are not remembered
-
Import and Merge MusicXML does not use track names for segment labels
-
Playback pointer and autoscroll with multiple segments per track
-
When Merge File dialog is canceled, MIDI output port is deleted
-
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....
-
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...
-
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...
-
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...
-
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.
-
The File name column of Delete Unused Audio Files window is too narrow by default
-
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: Export all tracks (16 by default) as MusicXML...
-
Inconsistent default behavior for new tracks
1 >