View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001352 | ardour | features | public | 2006-12-04 19:43 | 2012-01-29 20:35 |
Reporter | mtaht | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Target Version | 3.X | ||||
Summary | 0001352: Run script on export | ||||
Description | It would be nice to have a checkbox and the ability to run a script with args on export of a range or session. It takes a long time to do an export (walk away from the machine, wait), and a long time to encode such things down to other formats (come back, run script) Nice to be able to do both automatically. in my case I'm rolling a script that will push the resulting file to a couple servers, do downsampling, and tag and convert to flac, ogg, ac3, mp3, etc... | ||||
Tags | No tags attached. | ||||
|
what about if ardour wrote a line to stdout that you could wait on? |
|
how would the script get args? what args? quite a bit of specification required here. nice idea though. |
|
I was thinking the only arg provided would be a full path to the exported file. |
|
export range can create multiple files ... |
|
Could live with just the filename(s) would suffice. As for args, perhaps emulating the same % commands as grip provides would work. Those are: %a -- artist %G -- genre %d -- date %N -- track number and so on. keeping this sort of information around in an in-ardour project template would be good... But what I think I'm going to do for now, is roll a dnotify or inotify based script that runs in the background, that: When it spots a new directory created in the "exports" directory, (which wouldn't be a subdir of the project but a separate dir, over nfs in my case) prompts for artist, track number, copyright date, track title, Genre, license, comments When it spots a modified exported wav file (no longer being written), then fire up the conversion script |
|
Nothing like coming in very late to a suggestion, I got pointed here from Thorsten's pdf on recreation of the export dialog... Personally I like this idea for handling many functions that Thorsten has suggested in the export dialog rebuild. For instance exporting to multiple file encodings, automating web uploads, etc. The thing with this, and what it would likely require, would either be a standard command line call, or the ability to define parameters to pass to it or possibilities, ala LADSPA dialogs(Though I would like to keep as much in the shell as possible for this myself). A shell script for instance could be written to take an exported stereo WAV file, convert to Ogg/Vorbis and upload to a server, or set in a sync folder for a PDA. This would prevent having to code into ardour every possible file format, but instead let ardour deal with uncompressed on its output end, and do that right, and let other utilities handle compression, delivery, etc. How ardour would learn of it, I would suggest a single XML file(Or possibly the ardour.rc) that they would be registered in, with the location of the script. The system ardour.rc file could work well for scripts available to everyone on a system, and the local user file for user installable scripts that could go into the ~/.ardour folder. The tricky part of course, as has already been brought up, is letting Ardour know what parameters are available and what to pass for them. Not sure how LADSPA or LV2 handle it, but a similar method would likely work from my limited understanding, where a simple XML file could define parameters and possible values, and possibly even presets to set all parameters to(Or maybe the preset would just be another parameter). The advantage is how flexible this could be, without needing to modify the code of ardour for it. This could allow for batch processing in the script, as well as using a chain of these scripts to emulate it as well. Multiple scripts would have to be able to be run, and the option to run them consecutively should probably be the default until quad-eight core processors becomes standard;) Seablade |
|
This is partially solved by adding a script via OSC, which is in 2.0-ongoing as of now. http://tracker.ardour.org/view.php?id=2071 |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-12-04 19:43 | mtaht | New Issue | |
2006-12-04 21:53 | taybin | Note Added: 0002855 | |
2006-12-05 16:22 | paul | Note Added: 0002863 | |
2006-12-05 16:23 | paul | Status | new => acknowledged |
2006-12-05 16:31 | taybin | Note Added: 0002866 | |
2006-12-05 16:35 | paul | Note Added: 0002867 | |
2006-12-05 16:51 | mtaht | Note Added: 0002868 | |
2007-07-18 22:53 | seablade | Note Added: 0004162 | |
2007-07-18 22:56 | seablade | Note Edited: 0004162 | |
2008-05-03 18:46 | mtaht | Note Added: 0004915 | |
2009-08-17 19:04 | nettings | Relationship added | related to 0002071 |
2012-01-29 20:35 | cth103 | cost | => 0.00 |
2012-01-29 20:35 | cth103 | Target Version | => 3.X |