| Users sponsoring this issue (Total Sponsorship = US$ 460) |
|
|
Hi LCut. Thanks for kickstarting the sponsorship for this issue but I've got some news that might get you up & running pretty soon. Check out my web site which gives some preliminary information about my AAF plugin which is now called ArdourXchange:- http://www.creativepost.co.uk At the time of writing it only supports importing (not exporting) and it's only available for Indamixx - but here's some great news.... If you've never heard of Indamixx it's a complete "studio-in-a-box" aimed at pro and semi-pro musicians. It includes Ardour, along with some other great Linux audio packages which all run under a distro called Transmission 2 (which I believe is a variant of 64studio). Currently, you can buy Indamixx complete with suitable hardware (i.e. a laptop or handheld device) starting at around $499 - but even better, you'll soon be able to buy the software only (on a USB memory stick) for under $100. In fact, I think it's even less if you don't want the memory stick!! That'll get you a working, ready-to-go studio (including AAF support) for not much more than your sponsorship amount. I've probably jumped the gun a bit here because the 's/ware only' version is still being tested - but anyway, I hope that's of interest. |
|
|
Hi John. Thanks for your answer. It's great that an AAF plugin exists, and the Indamixx system looks like an interesting Linux-based system. But my aim here is to sponsor an Open Source AAF/OMF patch for Ardour. I'm a semi-professional sound engineer and use Cubase and Protools software, so AAF support is'nt a problem for me. But I believe in open source software, and try my best to support Ardour as a great open source DAW. Sorry to tell that, but even if Indamixx cost 10 bocks, then it would'nt more interest me. I want to have the choice what hardware and software to use. It's a basic principle of open source world, and I don't want to use Ardour on a propriatary system, even with AAF format support. I know that there're a lots of work to achieve, and all of that can't be free. That's why I open this issue. If there are ways to open your work to the community it would be great ! |
|
|
Well, introducing this feature to the community was the main reason for doing a deal with Indamixx. FWIW I'm treating any income generated by Indamixx as being sponsorship too. Therefore people can sponsor me the conventionsl way (i.e. making a pledge and waiting for others to join in). Or they can sponsor me by buying Indamixx. From a developer's perspective the Indamixx connection delivers 2 important advantages:- (1) It gives users a choice and at least some kind of solution in the short term. (2) People can be using (and therefore testing) software that would otherwise just be sitting on my personal PC, waiting for enough sponsors to come forward. The end result is that people like you (who are happy to wait for the source code) should hopefully get a more stable product in reward for their patience. |
|
|
I would recommend using the official SDK and manuals for interacting with AAF files. I know that there is some work to add this support to Blender as well and both using the same libraries would allow flawless transitions from Ardour for audio to Blender for video editing. http://aaf.sourceforge.net/ I mean why replicate work that has already been done. |
|
|
Hi openmediaforge - you might have misunderstood the problem with Ardour and AAF. Ardour can already support AAF via a plugin (that I wrote) which does indeed use the AAF SDK. However, that plugin is an adaptation of something totally different that I wrote a long time ago for Windows. Therefore although it works, at present it has 3 drawbacks:- 1) It isn't open source. 2) Anyone who wants it would need to be able to build Ardour themselves. 3) Even when installed, it requires Wine (or Crossover Mac) to run. The quest for sponsorship is to enable me (or someone else) to provide AAF support as a standard, open source feature within Ardour itself (i.e. not as a separate, closed source plugin). At the current level of sponsorship, around 300-400 sponsors would be needed to make this viable. But at the time of writing (and despite its apparent popularity) this feature has only 3 sponsors. That's what's holding us up at the moment. |
|
|
IMPORTANT NOTE: If anyone's interested in helping to test my plugin, I've just released a time-limited version, FREE OF CHARGE for early adopters. You can get a copy COMPLETELY FREE as long as you satisfy the following conditions:- 1) You pledge at least $50 to this feature request; AND/OR 2) You already contribute to Ardour in some other way, either financially or technically (developer / translator / tester etc); AND 3) You will not be distributing the plugin for commercial gain Depending on when you install it, the time-limited copy will work at least until the end of July 2010. Hopefully, that'll be enough time for enough people to come forward and sponsor an open source version. There are a few limitations, described in my preceding post (mostly, you need to be able to build Ardour from source). If you'd like a free copy, use the 'Contact' link on my web page:- http://www.creativepost.co.uk/ |
|
|
Hello. I am interested in this being open source, and have pledged $50. I would like to see OMF support too eventually, as my 'other daw' is Cubase, but first things first eh! |
|
|
final cut and nuendo provide xml versions of their sessions this could also be a way to go instead of omf or aaf support maybe its more easy? |
|
|
Just to say that a guy wrote some code for .OMF support in reaper daw, and I've thought it could be interesting here, because he decided to release the plugin's source code. - initial forum (his name is 404notfound) : http://forum.cockos.com/showthread.php?t=24943&highlight=omf&page=4 - sources : http://404notfound.bplaced.net/reaper/ Cheers l_cut |
|
|
I don't consider this work to satisfy the feature request here, but it will soon. I thought that everyone attached to this bug should be aware of stuff I've just committed (to ardour3 only at this time). This is from my post to the ardour-dev mailing list. ------------------------------------------------------------------------------ Thanks to Hannes Breul, who developed code for Reaper under a BSD-ish license, I have just added the ability to import OMF sessions as Ardour sessions. This needs testing and it also needs further development. Right now, its not even very easy to run it because of its use of the uninstalled version of libpbd ... Caveats: * it imports ONLY OMF2 files. OMF1 is not supported * it will not identify audio files that Ardour cannot read (e.g. embedded MP3 files) but no[ problematic errors result from this Build: cd tools/omf make (requirements: sqlite3, sndfile) Run: (ardour3 only) LD_LIBRARY_PATH=/path/to/ardour/build/default/lib/pbd ./omftool [ -v version ] [ -r sample rate ] [ -n session name ] OMF2_session_file this will create an ardour session whose name will based on the omf file name OR the -n argument. it will be created in the current working directory. Future: I don't have much time to spend on this myself. The basic stuff is all there, I've been able to load at least a couple of test OMF sessions from other DAWs and get audio from them. Someone needs to step up and make this puppy their own. Bug fixes/integration with waf/usability fixes/GUI ... its all yours for the taking. I may fix trivial errors, but I need to get back to other things now that this is basically working. Incidentally, this also provides a fairly good guide for how to create an Ardour session from scratch, should anyone want to do this for other "session" formats. |
|
|
On a personal level, there were never enough sponsors to tempt me to get started on this - and now I'm too busy with other projects... :-( Having said that, wasn't there another developer (last year sometime) who wanted to get involved in OMF development? I can't remember his name just now but I'm sure I remember someone who expressed an interest. |
|
|
this is a real newbie question, sorry: how can i sponsor on that issue? i just made an account on tracker, but i dont know how i can actually donate. when i click on sponsor, it shows the sum i d like to sponsor, do i have to sponsor then the same amount through the normal ardour sponsoring paypal thing? thx folks... |
|
|
@calimerox: you pledge an amount here and pay only once the issue is resolved (usually by making a donation to the person who fixed it or to ardour.org and Paul will re-distribute, but we'll get to that later). Then again the chances that ardour will gain OMF/AAF support are slim, see the last comment at https://community.ardour.org/node/8491 but since ardour is free-software, anyone can pick up this issue and claim the bounty. |
|
|
is there reference docs for AAF/OMF anywhere? thx, Arno |
|
|
I don't think there's anything available for OMF anywhere but AAF is still alive (though I'm not sure if it's being developed any more...) However, its previous owner (the AAF Association) changed its name about 10 years ago and is now known as AMWA (Advanced Media Workflow Association). You can contact them here and ask if they've got any documentation available:- https://www.amwa.tv/about.shtml A word of caution though, if you're thinking about adding AAF support to Ardour... At various times I've offered to do this work myself (for Mixbus). What's stopping it is a conflict between the AAF licensing terms and Ardour's (GPL) license. I've forgotten what the conflict is (maybe someone else can explain better...) |
|
|
AAF relies on some technology from Microsoft that is licensed in a way that prevents its use in open source projects. There was an attempted reimplementation (it is basically "filesystem in a file" stuff) by the GNU project, but it was never really finished and wasn't fully compatible with the MS stuff that AAF relies upon. By the way, AAF is the WORST specification I have ever read. It is the epitome of design by committee. The people involved show no signs of understanding at least half of the technology their specification relies on. When I try to imagine a less elegant specification for this purpose, I cannot. And to repeat what is written already: there has never been any documentation available for OMF. At once time, I made a stab at using the library developed in connection with Reaper, but soon found out that it was incredibly incomplete (there are lots and lots of OMF files it cannot open). This is partially because every implementation of OMF has no specification to adhere to, and so they all differ in incompatible ways. |
|
|
Hi Paul - I've studied the AAF license quite extensively and I'm still not sure what the problem is. The license does state that AAF contains contributions from different parties but that each contributor grants a worldwide, compensation-free, nonexclusive license to the recipient, subject to certain requirements. AFAICT those requirements are:- 1) That you must not re-brand the AAF code as if it's your own. 2) If you modify the AAF code you must make those modifications available somehow. 3) If you incorporate the AAF code as part of some larger project, the larger project can use a different license as long as it's made clear that the AAF part is governed by its own (separate) license. You're absolutely right about the design though!! And considering they're supposedly for multimedia use, AAF and OMF have some highly questionable limitations (e.g the fact that they don't support MIDI...) |
|
|
Hi, Have you see this project? https://github.com/PixarAnimationStudios/OpenTimelineIO It seems AAF is supported. Wouldn't it be a good starting point for AAF import/export? |
|
|
Thanks for the heads up! "OTIO supports clips, timing, tracks, transitions, markers, metadata, etc. but not embedded video or audio. Video and audio media are referenced externally." Thats is kinda nice. I'm not sure if/how we can map transitions, also python is going to be an issue (we don't yet bundle nor include a python interpreter nor allow C++11 at this point in time). But it's a whole lot saner than AAF and OMF. |
|
|
I'm thinking using https://github.com/pybind/pybind11 at the beginning. Another solution would be to port the code to C++. |
|
|
Good news! A C++ implementation is in progress: https://github.com/PixarAnimationStudios/OpenTimelineIO/pull/319 |
|
|
Hi, almost ended a C coded, FOSS implementation of AAF for a french television. Currently running as a POC in test with ardour and some interface to build ardour sessions from AAF (thanks to ptformat and session_utils) It's working great. Hope to release it soon, before the end of the year (if some ardour devs are interested in integrating it as an ardour functionality ;) Note that my library is currently only for parsing (embedded/external audio/video files, fade in/out/x, clip/track gains constant/automation, clip positions...), but not for writing AAF. https://github.com/agfline/LibAAF |
|
|
Hi agfline, what is the status of your project? I wrote ptformat, do you need some help integrating this? |
|
|
Also (agfline) which OS's does your project support? AAF makes heavy usage of a Microsoft technology called COM (Component Object Model). Essentially it's a way for programmers to use a standard 'C' coding interface while also writing object oriented programs. I'm pretty sure it got ported to Mac - because many AAF apps run on both Windows and Mac. But I've no idea if it ever found its way into Linux. Are there already apps on Linux which support AAF? |
|
|
@zamaudio, the project was held in abeyance. It was working perfectly until some guy thought it was not enough expensive I guess... I'm currently working on other stuff, but I really don't want to give up on it (It was too much work). So I could resume the project in a few weeks / months when I have time. ptformat was already very helpful, but any help will be appreciated ! @johne53, I don't know about COM, but I know about CFB/OLE file formats, all of those appearing to be the same thing (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/50708a61-81d9-49c8-ab9c-43c98a795242). CFB/OLE/COM is not that complicated, it's actually FAT32 in a file. Since I'm working on Linux, I already wrote a library for parsing CFB (libCFB) which is part of LibAAF, thus I don't see any difficulty in porting LibAAF under Windows/MacOS. |
|
|
@agfline wrote:- " CFB/OLE/COM is not that complicated, it's actually FAT32 in a file. " Interesting stuff.... the earlier OMF format was based on a similar concept from Apple, called bento. Historically though, COM (or more correctly its license) was one of the main stumbling blocks to incorporating AAF support in Ardour - but if you've found a way around that, maybe it'd be worth us taking another look? FWIW Ardour recently added VST3 support which uses the exact same principle - i.e. it uses its own-brand version of COM which (I'm assuming) doesn't need a license from Microsoft. Does your code make use of the official AAF libraries or is it all your own work? |
|
|
My lib only shares a few header files of the original SDK (for constant values macro definition only). Well, what you call the COM part (I call it CFB for Compound File Binary since it is called that way in the spec) was really not the most difficult part to understand and implement (in read only, as I said). As in the FAT filesystem, you have tables (FAT and DiFAT) and sectors, that let you access to a tree structure of nodes (directories) and "files". Basically "files" represent objects, and sometimes refer to other "files" and nodes. An object can describe a sequence, a track, a clip, an effect, a media essence, etc. Finally, the most complicated part in my opinion is to interpret all this mess. The meaning of "classes" and their content, used to describe sequences, clips, essences, etc. with each time a lot of different ways to represent things, despite the standard and the AAF Edit Protocol. That is why there is so much incompatibility between softwares when it comes to the exchange of AAF files, and this is what took me the most time and effort to implement and test against many different files, from different softwares, with different export settings. The low level Compound File Binary format spec : https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafcontainerspec-v1.0.1.pdf?format=raw The data structure of FAT "files" : https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafstoredformatspec-v1.0.1.pdf?format=raw The AAF Class/Object Model : https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafobjectspec-v1.0.1.pdf?format=raw |
|
|
Thanks @agfline - have you thought about posting on the Mixbus forum:- http://forum.harrisonconsoles.com/forum-1.html Harrison Mixbus is based on Ardour and it has a long history of supporting AAF through various 3rd-party apps (one of which I wrote!!) Since version 6 it's had no internal support for AAF but I'll bet there are lots of users who'd like to see it return... |
|
|
I didn't know that ! You're talking about ArdourXchange is that right ? Can you tell me more about how you implemented it ? Is that based on the official SDK ? Do you have Git somewhere ? Yes I know a bit about Mixbus, never used it though. For me the GPL aspect of Ardour is fundamental, and I would love to see free software coming into broadcast and post-production. And for that, the AAF support is absolutely essential. But any improvement to Ardour can benefit to Mixbus so there is no problem ! |
|
|
Yes - ArdourXchange was my baby! It took a long time to get it right, so the original plan was that once I'd sold a certain number of copies I'd donate the code to Ardour. By that time however, Paul had discovered some conflict between AAF's license and GPL - so it all ended up in the skip :-( AxC doesn't have a code repo anywhere but yes, it was based on the original AAF library. Your stuff might be more acceptable, if it doesn't rely on the AAF code + licensing. And Harrison will likely be more amenable to resurrecting it - especially if it can include some experienced devs, such as me and @zamaudio, if he's interested. Ardour had some bad experiences a few years back when it tried to implement OMF - so it's unlikely they'd want to repeat the experience with AAF. Try posting something on the Mixbus forum and see if there's still any interest there... |
|
|
Hi @agfline I just remembered this thread overnight... Did your library ever get to the stage of being released? There's been some renewed discussion about this on the Mixbus forum:- https://forum.harrisonconsoles.com/thread-8998-post-63326.html#pid63326 That's probably a better place for you to announce your library, rather than here on Mantis- Mantis is mostly for bug reports :-( |
|
|
Hi, Another bump to the wall. I have more and more music video to mix for bands and show with which i work usually on stage. Sooooo.. I need to got the sound from the video edit. Sometime it's a cuts, edits... And it's lot of time for re-align all the clips. Any news about this topic ? I can put some € if needed. Not so much, but if it can help ! |
|
|
The core developers have no plans to do anything with this. Recently a github repository was discovered that gets some significant way toward making AAF import in Ardour possible, but the work has not been proposed as a pull request and we do not have the bandwidth to consider it. |
|
|
This the library I referenced: https://github.com/agfline/LibAAF |
|
|
I just took a look at the code and AFAICT most of the files are either uncopyrighted or they're copyrighted to Robin! So I'm quite surprised that the project's been discontinued. Did it ever get to the stage of being runnable? |
|
|
Follow-up to my previous post... It looks like the AAF library contains a pre-built shell script and binary for Linux:- https://github.com/agfline/LibAAF/tree/master/ardour So not easily useable by me but maybe they'd be useful for @wargreen ? If you follow the above link, the script and binary are in the 'bin' folder |
|
|
Hi, It's been quite some time since I haven't work on libaaf. The library itself is quite working well and has been tested against multiple AAF files coming from a variety of editors. Also I repeat, libaaf is currently read only and wont be able to write AAF files. Regarding Ardour, the implementation was left with a working POC, a standalone CLI tool that creates a valid Ardour session (including video mixdown track) based on an AAF file (https://github.com/agfline/LibAAF/blob/master/ardour/ardour_aafimport.cc). This tool was made based on https://github.com/Ardour/ardour/tree/master/session_utils files, hence the copyrights @johne53 ;) If someone wants to implement libaaf into Ardour, I will be happy to help and to provide libaaf support. However I just can't do it on my own. I don't master Ardour's code/architecture, I'm more C than Cpp , plus I have no time to fully work on it. |
|
|
@agfline - please consider making an announcement on the Mixbus forum:- https://forum.harrisonconsoles.com/thread-8998-post-63326.html#pid63326 Maybe just say that you've a Linux tool available for AAF import and you're looking for help with testing and development. The problem with posting here is that this forum (Mantis) is a bug fixers forum. It's much more likely you'll see some interest if you announce it on an actual user forum, such as Mixbus. I'm running on Windows here but the most recent reporter (at Mixbus) mentioned that he's looking for something to run on Kubuntu so that'll surely be the best place to start. |
|
|
@agfline - over on the Mixbus forum, me and another user have been trying to contact you because we can't launch your importer app. Do you still have a runnable version anywhere or is it too out of date now? |
|
|
Lcut / calimerox et al... Just wanted to let you know that agfline's AAF implementation is working now if you're still interested in helping with beta-testing. Unfortunately it didn't work in the official release (Ardour 8.4) but you can obtain it quite easily from the Ardour nightlies:- https://nightly.ardour.org/ I've also started a thread on Ardour's forum where you can post your experiences and suggestions:- https://discourse.ardour.org/t/aaf-beta-testing-suggestions-and-observations/110054 Hoping everyone's still interested after all these years... (better late than never I guess !!) |
|
|
It's just been announced that Ardour 8.5's been released so AAF import should be working now in the official release. Please can someone here try a few AAF imports for us? It's been working brilliantly for me but I'd love to hear if others can use it - any platform would be useful but especially the non-Windows ones. |
|
|
When importing AAF's that use looped or reused audio, a new .wav file is created instead and wrote to disk instead of reusing the existing wav and adding a new region to Ardour track. This caused excessive disk usage after several wav files containing the same information were created. The AAF was exported from Cubase , and the cubase song used the same audio in several spots using the Cubase Arrangment track. |
|
|
Worked well with Win10 to Linux AAF All in One export of STEMS |
|
|
Schmitty2005, I've been trying to contact agfline (Adrien) who's the main AAF developer but I think he lives in France and I've just realised that French schools are on holiday right now - so he might be taking a break somewhere with his family. Anyway, getting back to your troublesome AAF project... do you have anywhere you could upload it so I could download it and take a look? e.g. a Google drive maybe or a Dropbox account? It'd be great if you could upload it here or on the main Ardour forum but AFAIK neither of these sites have ever allowed that. |
|
|
One can have a break with his laptop ;) From my understanding of @Schmitty2005 last post on Ardour forum, it seems that issue is coming from the extract of one essence file per region, even if multiple regions rely on same essence file, leading to a disk space overload. So I guess that what appeared to be "broken external file references" in the log, was in fact missing extracted files when the disk was full. So we have to make the import process extracts each audio file only once and link audio regions correctly. |
|
|
@agfline Yes, any errors I ran into were caused by running out of disk space. As I made more free space, less regions were missing in Ardour when I tried to import again. I don't think there is a need to upload the project. The AAF import function did what it was designed to do. |
|
|
@Schmitty2005- if you do have somewhere where you can upload your session (maybe inside a zip file) I think it might be handy for us to have available as a test file. I looked through my own files yesterday and while I've got various Cubase exports in OMF format, I don't seem to have one in AAF format. |
|
|
Here is a link to an AAF export from Cubase. I used random media clips include with Cubase. It uses loops so it is similar to the AAF import that ate my drive space, but not as large: https://drive.google.com/file/d/18T9mVUE13rUzfyBxyC4q2429vGxXYN5e/view?usp=sharing Hopefully this helps. Let me know if you need another type of export. |
|
|
@Schmitty2005 - if you've still got your original AAF project (the one where you discovered nearly 2GB imports!) please could you keep it for a short while? @agfline has fixed the bug now but it might be a week or so before the fix finds its way into Ardour. I'll let you know once we've made the fix available and it'd be great if you could then re-test it for us. |
|
|
@johne53 I will give it a try. No problem @agfline - It looks like this got pulled to the master branch of Ardour and will be on the nightly build tomorrow. Thank you. |
|
|
Another potentially helpful mention is that Cubase 13 requires a minimum block size of 512 when using Dolby ATMOS. |
|
|
Sorry about the cubase note. Wrong bug....... :) |
|
|
@johne53 Mostly Success! Upon import of the previously used AAF that was about 32MB and turned to 2GB when imported,, AAF Import worked and the folder for the whole project was a little over 32 MB! The only source files in the interchange were the two needed to recreate the import proplerly! When imported into Ardour, I did see an excessive amount of duplicate 'Sources' listed in the source tab. I think it should only show two sources. Regions looked like I think it should, with multiple regions listed as needed to import the project. @agfline You probably are already aware of that though. Attached is a pic of the 'Sources' tab for reference. image.png (68,172 bytes) |
|
|
I don't know if this is helpful, but this was the log output during import of this session. It is much longer, but you can get the idea: 2024-04-25T18:55:33 [ERROR]: format_position: negative timecode position: -2019780 2024-04-25T18:55:33 [ERROR]: format_position: negative timecode position: -2019780 2024-04-25T18:55:33 [ERROR]: format_position: negative timecode position: -1737540 2024-04-25T18:55:33 [ERROR]: format_position: negative timecode position: -1737540 ... ... ... and the last lines: 2024-04-25T18:55:38 [ERROR]: format_position: negative timecode position: -44100 2024-04-25T18:55:38 [ERROR]: format_position: negative timecode position: -44100 2024-04-25T18:55:38 [ERROR]: format_position: negative timecode position: -44100 2024-04-25T18:55:38 [ERROR]: format_position: negative timecode position: -44100 |
|
|
Yes I agree the multiple regions look confusing but they might be intentional... if you click on any particular entry in the region list it'll show you where that entry got used on the timeline. But it'd arguably be just as helpful if there was only one entry and clicking on it showed all its usages simultaneously. Horses for courses I guess. |
|
|
Yes, I agree that the regions list should show all of the regions that are used, and it does do that, and each one selected in the REGION tab on the left highlights accordingly. However, it also possibly creates a new listing in the SOURCE tab for each region that is used. This caused an excessive listing in the SOURCE tab, when in fact, there is only two sources. If someone was to start adding to this import, The SOURCE tab is so cluttered it is almost usable. There should only be two sources listed, not the high amount that are showing after import. |
|
|
Ah, I see what you mean now... in fact looking at some of my '.ardour' files in a text editor I can see that the source filenames got added to the 'Sources' pane, yet also added to the 'Regions' pane for some reason. I'm wondering if this might be a problem with Ardour, rather than with the AAF importer because (internally) it seems to be the same with all of my '.ardour' files - and yet at runtime, not all of them show the same contents for both panes. Strange... |
|
|
Source list: files Region list: regions add 1 file -> get 1 entry in source list, 1 entry in region list split a region -> no extra entries in source list, 2 extra entries in region list |
|
|
Thanks for pointing that out. Ardour AAF import (sources and regions creation) is mostly based on ProTools session import code. I must admit I'm not very comfortable with the Ardour import process and I'm not surprised that some parts still has to be adjusted. I'll take a look at it in the days ahead. |
|
|
Yes, I can confirm that this is definitely an issue with the importer. Here are two screenshots showing the relevant contents from a ".ardour" session imported about 4 months ago and the same session imported this morning. Notice that the "Regions" are now showing multiple entries for each region. In fact if I edit today's import manually (so that it only shows 1 x entry for each region) Ardour's "Sources" pane and "Regions" pane will both go back to looking how they used to. So maybe when adding an entry to "Regions" you just need to check that there isn't already an entry having the same name? Ardour-regions-older.png (40,169 bytes) Ardour-regions-newer.png (85,643 bytes) |
|
|
Apologies if this is just me getting confused but I was looking at 'ardour_ui_aaf.cc' this morning and there's something kinda puzzling me... I noticed these two lines at the bottom of 'import_sndfile_as_region()' :- region = RegionFactory::create (sources, proplist); regions.push_back (region); If I initiate an AAF import after commenting out those lines, I assumed I'd end up with entries in the 'Sources' list but not in the 'Regions' list and sure enough, that's true - for the '.ardour' file. But If I load the imported session and select 'View->Show Editor List' it's the opposite way around - i.e. I see entries in the 'Regions' pane but the 'Sources' pane is empty. Could that be contributing to this problem somehow? |
|
|
To my amazement I've discovered that commenting out the above lines seems to fix the problem (well, almost...) With the lines commented out, I'd wondered how imported timeline regions were getting created and of course, they get created by 'create_region()'. So it's looking like the above lines are in fact intended to create entries in the 'Regions' pane and 'Sources' pane. As I noticed yesterday, commenting the lines out creates an empty 'Sources' pane (with zero entries). But I've now realised that after closing a session then re-opening it, 'Sources' and 'Regions' will then display the correct entries. So I'm wondering if the lines are getting called for each region when maybe the intention was to call them for each source? Does that get us any closer to finding a fix? |
|
|
It is worth mentioning that this the same type of problem in report 9599. https://tracker.ardour.org/view.php?id=9599 |
|
|
It's looking like @agfline must be busy with other stuff so I've pushed a small change which fixes this. All I've done is to move the relevant lines so they'll only get executed once per Source now, rather than once for every Region. I've tested about 10 AAF files here (embedded and non-embedded) and it works with all of them. Please note that this change is only relevant when importing AAF sessions - it won't fix the MIDI issue in report 9599 |
|
|
Thanks @johne53 for your fix ! Since I'm not an Ardour developer in the first place, most of the code for AAF import comes from session_utils and ProTools session import. IMHO a review of ardour_ui_aaf.cc by an Ardour guru developer could be beneficial at some point. |
