I was thinking a little bit more about this.
Maybe we should agree upon some kind of complexity-level we want to
catch.
For instance:
The user might want to put samples into a gig-file, that have no common
filename structure. We could write an interface to let him enter the
required attributes (with regex or what ever) for each filename and
give wav2gig an array containing those attributes per filename.
But I believe, this is not somehting we would want to capture, since
the user could instead use gigedit directly to create that gig-file.
So the question is where tu pull the line between filename-complexity
and usability.
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.
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.
Have a nice sunday!
Kolja
They could also be embedded in a regex-logic.
Am Samstag, dem 28.08.2021 um 20:23 +0200 schrieb Kolja Koch:
>
> >
> I think it's because I'm a little more used to it...
> > more
> > simple on first view. But keep in mind both on your easy tag
> > example
> > and
> > printf the actual purpose deals with the other way around: e.g. in
> > the easy
> > tag example the individual components where already gathered
> > (extracted from
> > the MP3 files), and the actual intention was to assemble one string
> > from those
> > individual components, which is really just a string concatenation
> > operation.
> >
> It also works the other way around, it indeed allows you to get the
> tags out of the filenames and/or paths to fill the ID-tags, if those
> are missing.
> See attached screenshot.
>
>
> >
> > 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.
>
> Cheers,
> Kolja
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Linuxsampler-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
