View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007862 | ardour | bugs | public | 2019-12-27 02:47 | 2020-01-03 23:46 |
| Reporter | ahms | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Some Other Linux | OS | Some Other Linux | OS Version | unknown |
| Product Version | 5.12 | ||||
| Summary | 0007862: control surface fails to "unbind" from Preferences/Control-surfaces window | ||||
| Description | Altering the "pulldown" in 'Show protocol settings" from the Preferences/Control-surfaces window fails to "unset" the other midi-port items. | ||||
| Steps To Reproduce | Add a control-surface via Preferences/Control-surfaces and enable a control-surface protocol from the checkbox list. Do not choose any available midi-port from the pulldown in the 'Show protocol settings'. Add all remaining respective midi-ports to that same protocol inside the Midi-connections window -- the cross between Ardour-misc(bottom tab) and Hardware (veritcal tab) is used. (this screenshot helps to show where the midi-ports get binded - https://discourse.ardour.org/uploads/default/original/2X/d/dbaa9c1133daa2b87c74642353ba3e61da8d5afd.png ) Close the Midi connections window Go back to the same Preferences window -- and pulldown, select a control-surface midi-port that you know is a valid one. (in 'Show protocol settings' dialog) Go to a midi track(create a basic one), and notice that you do not still have access to a midi-port. (from midi_port_input-pulldown above processor box) Go back to the same Preferences window -- and pulldown, and select back and forth between "two midi ports". Go to the midi track, and notice that you do not still have access to a midi-port. (from midi port input pulldown above processor box) View the enabled midi ports in the Midi Connections window(for the respective c-surface protocol). -- notice that there is more than one midi-port selected. Go back to the same Preferences window -- and pulldown, and this time choose "Disconnected" -- verify the view of the Midi connections window, there is now no midi ports binded. In Preferences window -- and pulldown, this time choose a midi-port, preferably one that does supply a control-surface. The midi connections window now exhibits "one" midi-port binded. If the user does not touch adding/binding midi-ports via the Midi connections window, the pulldown from the Preferences window will continue to work as expected --- which its default expected behaviour is to bind to just only one midi. The workaround to prevent having lost all midi ports -- such that none are available as track inputs (for note-on events), is to select "Disconnected" from the pulldown and that immediately unbinds all midi ports. The Midi Connections window reflects this change. This is a bit of a difficult bug to verify against because the user could be left toggling between the different midi ports and it does not change anything, -- it is only after they have selected "Disconnected" that they are finally able to bind to the midi port that they want. -- it is also non-intuitive for the labelling. ->>the "Midi Control in" in the Midi Connections Window becomes "Generic Midi Control in" when the user adds more than surface control. Suggestion 1: Make the "Show protocol settings" open up the Midi Connections Window, with "Ardour Misc"(bottom) crossing the "Hardware"(left) tabs -- as users can see right away they can add more than 1 control surface if they should wish to. Suggestion 2: Appropriate a good label that does not change for "MIDI Control In" to "Generic Midi Control In" as it becomes difficult to trace later if the user needs to do things later in the same Midi Connections window -- this renaming tends to occurr after a user has added more than one control-surface protocol. I hope this helps to making things a little easier for the binding of control surface settings. The settings seems scattered and is not consistent between the two places (one place appears to target simplicity for setting only one midi port, the other is for multiple midi ports in another place) -- hopefully this can be fixed into the next upcoming release. thanks | ||||
| Tags | No tags attached. | ||||
|
|
"Suggestion 1: Make the "Show protocol settings" open up the Midi Connections Window, with "Ardour Misc"(bottom) crossing the "Hardware"(left) tab" should have been written as "crossing the Other"(left) tab --- for the Midi connections window --- the attached picture also clarifies the correct spelling. |
|
|
Adding the observation that sometimes the "Midi Control In" is not there, instead it says just "Ardour", and then when an additional control surface protocol is added (making it "two" control surface protocols that are enabled).. the "Ardour" label changes all the way to "Generic Midi Control In" ..the addition of another 'surface control' protocol should not force a new label update for the first one ("Ardour" or "Midi <> in") . please review this and let me know why this happens, I'm curious as to why this is taking place,.. thanks |
|
|
Many things are unclear in this report. 1) "Add all remaining respective midi-ports to that same protocol inside the Midi-connections window -- the cross between Ardour-misc(bottom tab) and Hardware (veritcal tab) is used." I do not know what "Add" means in this context. I suspect you probably mean "Connect", but do not know for certain. 2) "Add" regarding control surface protocols. I think you mean "enable", but do not know for certain. The available protocols are always listed, so I am not clear on what "Add" means here. I believe that the entire scope of the bug being reported here is "Port used for Generic MIDI control surface support changes name" ... correct? |
|
|
This should now be fixed in git master. There are still issues with some empty "tabs" in the port matrix, but those are caused by entirely different things and are unrelated to the core issue here. |
|
|
Thanks for this post. |
|
|
ahms, as noted above, I cannot parse your lengthy instructions here. |
|
|
I think you need to mildly permit a bit of simplicity from the provided instructions as the term "add" is meant to desribe things in simplicity.. from above that is correct -- it means to enable a protocol then show protocol settings. If I gave each step-detail, it would be too confusing. Likely that the bug is already known since robin mentions that Midi I/O is told to a recent user that its connection window is experimental. The issue must of been known for a very long time, along with perhaps 2 or 3 other bugs I have mentioned on discourse and here. I suppose you already have this fix in the works but refuse to publicly acknowledge things as there are probably other kinks that are not sorted out. Not to be rude here, but I did put in the time and effort in trying my best so that you can replicate the issue. --> https://discourse.ardour.org/t/control-surface-simple-workaround-fix/102320 |
|
|
we do not "publically acknowledge" bugs in the forums - we have a bug tracker. we generally even discourage the use of the forums to discuss bugs, although it certainly does happen. that's not because we want to hide bugs, but because the forum is not designed to facilitate the process of bug reporting and fixing. giving precise step-by-step instructions is EXACTLY what a bug report needs to be for us to be able to understand and replicate it. there is never any such thing as too much detail to the recipe description. what robin mentioned is that the window some people think is for connecting to a control protocol is not for that purpose at all. we are talking about ways to make this more clear to people. |
|
|
You bugtracker lacks pictures to help clarify instructions. Re-hire someone as you did last time to migrate your forum. There's a good reason why users are not bugreporting things because in-text is not very forgivng to details. Despite even the pictures you can see provided to you as a recipe here, you are refusing to fix this bug. The question is why? |
|
|
There are plenty of bug reports with pictures. See that "Upload Files" section at the bottom of the "Add Note" section? You attach them there, like on thousands of other websites. There 7784 bugs in the database. 2913 of them are marked "open". That's not very good evidence of "users are not reporting bugs". I find your language tiresome and offensive. I have asked you to clarify your instructions/description SO THAT I CAN FIX THE BUG (assuming there's something to fix). You end up lecturing me about our processes and suggest there's some hidden reason for those processes. We didn't hire anyone when we migrated the forum. Robin did it. He has also locked your forum access for 1 week. We try to do everything out in the open, there is nothing hidden going on here. If you can clarify the description such that I can understand what you mean, and there's something to fix, I'll fix it. |
|
|
I find your lack of motivation for explaining why "Midi Connections" << when the user selects midi ports. << The pulldown in Preferences/Control_surfaces++'Show protocol settings" does not "unbind" the other midi port selections. as intentionally ignorant. Why won't you fix this bug? That's the question I am asking you. |
|
|
From your now unlisted post: --------------- There is a bug that the team is refusing to fix because it is too much work. There’s nothing wrong about mentioning it up front because many other users are falling into this same track. They don’t mind if they are told/reported about particular issue – users are ended up working in circles for getting the control surface to working correctly. There’s a bug. And paul is not wanting to address it either. So why bother to send in bug reports if they will just fall on deaf-ears? Just tell us that it is still not fixed. Make a features “todo” , “to fix” chart and that can help us know what parts of the program are not working. Instead the user is left working in circles. No ranting. Just trying to understand why the user’s voice here for trying to understand why certaing features remain unfixed. And why on the bugreport is is not going to be fixed. Paul already insinuated he’s not going to look into it, despite a tons of pictures, detailed procedure and so on. So it’s a bug, and one that a lot of users are having I’m pretty sure. I just don’t get it why you guys are not up-front about because you’re afraid it can make things look too experimental. It’s better to be honest right up-front than having us with half-a-working setup for the Midi mapping of things. And I’m also using the same Midi controller hardware as Paul. So the excuse that “all kinds of different midi” hardware as not supportive, wouldn’t stand very strongly. Just trying to understand why we users can’t poll/vote and root out a bug that is very commonly being encountered for pretty much all users. … but I think I’m seeing what is happening here. Fixes need to be firsrt approved by Harrison Consoles and not from you guys who have no say on certain bug/fixes that can get in the way of another’s agenda elsewhere. If something is broken, then it remains broken going into Ardour 6. I wonder why we are bothering to bugreport things if they are not going to get looked into. ---------------------- There are projects and companies that i've been involved with that would delete your account for this stream of falsehoods, insinuations and repeated misinformation. i'm not going to do that at this point - in some of your posts you seem to be trying to be a useful member of the community. But another incident like this, and I will do that. If you pay to support my work, I will cancel that too. |
|
|
Fix the bug. |
|
|
flexygist << understands the bug and I suppose is able to replicate this. @paul if you are not willing to be pressured to fix this bug because it is too time-consuming then hire someone to help you out on this. Brushing me as anti-wise on this is only making you look like you don't want to fix this. |
|
|
What are you hiding paul? Are you going to delete this bugreport as well? Why do you think I want this bug fixed? Put resources where many users are also having this issue. |
|
|
You've something of a separate agenda going for fixing long-standing bugs like this. I just want an explanation as to why you are not wanting to fix this. It doesn't seem like a complex thing to fix -- maybe it is, all you have to do is provide an explanation as to why this can't be fixed. Instead you brush things aside as though there is no bug reported. |
|
|
I've tried to contact you via email in private but you refuse to provide any reply/explanation as to why you are not bothering to fix the bug. The speculation as to why was brought up publicly because you refuse to provide answers. paul at linuxaudiosystems.com On 2020-01-01 9:07 p.m., ahms wrote: > hi paul, > > sorry for the confusion on the bugreport. > I would of thought a full explanation+pictures on the discourse forum > could yield an easier understanding. > > https://tracker.ardour.org/view.php?id=7862 > https://discourse.ardour.org/t/control-surface-simple-workaround-fix/102320 > > I'm not sure if what you've last commented also encompasses the main bug > that was being reported. > > The added suggestions and observations that was added at the end of the > bugreport were things I thought could quickly be noticed by development > -- such as the defect with the change of labelling. > > You took note of the labelling defect -- and I wasn't sure whether that > was a bug or feature.. so I contemplated on its actual purpose of change > of visibility. > > It appears you directly informed me that the labelling was corrected, > though it's not clear if the general bug is something you were able to > replicate. > > -- the quick summary replication was to fill all available midi devices > in the Midi Connections window, then to notice there is no "unlinking" > when using the "pulldown" in the "Show protocol settings" of the > Preferences/Control_surfaces window. > > ** The discourse topic was created because pictures show in detail where > the issue is --- it also helps to demonstrate/help other users to take > note of the slight defect with the pulldown in > Preferences/Control_surfaces. ** > ^ this was the general bug that was being referred to. > > let me know if you were able to successfully inspect the general bug > reported, or if possibly it is something you weren't able to replicate. > > I will abstain from overwhelming this contact email -- I can presume I > can add more to the tracker should you require more clarification or > possibly a recorded video/demonstration on this system I am using -- if > you are not able to replicate the issue. > > > thanks > |
|
|
At times I can use a Midi port input for a midi track while it is set as a control_surface, other times when I restart ardour I can't. Whatever framework,you're using it does similar oddities with updating the keyboard-shortcut labels after they've been changed in the Keyboard preferences. The fact that it recurrs should make this bug replicable, so that's why I tried to contact you. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-12-27 02:47 | ahms | New Issue | |
| 2019-12-27 02:54 | ahms | Note Added: 0020872 | |
| 2019-12-27 03:07 | ahms | Note Added: 0020873 | |
| 2019-12-30 18:03 | paul | Note Added: 0020877 | |
| 2019-12-31 19:10 | paul | Note Added: 0020884 | |
| 2020-01-01 13:12 | flexygist | Note Added: 0020885 | |
| 2020-01-03 20:43 | paul | Note Added: 0020887 | |
| 2020-01-03 20:51 | ahms | Note Added: 0020888 | |
| 2020-01-03 21:09 | paul | Note Added: 0020889 | |
| 2020-01-03 21:55 | ahms | Note Added: 0020890 | |
| 2020-01-03 22:13 | paul | Note Added: 0020891 | |
| 2020-01-03 22:20 | ahms | Note Added: 0020892 | |
| 2020-01-03 22:21 | paul | Note Added: 0020893 | |
| 2020-01-03 22:23 | ahms | Note Added: 0020894 | |
| 2020-01-03 22:27 | ahms | Note Added: 0020895 | |
| 2020-01-03 22:31 | ahms | Note Added: 0020896 | |
| 2020-01-03 22:32 | ahms | Note Added: 0020897 | |
| 2020-01-03 22:56 | ahms | Note Added: 0020898 | |
| 2020-01-03 23:46 | ahms | Note Added: 0020900 |
