Hi Ardour/Mixbus Friends!
For any who may be interested an updated ISO of AVL-MXE has been released:
Thanks and be well!
Glen
Hi Ardour/Mixbus Friends!
For any who may be interested an updated ISO of AVL-MXE has been released:
Thanks and be well!
Glen
Just an FYI that I downloaded and ran âliveâ and unfortunately when Ardour starts scanning plugins for the first time wine-staging has a meltdown and crashes.
I read manuals, remember?
Well then I guess you didnât read Page 68âŚ
PLEASE NOTE The first time Wine-Staging runs on your computer it needs to configure itself and set
up itâs directories in a hidden â.wineâ directory in your User home folder. Wine-Staging does not run itâs
setup until the first time it is called to run a Windows program by the host system. If the first time Wine is
initiated is during a plugin scan within a DAW it is possible the initial Wine configuration setup will occur
as you are running the LinVST plugin scanner which ensure the renamed â.soâ files of the Windows VST
Plugins show up in your Linux DAW. On some systems this may cause the scan to time out, fail and not
completely finish. Once Wine has set up itâs initial config you should be able to run the plugin scan again in your DAW and it should be able to successfully complete.
I set myself up for that one
So question: why does this still happen on a live ISO? Does the MX snapshot stuff do something odd? Is the answer on another page of the manual?
There are 2 things afoot hereâŚ
Wine-Staging has always often crashed on the first run of a plugin scan especially if there are a lot of Plugins and it is mostly due to the fact that itâs juggling too much to run the scan executable and write itâs config, sometimes you get lucky and it doesnât crash on a Live session but usually it doesâŚ
I usually run LinVST just before I build my ISOâs and this time due to a last minute Plugin addition I installed an updated Plugin package (also containing the Windows example Plugins) and forgot to re-run LinVST so the pre-written LinVST â.soâ files in that Plugin package were stale⌠So LinVST would need to be re-run before the initial Ardour VST Plugin scan for the Plugins to work anyway⌠but the fact that Wine-Staging usually crashes on the first run in general kind of masks this and I thought it was a good teachable moment especially for new folks on how the process works anywayâŚ
But⌠as you may have suspected, I am indeed an idiot!
In the future I may just pre-run ALL of Ardourâs stuff and pre-populate it in the Userâs home then everything should âjust workâ but the downside is the User wonât have those initial setup choices provided by the first run of ArdourâŚ
I always just breeze past those setup screens with default options knowing that I can always change them later. Experienced users who already know they need a different choice will know where to look and new users really wonât know what works until they check out the default values Thatâs my read on it anywayâŚ
Hi!
Just posting a âquietâ update here that fixes a few annoying issues on the last released ISO:
OhâŚ
And BTW the Ardour config is pre-populated in the Userâs home on this last ISO updateâŚ
Thatâs bugged me for so long - the first time you run ardour, youâre presented with choices which you donât really know the answer to until youâve already run it for the first time - and then you probably have to change them anyway
The problem is that there are no good default-defaults for a lot of those things.
If thereâs more than one audio interface (and thanks to HDMI, there almost always is on a desktop system these days), we have no idea which one the user plans to use.
We have no idea what their monitoring situation is, or is desired to be.
We donât know where they might want to put sessions - some people want to use that portable USB drive, some people want them under $HOME, some have a separate internal drive ⌠we could use some heuristic to guess, but it would be wrong at least 1/3rd of the time I think.
The core problem here is that itâs a situation with someone using a tool for the first time and hoping they donât need to know anything about the tool (or more charitably perhaps, that they can âlearn by doingâ). I donât think thatâs true of a DAW. You can learn a lot by doing, but there are some basic things that youâve got to understand a bit about. Probably. Maybe.
I understand the problem that presents - but I think that arises from an assumption (maybe going back quite deeply into the design of ardour) that it needs to know those things before you can open the application, which logically leads to asking questions even a proficient user might not know or have decided the answer to, until they have opened the application for the first time - and hence will almost certainly have to change them later anyway.
Perhaps the real solution is to approach it from the point of view that Ardour shouldnât need to know those things in order to let you open the application for the first time with a blank session and no default audio preferences selected.
I donât know another DAW that requires any of this setup on first use (and itâs not because Ardour has functionality the others donât in this regard). Itâs all in the preferences once you are inside the program and start asking questions about whether certain things can or need to be changed. Itâs a great way to explore and start understanding the power of the software. Samplitude, for example, will default to MME or perhaps their ASIO Magix low latency driver on the built-in soundcard. Itâs perfectly fine. REAPER does something similar and I donât think anyone complains. Think about it this way: you are offering two different ways to change preferences so you donât think it might be confusing when the user canât get that same dialog box back up?
I genuinely think ardour could increase its user base if things like this were addressed. Its not an exciting new feature, thatâs are going to grab the interest of experienced ardour users (or maybe even the developers). But I know anecdotally of people very experienced with other DAWs who have never got past Ardourâs intro setup. Its not a case of canât, its a case of âthis is just one - extra - part of a hundred other things I have to think about in order to get my job done. If Iâm spending time figuring this out, Iâm not getting way more important things doneâ
Hereâs an example of the type of thing I mean - and this is just during normal usage:
You can see there are some odd sessions there Iâve been using during the testing of various plug-ins, but - and this is the point - the only option Iâve got - or so it seems - is to Quit. Thereâs nothing there to cue me that selecting anything else will change that. Perhaps thatâs just a bug, but by any definition, its not intuitive - and its symptomatic of other usability issues further down the line. Ardour needs to draw people in - to give them a clue that its this amazing piece of software that they will want to use.
Hi, In my experience building and testing Live Media, Reaper (Linux) defaults to JACK and if JACK isnât running it throws an Audio Engine error so for first time launchers also not terribly clear what to do if you donât know how to discern between ALSA, JACK or PulseAudioâŚand in the futureâŚ*shuddersâŚPipewireâŚ
Yes, weirdâŚnever noticed that so it clearly hasnât bothered me. Still, it does have a big âaudio deviceâ button it throws with the error so itâs better than nothing. Iâm probably mixing up its (sane) defaults on Windows.
Is there any reason that you couldnât run Ardour to do an initial scan so that wine completes itâs initial config and then delete the ardour config before creating the iso? Iâm thinking that way, on a live session Ardour would still need to do the setup routine and scan, but it should work because wine would already be initialized.
I find it surprising that some would find this screen unintuitive, but it seems some would. To me, the layout is obvious. If I want to start a new session, I click the large button that says âNew Sessionâ. If I want to open an old session, I can either select one from the recent list or click the drop down box, which is similar to drop down boxes in other programs where you need to select a location. The fact the buttons are greyed out until you make a selection seems familiar to me as I have come across that behavior in other programs. I wonder how this could be improved as it seems as straight forward as it can get. I also wonder how a potential user who struggles getting past this screen could use Ardour at all, given how complex a program it is.
This is getting a bit off topic - but the point is not that anyone would necessarily struggle to get past this, and I think its unnecessarily dismissive to assume that anyone who doesnât find this intuitive would struggle with something âas complexâ as Ardour. I donât find it intuitive, and I can assure you I work with things way more complex than Ardour, all the time.
Sure, if you randomly click things then stuff happens, but thatâs not intuitive UI design by any measure. Why not simply (pre)highlight the last session for example? My point is that the application shouldnât be putting up barriers to entry, it should be enticing new users in. On seeing the first dialogue you should be thinking âI canât wait to see what this software can doâ - and not, âwell, I guess the rest of the application probably wonât get much worse than thisâŚâ