> > I understand that you like the printf specifier format, as it looks 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
