|
|
Screenshot_2023-01-07_08-20-37.png (127,360 bytes) Screenshot_2023-01-07_08-22-51.png (128,631 bytes) Screenshot_2023-01-07_08-23-14.png (129,421 bytes) Screenshot_2023-01-07_08-23-47.png (129,115 bytes) Screenshot_2023-01-07_08-24-23.png (129,387 bytes) Screenshot_2023-01-07_08-24-53.png (129,271 bytes) Screenshot_2023-01-07_08-25-29.png (128,841 bytes) Screenshot_2023-01-07_08-26-22.png (121,643 bytes) |
|
|
I'm having this issue, too - In Ardour 7.2 on Windows. I'm hoping to find how to find a reasonable workaround until this is fixed. If you look at my screen shot there are two tracks with CC midi controls. In the lower track the repeated section has edited CC data that remains stable during zoom operations. I'm currently working on the track higher up the screen with the single region of CC data. This will currently degrade with almost any operation - including saving the file, closing Ardour and re-opening it. I'm wondering if the bug is at its worst on duplicated tracks. I have (since I started writing this) and I think the problem might be slightly less bad with tracks made from scratch (rather than duplicated) and notes copied and pasted to the new track. Also I cut the region into two at the tempo change. At this point the section after the tempo change behaved itself after I added some CC data and I eventually got he region before the tempo change to behave by editing the CC data the same distance ahead of where it slipped by during a zoom - since at this stage it was only seeming to slip once. Hopefully there is something useful here to either people wanting to make their CC data behave and/or coders trying to fix the problem. ardour bug 2023-01-14 200143.png (144,313 bytes) |
|
|
was not able to trivially reproduce this. |
|
|
if you could attach a session that demonstrates this behavior, that would be helpful. |
|
|
I have just been able to replicate the problem by editing the control data on the track 'Siren Synth' then zooming in and out again in the time domain. I'm sorry if this upload fails - I'm on holiday in a rural area (hence having more time to spend on Ardour) - which is very nice but the internet is terrible. I'll keep trying. |
|
|
I haven't been able to upload the file because of internet problems. The first track in my project was an imported audio file. I deleted that track to upload my problem project and then had another look at the problem control data. The problem seems to have gone away. I recorded some audio to recreate the presence of an audio track and the problem is still absent. I'll try and get the original file to you as soon as I can, though. |
|
|
'storm bass to upload' provides the root folder of my project and some sub folders 'storm bass root files' are files to be extracted into the project root folder 'cardinal patches' is a sub folder of root 'interchange' is a sub folder of root |
|
|
I don't see the link .... am I just missing it? |
|
|
I'm having trouble with Mantis, Paul. I have sent an email to the address on the credits page. That's you isn't it? |
|
|
Apologies for being late to the party with this. Attached is the session from which I took the screenshots in the original post. It uses SFZ and DecentSampler instruments which obviously aren't in the attachment and which may be a problem. However I've added a track using General MIDI Synth which shows the same behaviour. I attempted to add some some CC1 data on the 2nd 16th note of each beat. All seemed ok until I adjusted the values (not the horizontal position). I saved the session without zooming in the hope you might see the mismatch. I notice a previous bug report 0009142 also related to MIDI automation and involving tempo changes. I do have tempo changes in this session so perhaps the 2 are connected. |
|
|
Re: tempo changes. My project also has at least one tempo change in it. |
|
|
Thanks to Windsurfer152, this issue is now (mostly) fixed. Certainly the most significant breakage is now fixed, but there were a couple of other details along the way that I noticed that need careful attention and probably tweaks to change the behavior. |
|
|
Many thanks Paul. It's really nothing to do with me; I just reported the bug. Anyway I'll download a nightly build and test. |
|
|
Thanks Paul. I am having a much better experience writing control data to my tracks now. |
|
|
Glad to hear that. Turned out that code still had some very deep thinkos in it that prevent snapping to grid correctly. This has now (just) been fixed in commit f1d784afbb0e and you can now drag multiple points with a tempo change in the middle and if they were all on-grid before, they will stay on grid (if they were off-grid, only the point you actually grab will snap) I would appreciate some testing of this in deliberately weird (and normal!) scenarios, so that I be confident about marking this all as resolved. |
|
|
Paul, I have noticed that my recorded control data going into my Cardinal FX channels via sidechains and the Cardinal Host Midi CC module no longer work. This could well be down to something I have done and my level of expertise with this sort of software would indicates that what I am doing could be any distance away from either sensible or practical. I think I would be sending this data directly via a bus track in Ardour but the bus tracks, I think, don't have facilities for recording and sending CC data. So I have done it using sidechaining from other midi channels, and, I'm pretty sure I had it working a week or two ago. If I am wrong or this was never meant to be possible in the first place then fair enough. I will request recording CC data in Bus channels. That, I think, would be the sensible solution to all of this. Sorry to have unloaded all of this on you. I was happy with my little workaround there while it worked but, as I say, having the feature in the Bus tracks would be better anyway. I think |
|
|
@benald: plese clarify what *used to work* and what does not work now. Images generally don't convey a lot (except when they do). |
|
|
I have been playing around a bit more. I have made a simple project to upload and found that of the two control parameters I have set up in the midi track, parameter 1 gets sent to and is available in the FX in the audio bus but not parameter 2. Having one parameter work is better than I thought and the other one not working is probably something I’m doing but a week or so ago I was running five or six parameters each to two FX buses without a problem. |
|
|
I have been playing around a bit more. I have made a simple project to upload and found that of the two control parameters I have set up in the midi track, parameter 1 gets sent to and is available in the FX in the audio bus but not parameter 2. Having one parameter work is better than I thought and the other one not working is probably something I’m doing but a week or so ago I was running five or six parameters each to two FX buses without a problem. |
|
|
Sorry Paul. Everything I have said about a way of sending CV from midi tracks to Audio busses via a sidechain that used to work in Ardour before your fix which don't work now I have fixed by correcting the routing of the CV in my cardinal patches. It was entirely my bad. |
|
|
I've spent a bit of time testing. I included tempo changes, ramped tempo changes, cc data added before I'd set the changes of tempo, edited some of that data after adding the tempo changes, added some new cc data... It's a massive improvement - thank you. I came across 3 minor issues, 1 of which may be entirely an installation error on my part so I'll leave that till last. Snap now works! For cc data, particularly in linear mode, it works in a slightly unexpected fashion. So it allows you to draw or move points to positions between snap values, but the nearer you get to the snap points the more it tends to snap. I really like this as it avoids the need to change the snap value or turn snap off to make small adjustments. But that feeling may not be universal. I didn't find instances of that behaviour in discrete mode but maybe I didn't look hard enough... All the cc data I added after adding tempo changes worked perfectly. Likewise any existing cc data I edited after adding tempo changes. The only thing that wasn't quite right is some of the existing (linear) data lagged slightly on playback. So what I saw in the slider panel and heard didn't tally with what I had drawn and was seeing in the controller lane. Unlike previous behaviour toggling the zoom setting didn't redraw the values. On editing the misbehaving points with the pencil tool - just dragging a few pixels vertically and then replacing - the behaviour corrected itself. Not a big deal; I can absolutely work with the behaviour I was experiencing. The final issue is that while carrying out these tests I got dozens of "ardour: get_connections: Invalid Port" error messages. I only had 2 midi tracks and it didn't seem to matter how many times I disabled and then re-enabled the port I was using. Even with MIDI input disabled on both tracks just switching focus between the tracks was enough to throw the error. Whatever the cause of the error message is it didn't seem to affect the behaviour in the session, but my mechanic has warned me before about the dangers of ignoring flashing red lights. If there's no obvious explanation, and if you'd prefer, I'm happy to report this as a separate issue. |
|
|
1. the first issue is entirely by design. Years ago, Ardour used to have two kinds of snap - absolute snap where things could only be placed "on the grid", and "elastic snap" (I think it had a better name), which is the behavior you see. Somewhere around v5, we dropped absolute snap everywhere. 2. If you could possibly try to create either a small test session or a precise recipe to replicate this, it would be much appreciated. 3. I'll check into this. I would imagine you have "MIDI input follows selection" enabled? |
|
|
Please bear with me; this is a little complicated. I have 2 midi tracks. In one the cc lane uses linear mode while the other uses discrete. In both cases the cc data was created before programming tempo changes. In both cases the cc events are placed at regular intervals. The region that involves the discrete lane is duplicated. Initially the regions overlapped so I edited the start point and first cc event of each region to ensure they would play. That's why the values at the start of each region are slightly different. With no tempo changes everything played as expected. See first screenshot. After adding tempo changes it appears that both discrete and linear events have NOT moved to take account of the tempo changes. So they no longer align with the grid in the same way as previously. I didn't screenshot this. When I zoom in and then back out the linear events appear to have corrected themselves. The discrete events still appear out of alignment. See second screenshot. When I play the session the slider for the linear events does not move as the display would suggest it should, and the audio confirms this. This was partly expected based on previous experience. I've attached session files, both before and after tempo changes. Having saved the relevant information I thought I'd try manually correcting the data. When the vertical position of the linear data points (showing in the correct place but playing late) was edited even minutely it seemed to reset the horizontal position and it played back accurately. Again this confirms what I mentioned in my previous post. But the discrete data was less co-operative. With snap disabled I could move the points to where they should be and playback was in line with this. But with snap enabled I was unable to drag them to their regular positions - snap was offset in the same way as was the case before your fix was implemented. So the issue is hugely diminished from what it was, but there is clearly still something a bit buggy going on. An extra positive is that the error messages I detailed in my previous post did not appear this time. I don't think I changed any settings but happy to park that particular issue for now unless other users report the same behaviour. Screenshot_2023-02-12_20-43-22.png (117,461 bytes) Screenshot_2023-02-12_20-48-56.png (119,032 bytes) |
|
|
so, not a lot of mystery but still a problem to be solved with UI/UX. the line(s) do not update because these regions have their length & position defined in samples (despite being MIDI). as a result, we do not notify of any changes to the length/position when the tempo map changes. this behavior is correct and as intended. what is not correct, and what is not clear how to correct, is that it was a trivial matter for you to end up with a MIDI region with these settings, and that's not intended (certainly, it is not intended to be easy to do, let alone a side-effect). |
|
|
Thank you for the information. I don't completely understand and I'm not clear on why discrete and linear modes behave differently in this respect. However I have had situations when recording a piano track to midi where, if I increase the tempo after recording, some of the damper pedal changes I'd recorded instinctively are a bit out of whack on playback. I guess this might explain that behaviour. In any case the big lesson from this for me (other than learning that taking the time to report bugs properly is time well spent) is in terms of workflow - the thing with which I struggle most in Ardour. So recording note data then finalising tempo changes then adding cc data would seem to be a good rule of thumb. |
|
|
Since ardour 7, we have two different time "domains": positions and lengths can be in either samples or beats. For the foreseeable future, we expect pretty much all things MIDI to have position and length measured in beats. However, there are clearly some operations that users can carry out (on purpose, or by accident) which changes this so that, for example, a MIDI region ends up with a position and/or length defined in samples. Your point about the difference between the discreet/interpolated cases is excellent though, and I should go back and make sure that this is explained (at least to me). |
|
|
Having updated to 7.3 I've unfortunately had another instance of cc messages being ignored or moved. I was using the Expression controller to emulate a natural diminuendo at the end of a note, so that's the lane to look at in the screenshots. The slider in the lane accurately represents what actually happens. Everything starts fine but when we get to the 4th "dip" in b 13 and 14 the cc data is just ignored. Then the 5th drop in b16 doesn't happen until b18. I can't correct it. Unlike previous instances redrawing or moving points doesn't fix the issue. The session was created from a template. I thought the template may have been created using a previous version so I built it again from scratch and just imported the midi data. Same problem, although that also threw up the slightly odd situation of the default mode for Expression cc11 being discrete rather than linear. Screenshots and session file attached. |
|
|
Screenshot_2023-03-02_15-26-42.png (167,855 bytes) Screenshot_2023-03-02_15-27-03.png (167,792 bytes) Screenshot_2023-03-02_15-28-08.png (168,055 bytes) Screenshot_2023-03-02_15-28-23.png (167,912 bytes) Screenshot_2023-03-02_15-28-38.png (168,690 bytes) Screenshot_2023-03-02_15-28-59.png (168,786 bytes) |
|
|
Screenshot_2023-03-02_15-29-26.png (168,258 bytes) |
|
|
No sign of the session archive yet .... |
|
|
I didn't realise the upload limit was 10 items per hour, or per 3600 seconds as Mantis calls it! I set my timer so hopefully here we go... Screenshot_2023-03-02_15-29-41.png (169,022 bytes) Screenshot_2023-03-02_15-30-12.png (168,473 bytes) Screenshot_2023-03-02_15-30-51.png (167,402 bytes) Screenshot_2023-03-02_15-31-30.png (166,979 bytes) |
|
|
I don't know if this helps; that session crashed on me repeatedly when I tried to change the initial tempo of 120 to the 104 I wanted. Then today, working on a different session, everything was working ok in the opening bars at 100 bpm. I then changed to 88 bpm some 20 bars in. I was subsequently unable to position any cc data events with any accuracy regardless of whether snap as on or off. So it does appear that the further you get from 120 bpm and/or the further into the piece you get the more erratic the behaviour. |
|
|
I've uploaded the archive of the session I mention above. I used the archive session dialogue for the first time and can't quite believe the result is only 26kB. I've also included a standard archive. Can you please confirm they both contain all relevant data? On revisiting the session I can see my description was not accurate.; 72bpm rather than 88. While I presume it is related this problem is actually distinct as it relates to adding new cc data. So the timeline is; create tempo change > create new region after tempo change > add new cc data. Bar 22 is where the problems start. "Attack," "Offset" and "Expression" lanes in the Clarinet track. Playback is consistent with what is in the lanes. The issue is that the points are not where I placed them. A point drawn in b22 is placed more than a beat later. By the time you get to entering data in b27 it is placed more than 2 BARS later. This is true whether snap is on or off and whether in Linear or Discrete mode. It is possible to drag the point to the correct position and snap does work if it is enabled. And, unlike the previous example, data is not skipped on playback. But it's not a sustainable workflow and, so far as I know, there is no list editor or similar I can use as an alternative. |
- Anonymous
