|
From: Kolja K. <ko...@fr...> - 2021-09-08 17:27:34
|
Hi,
thanks for the tipps!
I made some progress, see attached screenshots.
example1 shows processing the default-naming-scheme. I already renamed
these files with my initial shell-script to that. When hitting OK, a
wav2gig-command is created:
wav2gig --regex-name1 "(.*) - .* - \d* - \d* - .* .*" --regex-name2 ".*
- (.*) - \d* - \d* - .* .*" --regex-velocity-nr ".* - .* - (\d*) - \d*
- .* .*" --regex-note-nr ".* - .* - \d* - (\d*) - .* .*" --regex-note-
name ".* - .* - \d* - \d* - (.*) .*" [list of files]
This actually worked! :)
example2 however shows a much more complex case. As to see on the left,
there are a lot of files in that folder and they don't have any note-
number nor velocity. The tool will calculate the notenumbers based on
given sign-characters (' ' for sharp in this case). Another thing to
mention is that the (mono-)files' last character show their stereo-
position (L for left, R for right). So with the specifier-string one
can enter in the middle of the window, this added to the corresponding
name2 (%m appears twice). Also, not all files comply to the specifier-
scheme, that's why I entered a second one, wich will be used against
the remaining files. This way, all files could be processed, creating
18 gig files out of that. Theoretically, you can enter as many
specifier-schemes as you like.
Surely, this wouldn't actually work with wav2gig, since I don't know
how to translate this into the required regex.
Another thing is that there's no velocity given. Don't know, how
wav2gig would react on this.
I'm not absolutely sure, how to go on from now. The whole thing would
need some cleanup, I'd like to implement some options, help and
preferences. In order to implement the bottleneck from above I would
have to patch wav2gig, I'm afraid. This wouldn't be something for your
mainstream, thou, I guess.
Maybe I'm putting that on a github-site, have never done that before...
> Later on I will make that available by more convenient functions via
> > the
> > libgig API. But that's still in the works on my side.
That sounds really interesting! I could imagine using that directly,
when it's ready. Looking forward to that!
Cheers,
Kolja
Am Sonntag, dem 05.09.2021 um 18:48 +0200 schrieb Christian
Schoenebeck:
> On Sonntag, 5. September 2021 15:45:15 CEST Kolja Koch wrote:
> > Hi Christian,
> >
> > cool, thanks a lot for this!
> > As far as I understand it, I will be able to use that in my 'gig-
> > creator', that I'm working on (by the way, I ended up using
> > wxWidget).
>
> Yes, for now you would probably assemble a command line and call the
> system()
> function to execute the assembled command line, something like:
>
> int res = system("wav2gig --name1-regex '" + name1Pattern +
> ... );
>
> Later on I will make that available by more convenient functions via
> the
> libgig API. But that's still in the works on my side.
>
> I also slightly changed the default regex patterns, which are now
> like this:
>
> [^-\/\\]+ - [^-]+ - [^-]+ - [^-]+ - [^.]+
>
> Tearing that pattern down:
>
> [^-\/\\]+
>
> Which means "any sequence of characters except minus ('-'),
> forward slash
> ('/') or backslash ('\')". Basically this strips away a leading
> path like
> "/some/where/foo.wav" or "C:\some\where\foo.wav" and stops before
> the next
> " - " delimiter starts.
>
> [^-]+
>
> Any character sequence except minus ('-'). So it stops
> before the next
> " - " delimiter starts.
>
> [^.]+
>
> Any character sequence except dot ('.'). That strips away the
> trailing
> path extension, typically ".wav" or ".WAV".
>
> One more tip: if you are choosing C++ then I recommend to use C++11
> string
> literals for your regex code. That avoids having to double escape:
>
> // double escaped required (one for regex, one for C++)
> string pattern = "[^-\\/\\\\]+";
>
> vs.
>
> // single escape being sufficient (for regex only)
> string pattern = R"RegEx([^-\/\\]+)RegEx";
>
> That way you can also directly copy & paste the regex code from your
> source
> code into any RegEx debugging tool of your choice and vice versa.
>
> CU
> Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|