Re: [Linuxsampler-devel] wav2gig naming-convention

[Kolja K. <ko...@fr...>]

Hi Christian,

thanks a lot for the info!

Regarding regex:
I know regex, but was not too familiar with it.
>From what I understand, it is hard to foresee, in what order the
attributes are in the filename, which makes direct usage of regex
difficult.

I already toyed around a little bit and wrote a patch (2 files
attached), that will do the following:

- Use '-s' as a switch to use the 'filenamescanner'.
- You will be presented with some instructions on how to use it.
Basically, this works like formatting with printf. Also, the first
filename of the set will be printed.
- Enter a 'scheme' that will be used to parse the filenames.
- Eventually enter required attributes that are missing in the filename
(like e.g. velocity, that would be a constant for all samples then).
- Show the result based on the first filename in the set.
- Proceed, retry or abort.

It uses regex to parse the input-scheme and thereby create another
regex-string (that will then parse the filenames) plus mapping of the
found patterns to the corresponding attributes.
The code calculates NOTE_NRs out of NOTE_NAMES and vice versa, if
either one is missing.

The patch also adds
"
    } else {
    	s->MIDIUnityNote = wav->note;
"
as you proposed.

To be done:
- code-cleanup
- test and implement checks against sane input (e.g. NOTE_NR has a
valid format) and make code more robust.
- 'hide' filename-path, only the filename itself is relevant.
(Although, expanding the usage of wav2gig to be able to create multiple
gig-files based on a directory-structure could be interesting.)

Wonnahave:
- A flag for automatically generating the .gig-filename like e.g.
'NAME1 - NAME2.gig'.
- The possibility, to automatically join two mono-wav-files into one
stereo-wav-file. Another specifier for identifying those in the
filename could be added, like %s. Currently, this has to be done
'manually' (e.g. with sox), bevor using wav2gig.
- a flag to expanse the created regions (with a minimum of pitch-
correction), so that a gapless, ready-to-use instrument is created.
I think, this would make the tool very valuable for creating
instruments from scratch.

As I said, this is my first contribution (and the first patch I ever
wrote), I still lack knowledge of versioning and writing code that is
e.g. windows-compatible (I'm on Archlinux, had to adjust the PKGBUILD
of libgig-svn since it woldn't compile due to pango-errors), so bare
with me... ;)

If you'd rather go into another direction, that is fine with me as
well, it still was a good exercise for me :)

Let me know what you think!

Cheers,
Kolja

P.S.: I put the functions for the filenamescanner into a separate file
(filenamescanner.cpp). Both files need to be in the directory of
wav2gig.cpp since I don't know how this is usually done.



Am Donnerstag, dem 26.08.2021 um 15:35 +0200 schrieb Christian
Schoenebeck:
> On Mittwoch, 25. August 2021 12:26:38 CEST Kolja Koch wrote:
> > Hello all,
> > 
> > I played around a little bit with the wav2gig tool, in order to get
> > samples extracted by akaiextract into a gig-file.
> > Currently, wav2gig only supports a hard coded naming convention for
> > the
> > wav-files in order to get the information needed for the import
> > process.
> > 
> > - Are there any plans to integrate the import-process into gigedit?
> 
> In libgig there is already a quite a collection of individual command
> line 
> tools. The plan is to first make these already existing tools available
> through a convenient API accessible from the libgig DLL itself. I've
> already 
> started work on this on libgig side (not committed yet).
> 
> As a next step GUI applications like GigEdit would be extended to call
> those 
> libgig functions to offer the respective tools like conversions,
> integrity 
> checks, and so forth. This could obviously then also be used by other
> GUI 
> apps.
> 
> > If so, we could present the user with an interface similar to the
> > "Fill
> > Tag" scanner in eastag:
> > http://src.gnu-darwin.org/ports/audio/easytag/work/easytag-2.1/doc/EasyTAG_D
> > ocumentation.html#vh_1_2_2 Note: Any characters in the filename that
> > should
> > be ignored can be entered directly and work like a delimiter, just
> > like the
> > " - " in the example.
> 
> wav2gig.cpp already uses regular expressions (RegEx) to extract info
> from the 
> individual file names. These RegEx patterns are currently hard coded in
> wav2gig.cpp, but the plan was to use them just as default RegEx
> patterns and 
> allowing to override them individually with custom RegEx patterns from
> the 
> command line if needed.
> 
> While the template format in EasyTag is easier to understand, it is
> also much 
> more limited than RegEx patterns.
> 
> Regular expressions are a common standard for text parsing tasks across
> all 
> programming languages, including shell scripts.
> 
> > Disadvantage is, that this will only work, if there are indeed
> > delimiters. In my case, the filenames look like this:
> > 'STFLSF 5   L.wav'
> > where 
> > 'ST' is the instrument, 
> > 'FLS' the articulation and 
> > 'F 5' is the note 'F#5'. 
> > The 'L' stands for 'left', as there is also a file for the right
> > channel.
> > 
> > Unfortunately, there is also
> > 'STFLSF5    L.wav'
> > where 'F5' is the note 'F5'.
> > Theoretically, there could also be a 'F -1' (= 'F#-1').
> > 
> > I know, we cannot cover any name-scheme one might (not) think of, but
> > as you can see, the only 'dynamic' part of the filename in my case is
> > the note-name, so using the 'easytag'-scanner I could enter
> > 'STFLS%n  '
> > where %n would refer to the note-name.
> 
> Yeah, but RegEx patterns can handle all of them, and also much more 
> complicated file name scenarios beyond that.
> 
> I highly recommend you to readup on RegEx patterns, as this is a highly
> valueable knowledge for any programmer, even if you are just writing
> shell 
> scripts. There are also plenty of sites online that allow you to toy
> arround 
> live with RegEx patterns and arbitrary input, with coloured visual
> diagnostics 
> how the example input text was exactly tokenized, syntax help and much
> more.
> 
> [...]
> > I'm willing to participate on this, though my programming-skills are
> > those of a layman... ;)
> 
> Well, in this particular case, all you need is inside wav2gig.cpp,
> which is a 
> understand and adjust this code, even for beginners.
> 
> CU
> Christian
> 
> 
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel