can ardour put a plugin into a specific region, or are plugins only assigned
on a full track basis? i’ve developed a workflow with my current workstation
wherein i mix by manipulating individual regions at the object level, putting
a reverb on one region in a track but not on others in that same track. can
i continue to work this way in ardour, or are the effects applied only on a
trackwide basis?
thanks,
BabaG
that the GUI continued to work responsively. by the time 3.1 debuts, ardour will use a configurable number of processors for DSP.
interesting. thanks for the info.
most workstations cannot import projects via OMF/AAF in a useful way. you cannot share automation data, and in a number of cases, you cannot share plugins. protools AAF files are not even in compliance with the AAF standard, so you can run into subtle breakage there. the de-facto standard for inter-workstation migration is to export each track as a stem BWF and import the result. it is true that ardour doesn't do a good enough job of making this a trivial operation.
most of the people i know work with omfs still. i suppose, to some extent, this has to do with your workflow, whether you’re doing music or film. i do post for film/video. in this context, things like the plugins and automation are less important than track structure and region positioning. i just need to get the structure transferred properly, which omf seems to do well. i get omf’s from avid or final cut, run them through proconvert (now from solid state logic) and get an edl my workstation can open. i’ve been looking into the bwf thing but it’s extremely limited in that your regions cannot be edited as they come in without handles.
the region-specific plugin thing seems to come from samplitude originally, and is not present in protools, which is still the dominant DAW within the industry. given that a ton of highly skilled audio engineers get along without it, it doesn't seem like a deeply compelling feature. its not hard to imagine a variant of region bounce that would do this in a static way. you could also start (or find an existing) sponsored feature request for this, and maybe someone will implement it.
from a post production useage point of view, the region level plugin thing is an extreme gain in efficiency. it’s far less cumbersome and, potentially saves a great many tracks. my standard template is for 96 stereo tracks. it would grow much larger if i had to move regions to specific tracks for the effects i wanted. seablade has offered a workaround involving automation of plugins but this, again, is more cumbersome than being able to manipulate the plugin discretely from within the region. it’s true that most people get by without this, but, it’s also true that it’s a far more efficient way to work.
this all reminds me a little of the vhs/betamax phenomenon of the past, yeah, one is better, but the other took over. nobody had a car at one time either. users repeatedly suffer under this pattern. think ms windows. if protools is the model, i’d think it would be better to look to what protools will be, rather than what it is. it took them forever to be able to work with stereo files. using a standardization logic, ardour should be a windows app. protools is an industrial standard, and industry is always slow and conservative with regard to innovation. does that description seem appropriate in an oss environment? we waited something like thirty years to get airbags in our cars in the us. there’s always a tension between standardization and innovation. when you’re writing your own ticket, as you are with ardour, do you aspire to be better or to the mediocrity of standardization, a pretty fluid notion in the computing world. obviously, there are arguments for both, time and funding, undoubtedly, being high on the list.
i’ve been watching ardour for a long time and this is the closest i’ve ever been to thinking i could really use it for my production. among the things i have to weigh, now, is its current functionality (how close is it to allowing me to make a clean switchover from my current work environment), how i deal with unanticipated issues (can i get my work out of ardour and into my old system if i find there are problems ardour can’t deal with yet), as well as the cost. while i would very much like to contribute now, i have to consider a looming upgrade of my current software. in that context, i look at the potential for ardour’s addressing of my issues. at the moment, it sounds like my $600 would buy me into an new environment of diminished efficiency with little interest in increasing that efficiency. unfortunately, this puts me in the position of thinking i should just keep watching and stick with my current system. this is frustrating as the main thrust of my current system’s development is into technologies i simply don’t use so my upgrade money goes to buy additional functionality for other users but none for me. still weighing this but, that’s how it looks from here.
if this sounds harsh, it’s not intended to be. ardour looks amazing, the more so given its oss status. i’ll look into region bounce as an option.
thanks,
BabaG
@nirron_r: all true, with the caveat that the definition of “soon” is rather fungible.
Wow, that’s great news for the multi CPU DSP configuration. 
I am about to buy a new computer and was desesparing that the trend for the new lines from Intel or AMD is not much increasing power per core but adding more and more cores. So, soon ardour will be able to exploit the relativly cheap quad and future hexa cores, this would make 96khz sample rate edition possible wich i doubt is currently when you have a large number of tracks and plugins, unless you want to freeze or desactivate frequently some of them of course.
You deserve muchos gracias for this, another argument for my next donation
ardour runs all DSP on a single core, by design. your quad core makes no difference. this was a design decision made at a point where dual processor systems were still considered cutting edge, and we preferred to leave the 2nd processor free to make sure that the GUI continued to work responsively. by the time 3.1 debuts, ardour will use a configurable number of processors for DSP.
most workstations cannot import projects via OMF/AAF in a useful way. you cannot share automation data, and in a number of cases, you cannot share plugins. protools AAF files are not even in compliance with the AAF standard, so you can run into subtle breakage there. the de-facto standard for inter-workstation migration is to export each track as a stem BWF and import the result. it is true that ardour doesn’t do a good enough job of making this a trivial operation.
the region-specific plugin thing seems to come from samplitude originally, and is not present in protools, which is still the dominant DAW within the industry. given that a ton of highly skilled audio engineers get along without it, it doesn’t seem like a deeply compelling feature. its not hard to imagine a variant of region bounce that would do this in a static way. you could also start (or find an existing) sponsored feature request for this, and maybe someone will implement it.
or, option five, not having access to region-specific plugin workflow, the pt user base has no experience of the efficiency of that workflow and they never say anything. this seems the most likely to me.
BabaG
@babag: i think you’ve missed my point about PT/region plugins.
Its not that PT is a “good” system. However, PT has evolved to meet the needs of its (overwhelmingly professional audio engineering) user base. It would appear that Digi has never been convinced that per-region plugins are important enough to that user base to worth implementing. That could mean at least 1 of 4 of things: the user community doesn’t speak up loudly enough about stuff that really matters to them, that digi/avid don’t listen, that they both agree that it should be added but its too hard, or finally, that is just isn’t actually all that important. for the time being, and in the absence of other evidence, i’m leaning in favor of the 4th option, but i agree that any or all of them could be true.
you may not realize that ardour already supports region-specific gain. that’s not a plugin
and yes, proconvert can take OMF and generate DAW-specific sessions. what i actually said was that few DAWs can usefully import OMF or AAF themselves. this continues to be the case, as far as i know. SSL did talk to me early on about proconvert supporting ardour, but nobody has ever done anything about it. neither i or no anybody who is not at SSL has any access to the source code, so unless SSL perceives some utility in providing support, its not going to happen. of course, nobody needs to talk to use about the ardour format, because its all open and documented. err, well, open at least!
That manual is in the process of being rewritten as many parts of it are VERY out of date;)
Seabladethanks again seablade. dual quad core mac pro with 4gb ram here.
gettig pretty close to thinking i should pick up a drive and try ardour
on it. the two real crimps to my style that i’ve come up with in working
with ardour seem to be:
not being able to exchange projects between differing stations (omf/aaf)
not being able to apply plugins to regions rather than trackwide
other than that, ardour seems very impressive.
thanks again,
BabaG
Yea that is probably the same thread I am thinking of.
And to answer your question, that I think I followed correctly, yes. At least to the limits of your computer hardware(A CPU can only run so many plugins in realtime obviously)
Seabladesooo… i could conceivably, in an extreme example, throw all of my plugins onto every
track and use automation to manipulate them as regions begin and end?
(found this too:
Does Ardour support different effects applied within a section of the same track?
not quite same keywords but found it in forum 
)
thanks,
BabaG
You know I think there was a thread by almost an identical name on these forums somewhere;)
Plugins are non-destructive and per-track based. You can utilize automation to change these plugins and essentially stop them from doing anything to the sound for the various points in time that the region exists.
Otherwise what you will want is a destructive editor, something Ardour is not.
Seabladethanks seablade. that helps.
i’ve been through this:
http://ardour.org/files/manual/index2.html
some but you’ve made the automation clearer.
BabaG
do i have to open a plugin parameter dialog or something like that?
All automation happens on what we call ‘automation’ tracks. These would need to be shown, as they are not by default, but they will be displayed when visible as a track directly under the track containing the region. They can be shown or hidden from a popup menu on the track header. This is hard for me to explain without visuals, but our manual will hopefully be in a better shape soon to at least do a preliminary release which will have some visuals.
At any rate, you draw on these automation tracks with the same object tool you do most edits in Ardour with.
Of course another option is to use TOUCH automation and a compatible controller, no need to have anything open at that point, but compatible controllers with TOUCH automation are few and far between, though hopefully I will get a chance to overhaul our current MIDI setup to allow for easier inclusion of MIDI controllers with TOUCH automation. Though come to think of it TOUCH automation may work fine with the GUI fader, as that is easy to detect TOUCH on, I need to check that though, don’t take my word on it right now. I have been using my MCU for so long some of these things don’t come easily to me anymore sorry;)
SeabladeHmm I just realised I hsould clarify what I would likely ACTUALLY do in the situation mentioned above;)
Normally for things like Reverb to simulate room presence I will put them on a Bus, so I am running a single reverb instance, and use sends from the track to send to the reverb bus. This has limitations due to not being able to automate the send easily(Or at least you couldn’t last I checked, I can’t remember if this got fixed or not–remind me to clarify this after tomorrow I believe), however it in most cases allows me to easily adjust wet/dry mix by simply automating the faders of the track and bus, and still keep DSP load down, and allows me to easily set the reverb once for the room, and adjust the sends as needed to get the proper mix. This is merely a different way to achieve the same thing I described above, but also more than possible and personally I find easier than the per region editing described above, to achieve the realistic results I desire.
As I mentioned though, currently it does not work in all cases I believe, which would be corrected by being able to automate track sends, something I think is doable in A3, but I need to finish up my work on it so I can run it here and test half of these things in my head;)
Seabladethanks for the example seablade. as someone who is learning from afar, not having actually installed ardour yet, maybe you could clarify something. in your example, if i constructed it as you suggest, automating the plugin within a single region, suppose i go on and do some more design and foley work, adding additional sounds and what-not, returning to my footsteps later to adjust them. in this example, do i have to open something in ardour to adjust the automation? do i have to open a plugin parameter dialog or something like that? if not, great! if so, it re-enforces my point about efficiency. having split regions, one effected, the other not, allows me to adjust the fades at will from the main screen as all i need to do is grab the region corners to make my adjustment. these region corner hotspots are, of course, always on screen, whereas plugin dialogs need to be invoked. not a huge deal but when repeated hundreds of times, significant.
thanks for any clarifications,
BabaG
Deleted. Posted in wrong thread.
SeabladeI don't know precisely because i haven't yet used this, but i guess that with Ardour you can move portion of the automation points of your plugins but it's not synced with the clips because the automation is thought to be a track feature and is independant of clips.
In Ardour 2 this is correct. In Ardour 3 Carl already did some work because of a sponsored issue (He was still very underpaid, but hint there folks) and implemented automation to be able to be moved with the region, so look for that when it is released.
makes it easy to do something like a character walking away down a long hallway, to give them a region with no reverb that crossfades to one with lots of verb as they get farther away.
Or automate the wet dry mix and EQ instead of creating two clips;) This is what I do every time. It means that I still only use a single track, only use a single region instead of two, and personally I find it much easier, and more effective as well as more accurate, than destructively editing and then crossfading between two static clips. I realize you said it wasn’t the best example, but my point is that this model works better than you might think at first. There are still examples where I might want to destructively edit something like this, but that I do in an external program, and to be honest i haven’t had to do this in quite some time.
Seabladeok. i’m still here.
i never actually use any plugin automation on a per-clip basis. i just set up a region with the plugs i want, set the way i want, and, if i want them to change, i split the region and crossfade to the clip with the new setting. makes it easy to do something like a character walking away down a long hallway, to give them a region with no reverb that crossfades to one with lots of verb as they get farther away. not a great example, but in this example, i can use only one track and not have to apply the reverb to the whole thing, just the one region where it’s needed. keeps things organized too. i can keep all of my footstep foley in the same place instead of having to move the farther away, echoey footsteps to another track.
BabaG
i guess i should stop now.
BabaG