Filipe, I don't know how long you've been a human being, but I've been one for quite a while now, and I've had plenty of stupid ideas. It's nothing to cry about. Knowing that an idea is bad is the first step towards finding a better one (and there's usually a better one! especially true if you just tell someone the first idea you think of! boy are there going to be better ones!.
On Sun, Jan 3, 2021 at 5:32 PM Filipe Coelho <[email protected]> wrote: > On 04/01/21 01:28, J. Liles wrote: > > > 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. > > I really think these sorta things belong in a GUI, not in a script. > > As I already said before, when we opened a ticket it was not a demand. > Sometimes it was just to start a discussion. > We did not expect you to do it, specially since the git repo was not very > active anyway. > But due to lack of FLTK/NTK devs, we are also well aware that any changes > would take time. > > We were upset when you called people dumb and the idea stupid, yes. > > >
