On Samstag, 28. August 2021 20:23:34 CEST Kolja Koch wrote:
> > wav2gig -a '(.*) - \d* - .* - .*.wav" \
> > -b '.* - (\d*) - .* - .*.wav" \
> > -c '.* - \d* - (.*) - .*.wav" \
> > -d '.* - \d* - .* - (.*).wav"
>
> It took me a moment to understand your proposal right.
> That is indeed very flexible, especially when combined with
>
> > pattern1|pattern2|pattern3
>
> as you proposed.
> Also, this would make wav2gig easily to be invoked by other programs.
>
> From a user point of view, this anyway seems to me like it's hard to
> understand. E.g. if I'm no programmer and would be confronted with this
> kind of logic, I'd be scared away very soon.
>
> So why not use both approaches?
> - implement those name-switches as of your example
> - write a wrapper for wav2gig with a commandline-interface using the
> easytag-logic or whatever we would agree to be user-friendly. Not all
> name-schemes would have to be implemented here. This will call wav2gig
> with the corresponding Name-switches.
> - Write a real gui for that wrapper, that might be invoked by e.g.
> gigedit.
Because somebody would need to write *and* maintain all of that software. Keep
in mind that almost all people stepping by here are usually just saying
feature x doesn't work, please fix it. Or feature y is nice, but please extend
it in this and that way.
I understand that you would like to see those wav2gig patterns more user
friendly, but wav2gig is just one of many things (and projects) I have to take
care of and I only have two hands and 24h/day. wav2gig is out for just 2 weeks
now and you are probably one of the first people ever having used it at all
(yet). So that's the infamous point where I have to make clear compromises ...
Regex patterns are doing the job, including use cases that go beyond your
personal needs, and I don't have to maintain parsing code by myself. So the
plan is to make this feature configurable by standard regex patterns only for
now; no self-invented formats/tags and no custom parser code on top that would
need to be developed, documented, extended and ... fixed. Instead some regex
examples in the man page should already be a good starting point for new
users.
For more complex uses cases there are plenty of RegEx howtos and live RegEx
debug tools on the net. And if someone fails: there is still this mailing list
and the forum site where users can just ask.
Additionally I would add a verbosity switch and maybe a --dry-run switch for
providing users diagnostics for the individual input wav files' meta info
being picked by wav2gig and why. But that should be really it for foreseeable
future.
On Sonntag, 29. August 2021 12:30:13 CEST Kolja Koch wrote:
> Having wav2gig to accept regex-patterns for each attribute is fine with
> me. But from a user point of view, having an interface that allows him
> to easily enter patterns for the attributes for (some kind of simple)
> filename-structures would be recommendable.
Yes, but you can also easily over-engineer this as well. ATM I don't see this
conversion tool being used by a huge amount of people, nor on a frequent
basis. Hence I personally don't want to invest too much time and focus on it,
at least not ATM.
People who might refrain from using the wav2gig tool because of regex patterns
being user-unfriendly, usually neither want to use command line tools in the
first place. So for such people you would rather want to write a GUI app ontop
of libgig where you could really invest a *load* of development time and
people would probably still give you suggestions how it could be improved.
E.g. you can make a clickable pattern editor with coloured highlighting and
nice token frames that would show you a preview of the expected results in
real-time, and you could combine that with an automatic prescan of a directory
and deploy an A.I. on top of the prescan for a fully automated initial pattern
suggestion.
The more you think about it, the more desirable extensions you will find.
However the question always is: who will develop and maintain all of this.
> This is where (my beloved;) specifiers might do the trick. Beside the
> fact that they allow specifying all attributes in a one liner, checks
> against required attribute-formats would be implemented.
> The interface's output would be a command invoking wav2gig with the
> corresponding regex-patterns per attribute.
> This shouldn't be too difficult to implement, basically it's just a
> replacement of e.g.
> NoteNr %3r with (\d{3})
> or
> NoteName %a with ([c|d|e|f|g|a|b|c]+)(.*)(-?)(\d+)
>
> If you really want to allow to have alternative patterns for the same
> attribute, this could be implemented as well, e.g. using #[number]
> like:
> /path/%#2r/filename%#1r.wav
>
> which would result in the following regex-pattern for NoteNr:
>
> /path/.*/filename(\d+)\.wav|(/path/(\d+)/filename.*\.wav
>
> where '%#2r' is replaced by '.*' in the first alternative.
>
> I could imagine writing this with gtkmm (glade), but have no experience
> with that (only did some ncurses before), so I don't know how long that
> would take.
Well, if you really want to start such kind of project: I would recommend to
reconsider the toolkit decision and no longer use gtk(mm) for new projects
anymore, for many reasons actually. You would probably safe yourself a load of
development time and frustration on the long run by simply picking another
toolkit right from the start.
CU
Christian
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
