I am having an issue with Audacity 2.x – I have had it for a long time.
The issue is – the export folder.
Open MP3 up in Audacity
do my edit whatever it may be
Export Edits to MP3
Save folder is the previous save not the folder where I opened up the MP3. I would like the export folder to be where the opened MP3 came from not the previous file edited. It takes a lot of time to navigate to the folder where the file that I am editing game from… in addition to the main internal hard drive, I have 5 external drives plus 2 NAS drives that I have music stored on.
I don’t see anything setting that would relate to this. Can someone help me? Thank you in advance
Also next time please give all three numbers of the Audacity version you have so that it is unambiguous - see the pink panel above.
Sorry, but Audacity can’t do that. It’s a long standing feature request. We tried implementing this but dragging files in would not modify the export path. Edgar here has a custom Audacity build that I understand might do what you want. I’ll ask him to look in here, but if you used his build you would no longer be using official Audacity.
I’ll add your vote for this feature.
Otherwise, the only slight panacea I can think of is to use Places Bar Editor to set some of your common file locations to the “Places” on the left of the standard file open dialogue. However you will then see them in file open dialogues in other programs too, if they use the standard Windows dialogue.
I didn’t realise the switching of the export folder to that last imported/opened from was in that version, so I tried it. A very desirable feature I think, especially when dragging in also switches the folder. I can already think of an enhancement option for it - don’t make it per project, so that if importing from folder A into Project A then from folder B into Project B, exporting from Project A opens the export dialogue at folder B.
Remind me - what else than the need for code refactoring stands in the way of this folder-switching? Is it dependent on the Windows 7 Open/Save dialogue?
Do you know why we don’t we use that newer dialogue now for the relevant WinNT versions? It doesn’t seem to have any bugs when you navigate to another folder.
Other comments on this build:
I changed the “Unselected Peak” background colour but this made the Selection Toolbar TimeText controls just a small “bump” where the controls should have been.
The Manage .cfg feature in Preferences is nice. With the save and load feature included, that would make we want to release that feature, though I would not force user to restart on reset, just reset when user restarts anyway. Even with that GUI reset, we still need a cross platform “easy reset” solution for when you cannot launch Audacity.
Anyway, if we want to revisit discussion of that reset feature, it should be another topic.
That’s comforting! BTW that version has an undocumented feature (or bug): new project window cascading/marching has been turned off – all new project windows open at the same size and location as the active project window. I have a new build which has not yet been delivered to the client which turns this feature back on and back ports a small handful of 2.0.6 bug fixes. I am thinking about making this a preference.
This would require some thought; what happens if you Import from folder A into Project A then import from folder B into Project B and then import from folder C into Project C – and you want the dialog to open in folder B? This is almost the exact dilemma the client brought me; initially I had it working the way I liked it, the client had me change it after internal beta testing then, after release, got enough feedback from users to have me change it back the way I originally had it. I set up the code so that a preference switch would be trivial but the client chose not to use a preference switch. This was actually in regard to multiple imports into a single Project but the dilemma remains the same.
The folder-switching code (the client calls this “Smart Folders”), excluding some similar code I have added to Export Multiple, is fairly simple as it exists now; each project has its own new variable which stores the Import folder’s complete path (deriving this path can get tricky on Windows), each of the three places where the code Imports needs to have a few identical lines to derive and store this path information. At some point the Developers plan on re-factoring the Import code so that instead of three almost identical sections of Import code there is only one.
That newer dialog only exists on Vista service pack 2 and newer Windows; It is easy to determine if we are on Vista or Windows 7 but it is very difficult to programmatically determine the difference between Vista service pack 1 and Vista service pack 2. There is a huge amount of new code added to the current Audacity code base in order to implement the newer dialog
I have fixed this. Vaguely, what is happening is that the default Selection Toolbar TimeText controls end up storing a system default font size which is very tiny and makes the controls very small. The fix was to force the TimeText to have a reasonable default font size.
If there is an option then I guess there could be as many choices for the option as you want, but a choice of “use folder for last import in the session” or “last import in the project” seems useful to me. It could be extended to “use folder for first import in the session” or “first import in the project”.
Beyond that, I guess you would want to some way to select a track and choose “Export to folder this file came from”. I’m not promoting that as important for release though.
Yes I understand that we stopped using the new dialogue for file saving from 1.3.3 onwards because we added the “Options…” button into the dialogue.
Audacity continued to use the new dialogue for import/open until 1.3.6, so did we go back to the old dialogue there just for “consistency” of the dialogues?
And so I’m clear, we could use the old dialogues for the “Smart Folders” feature?
I know it wont because I am running the latest version. I posted here because I knew the version that I was running was within the framework. I should have included it. sorry!
I have right click context menu for MP3 setup so that it is pointing to Audacity to edit the file. It would be so easy to pass the directory as the working directory to Audacity at point but there isn’t much that can be passed from the command line currently.
Thanks…
The issue here is that there are no real common “places” as tracts are stored in the following order – artistalbumtrack*.mp3 – they are stored locally with backups on the NAS drives.
File is corrupt cannot open with Winzip nor command line unzip nor any other unzip utility.
I am not sure the reasons behind this – if I am editing a file as because there is a “bad” spot usually from the conversion process from WMA or ACC so that I can play on my IPOD. Sometimes there is a portion that is looped that should not have been looped in the process. I paid for sound editor that now I cannot run because the company sold it to Adobe and now have total abandoned their clients that was using it prior to the sell-out. Any Audacity is so much better. The “workaround” for me is to capture the path from the explorer window and paste it before the file name. Of course Audacity asks me if I want to overwrite it. I also have to save the album art by copying then pasting from within iTunes.
Personally I think that Audacity needs be able to have the current directory pass to it as the working directory for the opened file. I have setup Audacity to be available through the Windows context menu.
We need a complete solution for all scenarios, dragging in a file being the one that is “hard”, because dragging in bypasses the file open dialogue routines.
My apologies to the original poster Gale and I have hijacked your thread.
Agreed, if I do create a preference switch it will be either First Imported or Last Imported.
This is way before my time, the first Audacity I saw was 1.3.8. The dialog that I use can have the “Options…” button – I chose to change the button name:
On Windows there are at least three types of dialogs which can be used starting with Vista service pack 2: generic wxWidgets (cross-platform compatible); original pre-Vista service pack two (currently in use); new style (the one I use). I have no idea situation is on Mac & Linux. I can’t imagine that anyone would write operating system or widgets code which did not allow you to seed the dialog with a specific folder – given that I cannot imagine that it would be hard to add the Smart Folders feature to any Save/Export dialog.
George, again I want to apologize that Gale and I are discussing the implementation of this feature request within the body of this thread! Gale also had problems unzipping the file but eventually succeeded. I do not know what the problem is; I have not had any other complaints and the file has been downloaded and unzipped successfully by the client and others.
The reasoning behind this is quite complicated and has to do with cross-platform compatibility (Audacity runs on Mac, Linux & Windows XP and newer) as well as Audacity’s need to support older operating systems. Getting this right on all three platforms would be a huge development project and would require significant modifications to the current code – not just adding new code. This modification of existing code could easily introduce subtle new bugs and would require extensive beta testing.
OK - I have not seen a patch associated with “Smart Folders” - but you’re saying that if there was such, even it was got to compile on Mac and Linux, it might not work correctly?
If it could be proved to work cross-platform, that provides some impetus to perform the code refactoring deemed required by the developers before we can achieve AUP drag in and “export to the folder the file comes from”. Both of those are perhaps not “glamourous” features but IMO are a big usability improvement.
There is a lot of code to add the dialog but after you have the dialog there is only a few lines of code to add the button.
That link is correct.
I think that Smart Folders should work on all three platforms but it is my understanding that Audacity uses custom file dialogs on each platform with OS-specific code so would require someone familiar with each platform’s file dialog code to do the actual coding. Obviously, it would require testing under all the possible OSes.
On Mac, the Audacity Open and Save dialogues seem identical to those for other apps.
On Ubuntu, the Audacity Open and Save dialogues seem to be customised for no obvious functional reason.
But if the code that detects where the file comes from is agnostic of the export dialogue, shouldn’t it work with the existing dialogues on any platform?
All this said, the only thing (big as it is) that prevents us fixing this today is that dragging in files fails to modify DefaultOpenPath. File > Open, File > Recent Files and File > Import > Audio all do modify DefaultOpenPath (on my testing on all three platforms, anyway).
If you look at lib-src/FileDialog/ you will see that each of the three platforms has an entirely different source code directory; a Developer familiar with each OS’s file dialog would need to modify that specific code branch. I am sure that it is fairly easy to do so but it would require familiarity with that OS.
I think that opening the file via the CLI sets the DefaultOpenPath to the CWD (folder in which Audacity resides). Windows also does this weird thing with file shortcuts where it abbreviates the actual full path which causes DefaultOpenPath to be corrupt; the way to decode this differs between XP and newer Windows.
Once again, I do not believe that this would be hard to accomplish but I do believe that it will require someone familiar with the file dialog code in each of the OSes and careful beta testing on all OSes.
Thanks for pointing out where those source files are.
I assume the “additional button on Save dialogs” mentioned in the cpp files is the “Options…” button.
I’m not really clear why the functionality we want impacts on the specific file dialog used.
Or are you saying it affects the FileDialog*.cpp files, irrespective of the specific dialog used?
I think so few people open files at the command-line, it could almost be disregarded for the sake of a provisional fix.
But I tested it on Windows 7 x64 and for me, opening an audio file from the Windows command prompt doesn’t change the already set DefaultOpenPath. For example, an already set (listed in .cfg) DefaultOpenPath of D: doesn’t change in response to launching Audacity with:
If I initialise audacity.cfg then launch Audacity with one of the above commands, then DefaultOpenPath is not listed in .cfg as expected, but File > Open seems to be what I last used before initialising .cfg (I tested twice with different last directories). So there must be a registry setting that Windows saved?
Do you concur with those findings using released 2.0.5? Your custom builds look as if they do something different.
I notice there are three “Feature Request” votes that command-line file opening should change the export path to the current directory, so those users want another behaviour again.
Thanks for the reminder.
Perhaps you would not want to, but do you think you could make a patch that only fixed bug 550 for Windows (perhaps that did not even add a preference, but just forced DefaultOpenPath to change after importing a file by any method)?
Or don’t you know yourself how force DefaultOpenPath, given your builds don’t do that either?
I am just wondering that if there was a proof of concept patch for Windows that it may get Mac and Linux developers most of the way too, and give some motivation to do the code refactoring that is deemed important.
@ Ed - your post I was replying to seems to have gone, sorry, but much of it is in the quotes.
I am still a little confused as to which dialogs we are using now for releases on Windows. Is it the standard wx Open and Save dialogues, where the Save dialogue is modified by addition of the “Options…” button?
Do your Smart Folders builds work on Windows XP, and the dialogue there is the pre-Vista SP2?
In fact 2.0.1 which bundled modules doesn’t have DefaultOpenPath reset to CWD by launching it from the command-line. So I guess you actually have to be running a script to trigger the bug?
Given the feature requests to use CWD from the command-line, should that bug be left unreported for now?
As I understand Vaughan’s position, the solution of providing a preference to use DefaultOpenPath for ExportPath is “simpler” (or it would be, if all the import methods actually set DefaultOpenPath).
I think it is desirable that any import (including using File > Open…) sets DefaultOpenPath. As it is now, your special builds have the “inconsistency” that an import other than from the FileOpen dialogue sets ExportPath but not DefaultOpenPath, but an import using FileOpen sets both paths.
I think they could imagine the behaviour from a one line description, but will be more fired by a patch.
I’m guessing that a patch that for any import method, sets DefaultOpenPath to the folder the file came from would be preferred to your solution of a global variable. It not only fixes an inconsistent behaviour but lets us provide a preference to “Export to last opened folder” for any import method.
Given the “Preferences creep” fear, that Preferences option may be all that we’ll get to start with, despite other options such as a default folder and first opened folder may be useful.
I agree the developers would still want to refactor first, but are they ever going to do it in isolation without knowing for sure that DefaultOpenPath can be set for any import method? I’m not sure I would want to test a refactoring patch without knowing that bug 550 is fixable by Vaughan’s preferred method.
[Aside: what does the NewImportingSession parameter in .cfg do? It seems to appear the first time you use File > Import > Audio… .]
Very weird – I did not delete it; as you say the important stuff is in your quotes…
The Smart Folder part would work on Windows XP and its old style dialog. The build for my client will not work on Windows XP due to other features.
The bug is not that DefaultOpenPath gets reset but that CWD gets reset to:
…winReleasemodules
when it should be:
…winRelease
After giving it some thought, I agree on this.
I think that a Smart Folder patch without the re-factoring and with no new preference switch does make a lot of sense. I have a broken collarbone and I’m not doing much coding right now. I might give it a try – no promises.
This is a new one on me; searching…
Find all "NewImportingSession", Match case, Whole word, Subfolders, Find Results 2, "Entire Solution", "*.cpp"
srcMenus.cpp(4627): gPrefs->Write(wxT("/NewImportingSession"), true);
srcimportImportFFmpeg.cpp(307): gPrefs->Read(wxT("/NewImportingSession"), &newsession);
srcimportImportFFmpeg.cpp(315): gPrefs->Write(wxT("/NewImportingSession"), false);
Matching lines: 3 Matching files: 2 Total files searched: 343
I have no idea what it’s doing. It is set to TRUE only on any File/Import/Audio… menu driven Import attempt - successful or not. (This is poorly coded, it should only set to TRUE on a successful import and I assumed should work in all Import gestures). It is set to FALSE only during an attempted FFmpeg Import (I suspect this is poorly coded, also for a similar reason, though I may be wrong here as I have not carefully analyze the code). It is certainly not robust as there are a few other methods of getting into the FFmpeg Import code other than File/Import/Audio…
I had started a thread on this topic in another forum just a few days ago and was advised to post here.
Audacity is the GREATEST and I really hate to have a complaint. But when I click on “Export”, the folder is not the same as the one I imported from. Countless times I have forgotten to look at the export folder and as a result could not find the file where I expected it to be. Gale Andrews advised me that this is a very tough thing to be fixed for all circumstances and am glad that the Audacity team is aware of this and is working on it.
