When dragging a MIDI clip, such as a chord progression, the new MIDI region is given a take name instead of the MIDI clip title. For example, chord progession A I I IV iii would now be called t15.2 or whatever the current take count is at.
This makes a big confusing sources list.
Is there a option ? Or is this a bug from recent MIDI title changes ?
@paul
This is Ardour 8.6 :
This is Ardour 8.9:
It also affects the CUE Tracks as well:
So this is better looked at by saying the MIDI file name no longer gets prepended to the region name.
This was consistant behavior in Win and Linux.
I could not find a setting to change this. Is there one ? Or a bug ?
Could be a bug. I did change things recently to allow imported MIDI tracks to take their names from the SMF in more ways than before. I did not anticipate that it would things created from clips (which shouldnāt go through the same pathway).
Iāll check it a bit later today.
Ok. Thank you. I have edited my post, that this also affects the CUE track names as well.
This should be fixed now in git master (and subsequent nightly builds).
The work I did to provide a new option for naming based on SMF and their contents was centered on importing via the import dialog, not via drag-n-drop. New sources and regions created via drag-n-drop are now named after the file and track names, unconditionally (there is no dialog/interaction associated with drag-n-drop; if you want control over importing, you need to use the import dialog).
Thank you. I gave this a try on a home build of Ardour latest git. When using the MIDI chords, The Cue tracks show the clip name properly, but the region list and EDIT tracks only show the ātakeā name specifically when they are dragged onto an existing track. When dragged into the main area, and a new track is created, the MIDI name appears properly on the region and the in the region list. When dragging to CUE tracks, the name appears properly in the CUE list, but the region list gets the ātakeā name, and there seemed to be a some random issues dragging to create new CUE tracks whether it was going to get a take name or the file name.
to clarify ā¦ there are no CUE tracks. all audio and MIDI tracks can have clips/cues present.
I think you mean āwhen dragging from the list of MIDI clips onto the cue pageā ?
git pull and build again 
Yesā¦
git push first
nothing new showing on github mirror https://github.com/Ardour/ardour/tree/master. Maybe a time delay ?
No time left to build and retest today. I will check the next nightly build when I have some time and will open a tracker if it persists.
Thank you for the quick responseā¦
fair
i had git pushed but it failed because I had not pulled first.
I went ahead and did a build.
EDIT page drag and drops work!
CUE page drag and drops work when adding to an existing track.
What doesnāt work yet is the CUE page drag and drops still get a take name when a MIDI clip is dragged onto the blank area to create a new track.
Fixed. Fixed. Fixed. 20 chars.
Thank you. It is impressive how quick you fixed this! And how well you must know the code.
Perhaps this last commit should be a final 8.9 hotfix? I donāt know whatās in the Pipeline for future releases but I think a fully fixed and functional 8.9-ish plateau release would be nice for new Users and folks that have a life and donāt read the GIT commits every few days (like me). I miss having a battleship version of Ardour to use while you guys try out the bigger and better stuff, on my Studio machine this will be the 3rd version of Ardour Iāve installed in a few weeks and I only have the luxury because Iām a subscriber and know about nightliesā¦ Your development ambitions are admirable but some people just want bulletproof plateau versions to work from and I kinda feel people who are actually using Ardour for production are not being taken seriously at all with all the recent development-maniaā¦
I guess thatās the price we have to pay for this type of development approach. Big companies have QA and test departments, which they clearly donāt have.
So, Iām ok with field testing and personally stay on a stable version for āmission criticalā projects, unless there is a feature that I urgently need.
Meh,
I think we can have some of both waysā¦ Upgrading shouldnāt come with the expectation that established functionality may not work. However I do empathize that there are too many features and not enough daily production testers for guarantees of what may happen in the āwildā.
There are actually very few ābig companiesā in the DAW space.
As Ardour gains more and more functionality, it becomes easier and easier for some well-intentioned change (e.g. being able to import SMF and use only the filename) to break something somewhere else in the software.
And because peopleās workflow varies so much (for example, I donāt remember the last time I used drag-n-drop to import anything into Ardour unless I was specifically testing that functionality), full coverage of all possible issues is extremely difficult to achieve, even with a QA/test ādepartmentā.
There may or may not be a hotfix 8.10 release, but today I am going to merge the pianorule branch and git master will immediately become āunsuitable for actual useā for a period of time.
Maybe users should keep a few older versions of Ardour. Maybe in this case delete 8.9 and install 8.6. Paul and Robin are doing an incredible job and of course with new features bugs can occur. And as Paul also said, the workflow of the users is so differentā¦ I would never have noticed this ābugā. I might notice a bug in 8.6 that another user would never notice. There are many Ardour versions and among them there is maybe 1 version that have a bug that interferes with your own workflow. Thatās why I think you should keep older versions. And maybe finish mixing your project before switching to a major release (e.g. from 7.5 to 8.0). This is my opinionā¦
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.