When I think about other DAWs, the audio and MIDI devices are set in the application’s preferences dialog but then creating a new session would definitely also set the device sample rate to match (I think/hope this might be the default-enabled option you are considering?).
Sadly it’s all more complex than this. There are increasing number of devices that can only run at 48kHz. So “setting the device sample rate” will fail unless the user happened to have opted for 48kHz.
If users actually want to just be able to say “use device Foo at 44.1kHz” from a startup dialog, then the entire DAW has to be able to resample everything and deal with everything that comes from having the hardware SR not match the intended SR.
Are we talking about professional audio interfaces or cheap soundcards soldered onto motherboards? If it’s the former then I can certainly understand why you’d be going in this direction.
Conceptually the ‘session’ doesn’t really need a sample rate (in fact there are other DAWs, you might argue which ‘…hide this from users, it’s not important…’ in which the session is just a container for the content. In many ways, a modern DAW owes less to the model of a multitrack / console / session, and more to a non-linear video editor, in which you assemble some assets / components on a timeline to create the final product. Those components might be in any format / sample rate etc and might have originated from a variety of disparate sources. In fact, some may simply be place-holders to be swapped out with better quality versions or alternate takes later. In that situation, you exactly do want the DAW to hide the ‘mechanics’ of this from you, rather than play the wrong speed, or the wrong time by default, just because the quality may be better that way. The way this is most elegantly handled is to provide user-interface cues / info in the audio clip container(s) on the timeline, which tell you they are not at the same rate as the audio I/F e.g. will be resampled. If you change the audio interface sample rate, the components on the timeline then reflect this. Its the audio hardware which then defines the sample rate, everything else just plays out through it, with whatever conversion needs to be done and the user can make informed choices about minimising its effect on the audio content.
I would recommend this post about “intuitive”. Honestly, we should be aware of that and have it in mind when we judge/evaluate things. There are many people reading this forum so please let’s not propagate that simplistic way of thinking about and comparing things. (I don’t mean to be rude, I’m not native english speaker, so sorry if it sounds like that)
On another hand, there already is an option to “Conceal LV1 plugins if matching LV2 exists” so you would have to add two “filters” on Plugin Manager, one for LV2 and another for VST3. Also, I guess they may not be filters indeed, but general preferences for the scanning plugins process.
Lastly, it actually is in a predictable/logical place: Preferences > Plugins
Thinking about Audio/MIDI Setup window, it is also in a logical place, and it’s really accesible the way Robin says:
OK, fair enough. It’s something I’ve done myself (mixing/mastering on a laptop while on the road) but having a soundcard fixed at 48kHz is new to me.
This is what I’m used to in Samplitude/Sequoia, for example. Decoupling for studio vs working on the road makes sense but as Paul hinted I don’t think it should be the default (or at the very least have a big warning via the audio text (red background or different colored text) on the top right letting the user know about the differing samplerates.
It sounds to me like Ardour is about to achieve another DAW first (unless there are other DAWs that do this already that I don’t know about). Kudos for thinking outside the box.
So my viewpoint, which I stand by, is not as a new user of DAWs but as a user of DAWs (all different kinds including Ardour) for over 20 years. Many people reading forums can choose to believe something as “gospel” or move on. I think everyone understands these things as opinion. It’s certainly not “simplistic” thinking!
The point that @mike3 made and that I agree with is that the option is enabled by default and therefore unless you know about it you will be banging your head against a wall wondering why your VST2 plugins are not showing up. Because it is not directly available as an option in the place you insert plugins it is, in a manner of speaking, not intuitive, IMHO.
What is ‘intuitive’ is, subjective, depending upon your usual workflow etc, but in this case I do think there are some things which are just generally counter-intuitive, irrespective of workflow - and it seems obvious to me that the logical place to put a configuration option is where its effect will be noticed.
I did exactly that - almost literally… admittedly I was trying a new build of a VST2 plug-in at the time, so I assumed I must have introduced a bug that was preventing it from ‘scanning’ correctly, but I think its still valid for more ‘normal’ use cases
@x42 I noticed vst window working properly now on KDE Plasma! Clearly something has changed in the code and now the window rules works correctly even in full screen. Now the plugin window remains on top like it should.
Unfortunately there are a view serious mains issues things that go wrong using 6.5 in stead of 6.3 so I’ll have to re-install 6.3.
3. examples of main issues:
Exporting audio does’not give the same output volumes as your Master Meter says. I never before had to trim the Master. Its is very hard to get the wright output of a nonmasterd mix, its more like gambling now.
After a clean-up many tracks that are in use go silent, and one has to restart the project to hear them again.
Saved settings of the default ACE plugins (formaly a_pluggins), are gone after leaving a project and re-open the project again. Also newly made presets.
Etc. etc. I do appreciate all your work but your official releases really are to frequent and should be tested for longer periods before given free.
I presume installing 6.3 over 6.5 'll not cause damage.
Hope things turn out.
Regards Hans Flikkema
Yes there have been some updates. Plugin windows are not explicitly marked as transient for the parent window (either editor or mixer) when they’re displayed.
It may also relate to new preference defaults in Preferences > Appearance > Quirks
KDE is still rather special. It’s a highly configurable window-manager that by default it does not follow the guideline set forward by the freedesktop.org foundation, but it can be later configured accordingly.
Anyway I’m glad it works on your system now as you’d prefer it.
Nothing has changed there. Can you check if the export-profile that you use has “normalization” enabled?
That is unusual, and I cannot reproduce this. Presets work fine. Would you mind filing a bug report with steps how to reproduce this? – Could you start Ardour from a terminal and see if there is any output there when loading/saving presets? or perhaps Window > Log?
Which plugins are affected?
Some of the Lua scripts have changed (strictly speaking they’re now new plugins, so old presets won’t apply anymore); but ACE-EQ, ACE-Compressor, ACE-Reverb etc, should all be backwards compatible).
Definitely it’s a great job done around that. Made it so much easier and peaceful to get the job done without Alt+Tab windows all the time. This 6.5 version is the best by far until now and I see Ardour evolution coming quickly since the 5.12. Feels like home! Congratulations to the entire team and collaborators behind this.
Thanks so much for quick response Robin,
It affects only the ACE EQ, Comp plugins (3rd party plugins still work fine). In Fact the new setting is saved oké, but not under the setting-name!!. They all return after restart project as -none-, so the setting is there, but you have name and save it again (best before changing!!), and after restart its name 'll be -none- again.
First I have to finish some urgent products (my activities with Ardour are “low budget” releases for Indie Artists, some containing >40 tracks in recording and separated mixing- and Master projects!) so no hick ups at the moment, now safely using 6.3 again. After reinstalling 6.5. (next week I hope) I can look further and 'll bug report when still necessary, maybe my set up was disturbed. I’ll let you know then.
Leaves the frequently pop ups about reading HD errors during loop playing, like others already have reported, and leaves the temporary disappearance of tracks (going silent) in record/mix sessions after clean-up; one has to restart the project; all these are minor issues, far less urgent and already reported.
Let me finish saying that it’s all minor issues, never lost anything. Ardour is a very very fine, versatile and user friendly DAW, competing easily with the big ones like Protools. So no doubts, thanks to your great work!
Doesn’t always get a response, Feature Requests especially get looked at at specific points when planning future development work, which is why they get lost so easily on the forums, and why the bugtracker is a much better place for them.
admittedly I was trying a new build of a VST2 plug-in at the time, so I assumed I must have introduced a bug that was preventing it from ‘scanning’ correctly, but I think its still valid for more ‘normal’ use cases