On 04/01/21 01:28, J. Liles wrote:
On Sun, Jan 3, 2021 at 5:24 PM Filipe Coelho <[email protected]
<mailto:[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.
