On Sun, Jan 3, 2021 at 5:24 PM Filipe Coelho <[email protected]> wrote:
> On 04/01/21 00:55, John Rigg wrote: > > On Sun, Jan 03, 2021 at 11:25:16PM +0000, Filipe Coelho wrote: > >> jackpatch has a user-experience problem > > Out of curiosity, what is the problem? I've been using it > > for over 6 years and it's always worked flawlessly here. > It is not a problem you see all the time, but when it happens is annoying. > > There is a whole thread going on about this, so I will keep that > discussion there. > > > >> An export/import option is not unreasonable, in my opinion (and several > >> others on the same github topic too). > > There is an 'import at mouse' option in each track menu. > > > > Unlike Ardour, non-timeline records multichannel tracks to multichannel > > files, which can be used as is, so no need for a separate export > function. > > > > If further conversion is required it can be done with an existing program > > like sox. > > There is a misunderstanding here. This is about NSM. > > So the idea is to have a way to export a session from the GUI, so that > we do not have to manually find the right dir and manually compress > using tar or similar. > This is error-prone due to requiring correct use of tar. If symlinks are > used in the session, we likely want to convert those into real files. > > Having such option in a GUI prevents user error, as the right tar > commands or anything custom needed will be there. > Same for import, kinda. > > There was a ticket about this, with then some discussion on how/why this > is stupid and dumbing-down users. > > Personally I still think this would be of great value. > I sometimes forget the right flag to make 'tar' resolve symlinks when > creating a tarball. > > That's why a clever person puts that kind of thing in a shell script and just invokes the script rather than trying to remember the right commands. I was perfectly happy and willing to discuss the issue of archives and imports with you. *You* were unwilling to consider the possibility that A) it needn't be built into NSM and B) that I needn't do it myself. Still happy to discuss it, of course. But bear in mind, that I am interested in the best solution, putting things where they belong, and keeping the complexity and bloat to a minimum. So if you come into the discussion with fixed views about who should do what or where it belongs, then you're probably going to be frustrated when better ideas are presented.
